-1

We are developing a mobile app that includes a user account system. Currently, we have a system password flow like this:

User enters password -> SHA-256 HMAC hash with key -> server -> SHA-256 hash -> database

I have 3 questions:

  1. Is this secure enough for release?
  2. Would it be secure to store the client-side password hash to save the login?
  3. If #2 is a no, would it be better to encrypt the hash using AES-256 and then store it?
schroeder
  • 125,553
  • 55
  • 289
  • 326
Blakenator
  • 1
  • 1
  • #3 is out: Do not encrypt passwords: hash them – schroeder Jul 10 '15 at 18:30
  • We're assuming the connection between the client and server is encrypted? – schroeder Jul 10 '15 at 18:30
  • Yes, it is encrypted – Blakenator Jul 10 '15 at 18:35
  • 1
    1. No, the SHA-2 family of functions are not suitable as password hashes. [Just use bcrypt](http://codahale.com/how-to-safely-store-a-password/). 2. No, the client-side hash effectively becomes "the password" and now you're storing "the password" in plaintext. 3. No, passwords should be hashed, not reversibly encrypted. – Stephen Touset Jul 10 '15 at 18:42

1 Answers1

0

You are hashing on the client, then encrypting again on the server? If you are under SSL, sending the hash from the client isn't really any more secure than sending the password in plaintext to the server. In fact, this method just makes the hash BE the plaintext, if you can capture that you can send it over to the server just fine, without knowing the real password.

Send the password over ssl in plaintext, Salt. hash it with PBKDF2, scrypt, or bcrypt. . Many iterations. Done.

Jason Coyne
  • 1,583
  • 2
  • 10
  • 10