ATM Authentication Issue [Group 3] : No auth file generated

[AshStorm17]

The bank does not take any -s argument and does not create an auth file.

This means that we cannot authenticate the atm. In the atm I see a warning that -s file is not needed.

The Readme claims to have .auth files for authentication but no such file is observed in running code.

[Quantizate]

@AshStorm17 we actually have a different structure for the auth file. And we also spoke to sir about this, and since the requirement was based on every user session, we are creating an auth file that can be used for all transactions(withdraw, balance, deposit) in that session. Please do go through the assumptions section in our readme. https://github.com/IITGN-CS431/project-cns/tree/main/project-submissions/group-3#assumptions

[AshStorm17]

The user is authenticated, but we are not authenticating the atm. This should be done in order to ensure that only legitimate atm's are able to login to the bank.

[bichhawat]

I think the question here is that can a random atm (without bank.auth which is not present here) connect to the bank. If this is hardcoded into atm, can we generate a rogue-atm with some fields changed that can still connect to the bank. If yes, then this may be a security bug.

[Quantizate]

Actually we did have a conversation with @pratyush3757 sir if a person is using our atm client and performing any operations we do treat them as legit users and also we have taken all precautions that even if the person has details of another person unless until the user is authenticated we won't be able to make any transactions. Also, one way to authenticate atm could be using mutual TLS but then we would be needing the client certificate which would need to be provided always. Then we would not be ideally be able to run multiple atms without having all these certificates which in our case we can run the atm from different systems too. Also, we might have got it wrong when we discussed the problem statement with you we did draw the conclusion that bank.auth would be used to verify user sessions and generated for every user session and that is what we have implemented. Again with client separation this shouldn't ideally be an issue.

[bichhawat]

The user sessions are via an ATM, right? So if the ATM is not authorized, it may be stealing session information of the client. There isn't a need to authenticate client; having a "pre-installed" bank.auth on the atm should have been enough. But that's okay for now

[pratyush3757]

This approach poses an issue if a MITM can get knowledge of the user token, and spoof it. Originally, the attacker would need both the user details (card file) and the atm client details (auth file). So 2 things to spoof. But these two approaches are practically equivalent as, client + auth files may be transmitted together based on implementation. So they may be treated as one entity.

[Quantizate]

Yes, that does provide additional security. But we were lost in thought about how a client from a different device can approach the server. One way would be to bundle the app together with the auth file, but if we were to think of that we would need to keep replacing this "bundle" every time. The other way would be that whenever we start a client we request for an auth file from the bank, again this leads to the same core problem of how do we really authenticate the client (spoofing issue again). These are just what I could think of, is there any other way or something other than this used in the industry perhaps, would really like to know more about this.

[pratyush3757]

We are just emulating a bank and atm right? So securely installing a key (or auth file) on the atm beforehand is trivial. Also, that provides us a way to rotate keys afterwards as the initial sharing is considered secure.

But I guess you are asking about a scenario were we're dealing with distributing virtual or software based clients? In that case, we'd have no way of differentiating a legitimate client from a spoofed one straight away. There are ways of detecting one, like asking the application to identify itself with a "signature" (not entirely cryptographic one but close), detecting anomalous behaviour, or checking if it uses up-to-date API endpoints. It's just an endless arms race between the crackers and the defenders basically.

One other way is to force a client to have a secure third-party solution that verifies the integrity of the client. Case in point, kernel level anti-cheat software (or DRM) for games. A modded/cracked game is just a spoofed client. So they check the validity of the game and look for any other "malicious" processes that are running. The server won't respond until the verifier connects and gives a thumbs up. Is that foolproof? No. But they can have multiple layers to detect and prevent tampering. How would you verify the verifier? First, (on windows) it's hard to install kernel level software that isn't signed by a trusted party. Second, just ship it with a certificate, send it a challenge to verify it. (And rotate the certificates often enough that it becomes infeasible to attack it).... And other ways I don't know much about.

Security's a process, not a solution. There will always be ways to bypass even hardware level of security, so we have to take assumptions and work with those, while also updating the assumptions as we go.