3 ms·

HULK SMASH SHA1 FOR PASSWORDS! No seriously, before you get like a million users you should switch to a much slower hashing alg that's designed for passwords,

by jayferd 14y ago

HULK SMASH SHA1 FOR PASSWORDS! No seriously, before you get like a million users you should switch to a much slower hashing alg that's designed for passwords, not for checksums. Scrypt is good, bcrypt is good, and there are a few others. But here's a(n?) scrypt package on Haskell that will do it for you and has a really nicely designed API: http://hackage.haskell.org/packages/archive/scrypt/0.3.1/doc/html/Crypto-Scrypt.html http://hackage.haskell.org/packages/archive/scrypt/0.3.1/doc...

thirsteh 14y ago
Yes, the scrypt package's PasswordHash API is great, akin to bcrypt (http://hackage.haskell.org/packages/archive/bcrypt/0.0.4/doc/html/Crypto-BCrypt.html http://hackage.haskell.org/packages/archive/bcrypt/0.0.4/doc...). Just ignore the terminology used ("encryptPassword", "password encryption", etc.) Why: http://throwingfire.com/storing-passwords-securely/#notpasswordhashes http://throwingfire.com/storing-passwords-securely/#notpassw...
chongli 14y ago
Could you explain a little more about why you need a slower algorithm? How is anyone going to crack a well-salted SHA1 password?
- pixl97 14y ago
  http://hashcat.net/oclhashcat-lite/ http://hashcat.net/oclhashcat-lite/ 2800M/s SHA1 hashes on a ATI HD 7970. vs http://stackoverflow.com/questions/11298184/about-how-fast-can-you-brute-force-pbkdf2 http://stackoverflow.com/questions/11298184/about-how-fast-c... PBKDF2 is still very much harder to crack then SHA1 with any reasonable length of salt.
- g_lined 14y ago
  It is increasingly trivial to try millions or billions of hashes per second. Using scrypt forces the computer to use more resources (in this case, memory in particular) which means that scaling the guess rate is orders of magnitude slower and cannot be significantly increased by building faster computers (because it's limited by memory not process speed). http://en.wikipedia.org/wiki/Scrypt http://en.wikipedia.org/wiki/Scrypt It comes down to this: Why use something which is designed for speed like hashes to do something that can be broken by highspeed guessing?
  - chongli 14y ago
    >Why use something which is designed for speed like hashes to do something that can be broken by highspeed guessing? Perhaps you have hundreds of millions of users? The slower your hash algorithm the more resources it takes to run it.
    - jlgreco 14y ago
      At hundreds of millions of users, I rather suspect resources spent on password hashing are going to be low on the list of concerns.
- amalcon 14y ago
  By brute-forcing it using GPUs. With a consumer-quality graphics card, anyone can try thousands of variations on every word in the dictionary in a few seconds. Common passwords that are not related to dictionary words (such as numbers and dates) take an ignorable amount of time longer. While you may use better passwords than this, it's certain that some of your users do not.
- jayferd 14y ago
  The key is that you want an alg designed for passwords, not for checksums. The design goals of each are very different.

by jayferd 14y ago

thirsteh 14y ago

Yes, the scrypt package's PasswordHash API is great, akin to bcrypt (http://hackage.haskell.org/packages/archive/bcrypt/0.0.4/doc/html/Crypto-BCrypt.html http://hackage.haskell.org/packages/archive/bcrypt/0.0.4/doc...). Just ignore the terminology used ("encryptPassword", "password encryption", etc.) Why: http://throwingfire.com/storing-passwords-securely/#notpasswordhashes http://throwingfire.com/storing-passwords-securely/#notpassw...

chongli 14y ago

Could you explain a little more about why you need a slower algorithm? How is anyone going to crack a well-salted SHA1 password?

pixl97 14y ago
http://hashcat.net/oclhashcat-lite/ http://hashcat.net/oclhashcat-lite/ 2800M/s SHA1 hashes on a ATI HD 7970. vs http://stackoverflow.com/questions/11298184/about-how-fast-can-you-brute-force-pbkdf2 http://stackoverflow.com/questions/11298184/about-how-fast-c... PBKDF2 is still very much harder to crack then SHA1 with any reasonable length of salt.
g_lined 14y ago
It is increasingly trivial to try millions or billions of hashes per second. Using scrypt forces the computer to use more resources (in this case, memory in particular) which means that scaling the guess rate is orders of magnitude slower and cannot be significantly increased by building faster computers (because it's limited by memory not process speed). http://en.wikipedia.org/wiki/Scrypt http://en.wikipedia.org/wiki/Scrypt It comes down to this: Why use something which is designed for speed like hashes to do something that can be broken by highspeed guessing?
- chongli 14y ago
  >Why use something which is designed for speed like hashes to do something that can be broken by highspeed guessing? Perhaps you have hundreds of millions of users? The slower your hash algorithm the more resources it takes to run it.
  - jlgreco 14y ago
    At hundreds of millions of users, I rather suspect resources spent on password hashing are going to be low on the list of concerns.
amalcon 14y ago
By brute-forcing it using GPUs. With a consumer-quality graphics card, anyone can try thousands of variations on every word in the dictionary in a few seconds. Common passwords that are not related to dictionary words (such as numbers and dates) take an ignorable amount of time longer. While you may use better passwords than this, it's certain that some of your users do not.
jayferd 14y ago
The key is that you want an alg designed for passwords, not for checksums. The design goals of each are very different.