1

First time doing a secure login from a mobile app to a server (built in java). I want to understand if I got this right.

Login in for the first time:
1. On the mobile device hardcode a security phrase (ex: "superSecurePhrase@@!!".
2. Take in a username and password.
3. Use base64 to encode username+phrase and password+phrase.
4. Using https send this information to my server.
5. On the server decode using base64 with the matching phrase hardcoded on the device.
6. Hash password and save to DB, also hash username and save to DB.
7. Use AES algorithm to create a session token
8. Send session token to device.
9. Save session token to DB, and when user requests something, make sure they match.

To verify credentials it is pretty much the same process except username and password aren't saved, but instead queried for the DB and checked for a match?

Is this the general pattern used for this kind of thing?

Potential vulnerabilities:
1. Physical access to the device to retrieve the hard coded base64 phrase?
2. SSL Sniffing and acquiring the token?

Thank you for your help.

William Falcon
  • 9,813
  • 14
  • 67
  • 110
  • 2
    Have you read [The definitive guide to form based website authentication](http://stackoverflow.com/questions/549/the-definitive-guide-to-form-based-website-authentication)? – Oleg Estekhin Jul 09 '14 at 13:30

1 Answers1

1

If I were on your place I would hash the password with SHA-1/SHA-2 on the device when registering. This way I will be sending only the hash. If the request is intercepted by a man in the middle, even if they decode the Base64 encoded string, they will have only the hash. As an end use I will be terrified if someone has my raw password, because I use it on other places (I know it is a bad practice). You can still Base64 encode the hash with the salt.

You can use your "superSecurePhrase@@!!" to salt your password string during the SHA-1/2 encoding, or have a separate salt for this.

The token should be random on every generation (it stays the same until it expires), I would use something like the org.apache.commons.lang.RandomStringUtils, assuming you are using Java on the backend.

On the app side I would store the token in the shared preferences, if the device isn't rooted, it isn't accessible by other apps. If it is, and the user allowed root access to the app, you can't do anything about it. Storing in a databes is also OK, if you are already using a database in the app.

So, to sum it up, the biggest difference is that I would prefer to create the password hash on the device and send only the username and the hash over SSL.

Daniel Alexandrov
  • 1,299
  • 8
  • 13