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.

2 Answers 2


You don't need half of those parts. Adding them will only create a more complicated system, with more room for failures.

You could do this:

  1. Use certificate pinning on the device

    This ensures that the device is talking to your server, and make the work very hard for any third party trying to read the data stream.

  2. Using SSL, send login and password to the server

    Any other data can be skipped. Timestamps, secret phrases, anything else is superfluous. You could send some device ID, it can be useful for accounting, not for authentication. You don't need the information, leave it out. Using SSL enables you to send the password as it is, without encryption, hashing or encoding. SSL will encrypt to you, transparently.

  3. Store the username in clear, hash and salt the password

    Hashing the username does not give any security, and increases difficulty for you. Salting and hashing the password will help your data survive longer in a case of database leakage. Just select the right encryption algorithm, and good salts. This site is a very good reference on password storage.

  4. Use tokens with expiration time

    Store the tokens on database, and send them to the client. You don't need to change the token on every request, you just need to see if the token matches and is not expired. On every new login, expire the older tokens.

Don't trust the client. No matter how secure is the client code, someone can break it. Keep this in mind when designing the security of your system.

  • Is it fine to have a session cookie having encrypted token valid for a long time (1-2 years)? Commented Oct 3, 2018 at 11:21

Step 1 to 3 are obsolete as they do not provide any security here just obscurity. Credentials should never be hardcoded (CWE 748).

Step 4: good, ensure you perform certificate pinning

Step 6: How will you retrieve the password for a given username if you hash it? What algorithm are you using?

Step 7: Why use AES, why not generate a random token using a cryptographic secure random generator. If you use AES you make me think that the token will always be the same makes you vulnerable to CWE-384.

Step 8 and 9 seems good, that's how sessions work.

Normally your application should be nothing more than a frontend for your serverside API. All authorization and authentication should be performed on the server. This will require your user to introduce his password each time or you can cache it in memory. If you want to save the credentials on the device they will always be retrieveable by an attacker having access to the device (by then it's too late anyway).

So basically a first time login should be nothing more than a user registering as you would do with a normal web application. The users creates a certain password and username. This is passed through SSL to the server.

There are almost no differences between mobile and normal webapplications when it comes to building secure applications. You have a serverside application and a client side application. The difference is that instead of using a browser you now create the graphical frontend, used to represent the information, yourself. But the same principles apply.

Your remarks:

If an attacker is able to gain physical or remote access to a device, it's not your device anymore.

SSL sniffing doesn't really exist. SSL/TLS was created to prevent sniffing from happening. One thing to ensure is that your application verifies if the SSL certificates are valid. For even more sensitive information you should perform certificate pinning.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .