Moving old passwords to new hashing algorithm?

by

Normally it’s not necessary to reset the passwords, one can just wait until the user logs in the next time.

  1. First try to verify the entered password with the new algorithm. New passwords and already converted passwords will not take longer for verification then.
  2. If it does not match, compare it with the old hash algorithm.
  3. Should the old hash value match, then you can calculate and store the new hash, since you know the password then.

Every password-storing-system must have the option to switch to a better hash algorithm, your problem is not a one-time migration problem. Good password hash algorithms like BCrypt have a cost factor, from time to time you have to increase this cost factor (because of faster hardware), then you need the exact same procedure as you need for the migration.

Your option 2 with hashing the old hash is a good thing, if your first algorithm is really weak, and you want to give more protection immediately. In this case you can calculate a double-hash and replace the old hash in the database with the new double-hash.

$newHashToStoreInTheDb = new_hash($oldHashFromDb)

You should also mark this password-hash (see why), so you can recognize it as double-hash. This can be done in a separate database field, or you can include your own signature. Modern password hash functions also include a signature of the algorithm, so that they can upgrade to newer algorithms, and still can verify older hashes. The example shows the signature of a BCrypt hash:

$2y$10$nOUIs5kJ7naTuTFkBy1veuK0kSxUFXfuaOKdOKf9xYT0KKIGSJwFa
___
 |
 signature of hash-algorithm = 2y = BCrypt

The verification would run like this:

  1. Decide whether it is a double-hash.
  2. If it is a new hash, call the new hash-function to verify the entered password, and you are done.
  3. If it is a double-hash, compare it with the double-hash algorithm new_hash(old_hash($password)).
  4. Should the double-hash value match, then you can calculate and store the new hash.

More Related Contents:

  1. Disable browser ‘Save Password’ functionality
  2. Difference between Hashing a Password and Encrypting it
  3. Is “double hashing” a password less secure than just hashing it once?
  4. SHA512 vs. Blowfish and Bcrypt [closed]
  5. Encrypting/Hashing plain text passwords in database [closed]
  6. What algorithm should I use to hash passwords into my database? [duplicate]
  7. Best Practices: Salting & peppering passwords?
  8. Best way for a ‘forgot password’ implementation? [closed]
  9. Why not use MD5 for password hashing?
  10. Should I impose a maximum length on passwords?
  11. Do I need a “random salt” once per password or only once per database?
  12. How does the SQL injection from the “Bobby Tables” XKCD comic work?
  13. How can I store my users’ passwords safely?
  14. Are HTTP cookies port specific?
  15. Salt Generation and open source software
  16. Where to store JWT in browser? How to protect against CSRF?
  17. Remove Server Response Header IIS7
  18. Preferred Method of Storing Passwords In Database
  19. Is it safe to enable CORS to * for a public and readonly webservice?
  20. Securely Erasing Password in Memory (Python)
  21. Preventing Brute Force Logins on Websites
  22. Does HTML5 allow you to interact with local client files from within a browser
  23. Send mail via Gmail with PowerShell V2’s Send-MailMessage
  24. Is JSONP safe to use?
  25. Is it safe to enable ”Access-Control-Allow-Origin: *“ (wildcard) for a public and readonly webservice?
  26. Why not use HTTPS for everything?
  27. Where is the PEM file format specified?
  28. Difference between CSRF and X-CSRF-Token
  29. MD5 security is fine? [closed]
  30. How to protect against direct access to images? [closed]

Leave a Comment