1

I'm currently developing an android bank client app. Obviously security is key here. The app sends requests over HTTPS TLSv1.2 to my java server.

What I currently have in mind

Login

The app asks for user's username and password and sends these in plain text over HTTPS TLSv1.2 The password is hashed with bcrypt and if credentials match, an access and refresh token is generated. The refresh token is stored in the database along with the user's UUID. The access token and refresh token is then sent back to the app. The app stores these tokens in SharedPreferences(PRIVATE_MODE) The user is supposed to not have to re-enter their credentials if the app is opened again later and the refresh token is still non-expired.

Pin code

After successfully logging in, a PinCodeActivity is started which asks for the user's 5-digit pin code. The PinCodeActivity is always started when the app is opened and the user is still logged in. The entered pincode is also sent to the server in plain text. The pincode is then hashed and matched with the pincode in the database for the user corresponding with the access token which is also sent in this request to authenticate the pincode. If it matches, the server sends an OK response and the pincode is stored in memory on the app to be sent alongside every request to the server. When the app is closed this pincode is removed from memory.

What I'm not sure about

If the credentials and pincode is sent in plain text, could they not be intercepted by a Man In The Middle Attack? If so, if I would hash them on the app, would this not have the exact same implications? In that case an attacker could just send the intercepted hashes and login/attack with those hashes. I'm really no where near a security expert so please let me know if I got anything wrong or if there's something I should know.

Basically what I want to know is if the implementation I proposed is a secure method for a bank client app. And if not, how could I make this more secure?

keesjanbertus
  • 113
  • 2
  • 3
    `If the credentials and pincode is sent in plain text, could they not be intercepted by a Man In The Middle Attack? `, to intercept a TLS connection and read the data in clear the attacker will need the bank's domain certificate or must fool you, to accept another domain. You are basically secure with your aproach. –  Nov 10 '19 at 15:17
  • 2
    Possible duplicate of [https security - should password be hashed server-side or client-side?](https://security.stackexchange.com/questions/8596/https-security-should-password-be-hashed-server-side-or-client-side) – multithr3at3d Nov 11 '19 at 03:44
  • @multithr3at3d I would say that my post is broader since I asked more broadly about the security of my implementation. In stead of only about hashing server-side or client-side. If the post is not different enough, let me know and ill accept the duplicate. Cheers! – keesjanbertus Nov 11 '19 at 09:53
  • 1
    "The pincode is then hashed and matched with the pincode in the database" - sample space of possible PINs is low enough that this seems fruitless. – Adam Williams Nov 19 '19 at 22:32

1 Answers1

2

Transmitting data over TLS is assumed to be secure when the TLS implementation is well-managed. There are three major developer-level considerations.

Your server and client should be configured only with secure ciphers. Some MITM attacks leverage server/client support for weak ciphers to force the selection of a weak cipher, which the attacker then compromises. As long as one side requires strong ciphers, the connection can be established securely---but it is best to configure both ends if possible.

You should look into certificate pinning. With PKI, by default, any trusted certificate authority can issue a certificate for any domain. An attacker could compromise a CA and then issue certificates for domains of his choosing, or he could convince a CA to sign a fraudulent CSR that he created for your domain; these would work until he the compromised certificate is detected and revoked. Needless to say, financial institutions are desirable targets for this sort of abuse. Certificate pinning prevents this from happening by ensuring that your own certificate is used to establish the TLS connection.

Finally, use a current and supported cryptographic library to handle those operations. Crypto is a highly specialized discipline with a steep learning curve, and it is very easy to introduce disastrous flaws. Do not reinvent the wheel.

DoubleD
  • 3,882
  • 1
  • 6
  • 14