I am currently using SHA-512 with 100000 rounds because of the easier implementation. The algorithm generates passwords from a service (e.g amazon) and a master password. Would I benefit from switching to bcrypt/scrypt?

  • Are you using this to generate passwords, or to create storable hashes of them? If the latter, are you salting them? – Gordon Davisson Jul 8 '17 at 6:04
  • I am generating passwords from services (e.g. stackexchange) and a master password. – R3turnz Jul 8 '17 at 6:15

Based on clarification from the OP, I will change my answer.

So you're doing something equivalent to:

sha-512x100000("stackexchange.com"|"master password")

... that's really not a great idea. Your choice of hash function is not your biggest problem here. As an attacker, once I crack one of your passwords and recover the master password, it becomes trivial for me to crack all your other accounts.

I would suggest you switch to using passwords derived from /dev/random, or using a proper password manager.


Yes, please do not use SHA-X hash functions for password hashing. You'd be better to switch to something designed to be a password hashing function.

SHA-2 hashes (which include SHA-224, SHA-256, SHA-384, and SHA-512) were designed for performance: it was part of the design requirement that software and hardware implementations of these hash functions be as fast as possible. Assuming that your server is using a software implementation of SHA-512 and the attacker trying to brute-force the passwords is using either a GPU rig, or dedicated SHA-512 hardware, then you are giving the attacker an advantage over you because they can perform guesses with much higher efficiency than the server can generate the hashes in the first place.

In short, SHA hashes are designed to be fast - especially in hardware. A very bad property for a password hashing function.

bcrypt, scrypt, and to a lesser extent PBKDF2, are designed to be slow and inefficient in hardware -- very good properties for password hashing functions.

Of those three (bcrypt, scrypt, and PBKDF2) it looks like scrypt is the most modern and the best choice. Though, from the results of the 2013 - 2015 Password Hashing Competition, it seems that Argon2 (and the runner-ups Catena, Lyra2, yescrypt and Makwa) blow scrypt out of the water, so use one of those if you have it available.

  • Removed my answer as you have updated yours in response to the OP update. My answer no longer is relevant. Up voted yours. – ISMSDEV Jul 8 '17 at 6:28
  • 1
    Note that NIST corrently recommends PBKDF2 for password vitrification usage. – zaph Jul 8 '17 at 13:05
  • Minor nitpick: /dev/urandom is preferred over /dev/random - though in some implementations they are apparently the same (FreeBSD & macOS). – Sas3 Jul 8 '17 at 16:04
  • @Sas3 Yeah, minor and flame-war-y for sure. I think they're also the same in Solaris. The differences matters a lot on headless or embedded systems. On workstations with lots of human-input events (mouse / keyboard), /dev/random is more than good enough. – Mike Ounsworth Jul 8 '17 at 16:52
  • I like PBKDF2, it is easy to scale for more powerful CPU by adjusting number of cycles. – VovCA Jul 9 '17 at 22:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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