Is my authentication strategy secured?

Question

I want to implement an authentication system by following good practices, i want it as simple as possible and secured (im not going to implement some magic hashing function or something to feel a hero..) just wanting to use already known hash but not sure the right way of using it. I read some articles on how Lastpass (a password management company) mange to handle their authentication and i loved their idea.So i wanted to implement my own authentication based on it.

Basically im creating an authentication key from the password on the client side (so the password is never sent as a plan text to the server). that authentication key im sending to the server than do some hashing operations also in the server side and compare the result to the one inside the database.

On my client side:

auth_key = PBKDF2(SHA256, password+username, last_login_fe_salt, fe_rounds)

explanation - hashing password+username+last_login_fe_salt text fe_rounds times

last_login_fe_salt -> a random salt sent to the user once he/she input their username in text field - To be honest, not sure how this last_login_fe_salt is efficent for the cryptography against Dictionary attacks but atleast two people having the same password will send different hashes on their network. any hacker can get this data by asking from the server, i can add server side limitations (req/s if it makes some difference etc.. let me know what you think) also adding captcha might be a good idea. When a user logged in successfuly the server generates a new random string and saves in into the database.

*I didnt see any explanation which salt Lastpass uses on their client side hashing, they are using PBKDF2 algorithm that needs a salt parameter.

fe_rounds -> number of rounds given by the server when typing username - its fixed for everybody and configurable by the server, also in articles i read about Lastpass they dont explain from where they receive the client side number of rounds...

so now we send auth_key as is to the server...

On my server side

now we are creating a new hash to compare the one inside the db. Why another hash? if i understand correctly we bind the hash for server side data, like a combination of a password (that only the user knows) and server data.

db_auth=PBKDF2(SHA256, auth_key, user_be_salt, 100,000+user_configurable_rounds)

user_be_salt -> a random number that saved in db known only to the server and the ones who obtain the database, this changes on every successful login.

user_configurable_rounds -> number of iterations, every user can choose the amount of iterations (like in Lastpass) so attacker need also to guess the number or iterations?

I would be happy to hear what do you think about this authentication system, if its wrong than explain to me why and tell me what Lastpass do because i did not understand their entire authentication flow.

Answer 1

Overall not bad, with a few flaws in the details.

• If last_login_fe_salt is random and changes each login, then the PBKDF2 result sent to the server fails. This needs to be stored in the server's record for that username and kept the same.

  • Rounds also needs to be kept the same, and stored per username, so you can change the defaults.
  • If you want the ability to change them, then you need to be able to send to the client TWO salt and TWO iteration counts; old and new; then you get back both results; run both through the server-side algorith, then validate the old result, and if valid, store the new result.

• Why aren't you using SHA-512? The 64-bit operations required decrease the margin of advantage GPU based attackers have over your CPU based systems.

• Don't hardcode the server side rounds of 100,000; if you really want this, then
  • store the system required server rounds and user required server rounds in separate fields
  • consider moving the user round count security addition to the client side; otherwise you're going to hit denial of service attacks by insane round counts using all your CPU!

Congratulations on choosing a well known iterated key password hashing function with reasonable round counts!