0

Hi I am just planning my server login security for a mobile app and have made notes of a simple plan. Does it look secure, and can it be improved in any way? Thanks in advance.

Client login for the first time

  1. Get device id from client and send to server.
  2. Create a MD5 salt on the server and user account with new user ID.
  3. Concatenate the salt with the device ID and User ID to create the salted password.
  4. Create a MD5 Hash of the salted password and store the hash password in the database.
  5. Return the user ID and Salt to the client.

Clients login again or makes a general request

  1. Send request to server with MD5 hash generated by the client using the salt received from server and concatenating with the device ID and User ID. Also send the device ID and user ID in plain text.
  2. Verify the user device ID and user ID stored in the database are the same as sent by the client.
  3. Verify that MD5 hash sent by the user is the same as the hash stored in the database for that users device.
  4. Validate and continue with processing the request.
HoldOffHunger
  • 18,769
  • 10
  • 104
  • 133
Beloudest
  • 339
  • 1
  • 5
  • 18
  • I would recommend just to use a proven library to provide this functionality. You would be reinventing the wheel thinking you make things secure, but i would doubt that most of us would be smarter than a collective of contributers to such library :) – jcuypers Apr 12 '19 at 09:33
  • @jcuypers I appreciate your sentiment. I'm using PHP and Unity and I have to do most the leg work on the client side my self. I also want to learn what I can. Do you have any suggestions on such libraries? – Beloudest Apr 12 '19 at 09:39
  • I'm more of an Angular guy. Anyway I can provide you with this great link explaining the topic nicely: https://crackstation.net/hashing-security.htm. it has some PHP libraries listed but I cannot comment on them. – jcuypers Apr 12 '19 at 09:48
  • 1
    @jcuypers that was a very good link. Thank you, I would have struggled to come across that on G search. It seems I'm not far off the recommendations. The data I'm storing is not security sensitive so I currently feel comfortable using the advice in the article. I just want to stop cheating in a game. Main take aways are don't use MD5 for hashing and don't send the hash with each request, instead rebuild the hash on the server with the salt stored in the database and send a password which in my case will be device id as it stands. I can see a good reason for user password down the line. thx – Beloudest Apr 12 '19 at 10:29
  • 1
    Take a look at this - [How do you use bcrypt for hashing passwords in PHP?](https://stackoverflow.com/questions/4795385/how-do-you-use-bcrypt-for-hashing-passwords-in-php) – royalghost Apr 12 '19 at 11:08

1 Answers1

1

If security is a concern I would not recommend using the device ID as a password for the following reasons:

  1. It is not secret information and may be sent in plain text in many network calls to many servers meaning it could be easily obtained by a third party.
  2. It cannot be easily changed if a malicious third party obtains it.
  3. If the phone changes hands the id will remain the same allowing the new phone owner to log in as the previous user.

An alternative approach would obviously be to let the user choose their own password, however I'm guessing you have already considered that and you are choosing to use the device ID as it makes the experience as frictionless as possible for your user.

I would therefore recommend generating a uuid when the user installs the app and storing this in the devices secure storage (key store / key chain). On the first request send this up to the server along with the user id. A temporary session id should be generated and returned to the client which can then be used to authenticate successive requests.

Also MD5 should not be used for password hashing as it is not resistant to brute force attacks. A better choice of algorithm would bcrypt or pbkdf2.

James Adcock
  • 103
  • 5
  • Good advice, you have reinforced my research and thought process I had at the end of play yesterday. I also plan to use other social networks to log users in before registering with the game server. Facebook allows me to verify the users tokens via a server to server call which additionally adds a password security layer. I like the GUIID idea. – Beloudest Apr 13 '19 at 07:25
  • Would you recommend creating a new session ID for every new session e.g. reopened app? I'm also encrypting data with AES and I was thinking a session ID can become part of a startup request that establishes a unique hash to encrypt more sensitive data associated with a new user ID/account to send once the user has the session ID, good thinking? – Beloudest Apr 13 '19 at 07:25