* SHA-x is not an "encryption" algorithm, it's merely a cryptographically secure, one-way hash. The function name and the documentation are thus misleading.
* You shouldn't use SHA-x or MD5, etc. for password hashing anyway, because they are just way too fast! You should use BCrypt for password hashing.
Just out of interest, what do you mean by 'way too fast'? I would think that having a fast hash would be a good thing. Or is it because an attacker can generate hashes for some dictionary very fast? Isn't this why you'd use a salt as well?
Sorry if these seem like dumb questions, just trying to learn.
Hashing algorithms like SHA-256 have a very interesting property, they are designed to be extremely fast (even with large amounts of data). That lets you generate millions of hashes per second on any modern CPU (much faster with GPUs). Salting doesn't help much because if your DB is compromised, you are still open to brute force or dictionary attacks.
BCrypt is a very good algorithm for hashing passwords because it's very slow (compared to SHA-x) and thus are extremely time consuming for an attacker. BCrypt also allows to incorporate a "work-factor" which makes the hashing even slower; that allows us to choose a higher work factor when more powerful computers become commonplace.
There are a lot of articles online that discuss this subject.
No, this is technically wrong. There are better ways of stopping a brute-force attack on a password form, such as attack detection, and black-lists. If you rely on a computational delay to slow attackers down on your servers, you will merely open yourself to a simpler DDOS attack. The purpose of a computationally expensive hashing algorithm is that it prevents brute-force attacks against a stolen copy of your password database, where the attacker no longer has to deal with your other defenses.
The salt is usually in the db as you should have a different salt per password. The purpose of the salt is to add some complexity so that each password is in fact hashed by a slightly different algorithm (in order to defeat pre-computation based attacks.) If the attacker does not know that salt, then he does not know the full hash algorithm and cannot brute-force the password. So technically no, I don't think so. However, if the attacker can get your password db he can also get your salt db so I wouldn't rely on this by any means.
Disclaimer: I'm absolutely not a security professional.
It wouldn't, but it's a Bad Plan not to have per-user salt, so the circumstances where you'd have the passwords but not the salts that go with them would be... odd.
Thanks to you and astine, I just learned today about per-user salts. I thought that you only needed a site-wide salt and after reading on the topic, I now understand why it's better to have a per-user salt stored in the db.
I was also confused by these frameworks (e.g., Django) that ask you for a secret key and I thought that the secret key was a site-wide salt. Fortunately, they knew better than me ;-)
Comments
Still some nits -
* SHA-x is not an "encryption" algorithm, it's merely a cryptographically secure, one-way hash. The function name and the documentation are thus misleading.
* You shouldn't use SHA-x or MD5, etc. for password hashing anyway, because they are just way too fast! You should use BCrypt for password hashing.
I can submit patches if you wish :)
Just out of interest, what do you mean by 'way too fast'? I would think that having a fast hash would be a good thing. Or is it because an attacker can generate hashes for some dictionary very fast? Isn't this why you'd use a salt as well?
Sorry if these seem like dumb questions, just trying to learn.
Hashing algorithms like SHA-256 have a very interesting property, they are designed to be extremely fast (even with large amounts of data). That lets you generate millions of hashes per second on any modern CPU (much faster with GPUs). Salting doesn't help much because if your DB is compromised, you are still open to brute force or dictionary attacks.
BCrypt is a very good algorithm for hashing passwords because it's very slow (compared to SHA-x) and thus are extremely time consuming for an attacker. BCrypt also allows to incorporate a "work-factor" which makes the hashing even slower; that allows us to choose a higher work factor when more powerful computers become commonplace.
There are a lot of articles online that discuss this subject.
The faster you hash, the faster I can run a brute force attack on your password form.
No, this is technically wrong. There are better ways of stopping a brute-force attack on a password form, such as attack detection, and black-lists. If you rely on a computational delay to slow attackers down on your servers, you will merely open yourself to a simpler DDOS attack. The purpose of a computationally expensive hashing algorithm is that it prevents brute-force attacks against a stolen copy of your password database, where the attacker no longer has to deal with your other defenses.
Quick question, if you have the db but not the salt, does the speed of the hashing algorithm still matter?
The salt is usually in the db as you should have a different salt per password. The purpose of the salt is to add some complexity so that each password is in fact hashed by a slightly different algorithm (in order to defeat pre-computation based attacks.) If the attacker does not know that salt, then he does not know the full hash algorithm and cannot brute-force the password. So technically no, I don't think so. However, if the attacker can get your password db he can also get your salt db so I wouldn't rely on this by any means.
Disclaimer: I'm absolutely not a security professional.
It wouldn't, but it's a Bad Plan not to have per-user salt, so the circumstances where you'd have the passwords but not the salts that go with them would be... odd.
Thanks to you and astine, I just learned today about per-user salts. I thought that you only needed a site-wide salt and after reading on the topic, I now understand why it's better to have a per-user salt stored in the db.
I was also confused by these frameworks (e.g., Django) that ask you for a secret key and I thought that the secret key was a site-wide salt. Fortunately, they knew better than me ;-)
See http://codahale.com/how-to-safely-store-a-password/
Absolutely! I don't claim to be an encryption expert, by any means. :)
I am no crypto expert either, but here is your patch - https://github.com/ghoseb/noir/commit/f814ea9d1bc7470197eb73... (pull request already sent).
Noir looks very good. Keep up the good work and let me know if you need any help ;)