3
$\begingroup$

I'm creating a small messenger and I wanted to know if it makes sense to store user passwords double-hashed in our backend-database. I wanted the user the register in an app, which should save a hash of the password and login with this hash in our system, which should not save this (1st) hash, but should somehow hash it again.

This would prevent someone who somehow got a (doubled) hashed password from our database from logging in into our api (since he needs to provide the 1st hash) and also would allow the app to not store the passwords of the user in plain text.

Is this a good idea? Should I just stay with the first hash and not hash the password again when using it in our backend-db? I read that something like this might be insecure as hashes become less secure the more often you hash them again. Should I maybe use different hash-algorithms for both actions? Which algorithms should I use?

$\endgroup$
6
  • 3
    $\begingroup$ Please see How to securely hash passwords? from information security. $\endgroup$
    – kelalaka
    Apr 9, 2019 at 13:03
  • 1
    $\begingroup$ Instead of storing a hashed password, you could simply generate a new random authentication token with an expiration and store that. This would allow login timeouts and revocation. $\endgroup$ Apr 9, 2019 at 15:08
  • 1
    $\begingroup$ In most of cases, more than two time encryption(hashing) does not give strength, even it might be leave leakages. $\endgroup$ Apr 9, 2019 at 17:13
  • $\begingroup$ @ArsalanVahi Hashing and encryption are different things. $\endgroup$ Apr 11, 2019 at 21:10
  • $\begingroup$ @Future Security Can't we say "hashing is a type of non-key encryption "? $\endgroup$ Apr 11, 2019 at 22:06

1 Answer 1

4
$\begingroup$

I read that something like this might be insecure as hashes become less secure the more often you hash them again.

While this is technically true, you shouldn't worry about it. This paper has precise bounds on how bad it is to iterate a random function and with the iteration count $r<10$ as you are worrying right now this is a non-issue for security.

This would prevent someone who somehow got a (doubled) hashed password from our database from logging in into our api (since he needs to provide the 1st hash) and also would allow the app to not store the passwords of the user in plain text.

This is a good idea and also the ideal model of how client-side password hashing is supposed to work: You compute an (expensive) password hash on the client, send it to the server who then hashes (or somehow else one-way processes) it so that an attacker leaking the database doesn't get all the log-in hashes for free.

Should I maybe use different hash-algorithms for both actions?

Yes. As explained in the previous paragraph, you want to use a slow password-hashing scheme on the client, like Argon2 and then you can use a fast (normal) hash function on the server, like SHA3-256.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.