4 ms·

HN, is this the consensus? I thought certain hashes worked fine when properly salted?

deleted 16y ago
[deleted]
frisco 16y ago
Yes, this is consensus. "Salting" isn't actually a real security practice. See: http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html http://chargen.matasano.com/chargen/2007/9/7/enough-with-the...
- aidenn0 16y ago
  That article actually states that salting is a real security practice, is a necessity, and that it's been in UNIX since 1976,
  - frisco 16y ago
    I was more talking about bcrypt being consensus with that post. Salting slows down cracking attempts by a factor of N where N is the length of the hash; md5 and sha1 are so fast that you shouldn't be banking on salting to protect you in 2010. Also, you should assume that if an attacker has your database (with salts), they also have your code, which tells them exactly how the salt was applied. In that case, salting doesn't slow you down at all.
    - bostonvaulter2 16y ago
      I think the point is that you should use bcrypt and salt at the same time.
      - tptacek 16y ago
        You don't need to do anything like that; bcrypt does all this stuff for you. Don't salt bcrypt.
        youngian 16y ago
        I think people would be a lot less confused if you said this first. Say "Don't salt bcrypt, bcrypt salts for you" and you'll have to explain yourself less.
    - jhchen 16y ago
      But you're talking about defending against brute force attacks? Salting's strength is in defending against rainbow tables. It seems the best policy at this point is to use both as they defend against different things and are not mutually exclusive.
      - tptacek 16y ago
        You don't need to do anything like that; bcrypt does all this stuff for you. Don't salt bcrypt.
  - tptacek 16y ago
    He may be saying that because I've been making fun of people who use the word "salt" (in most other situations, crypto people would call that a "nonce"); I have in the past made the point that real crypto people never say "salt". But then Eli Biham used the term extensively in his HAIFA framework and I lost the argument. I'll still make fun of the word (salt! smoked salt! peanut salt! hah!), but I can't say no crypto people use it. I wish they wouldn't, though.
    - eru 16y ago
      That argument sounds like the German balloon fliers, who insist that they "fahren" (drive) the balloon and don't "fliegen" (fly) it.
ax0n 16y ago
In a case like the Gawker incident, it isn't safe. If the source code to the password hashing algo is compromised (it was) then the salt becomes useless. In short, just use bcrypt.
- Xk 16y ago
  No. No no no. The source code to the hashing algorithm means nothing. It is already open source! The reason that the salt is there is to prevent against rainbow tables. The salting did NOT become useless. If they had not salted passwords, then many many more passwords would have been broken because instead of having to brute force each and every one, you'd just look it up in a massively large hash table.
  - deleted 16y ago
    [deleted]
  - deleted 16y ago
    [deleted]
  - jrockway 16y ago
    No, he thinks the salt is stored secretly in the source code. Of course, it's not; you store it right next to the hash so that you don't have to use the same salt for every password.
- aidenn0 16y ago
  Salting and choice of hashing algorithm are orthogonal. If it takes X amount of time to brute force a password of strength Y and you do salt, then an attacker can crack N passwords of strength Y in time NX. If you don't salt, then an attacker can crack all* passwords of strength Y in time N, which is a huge difference.
  - ax0n 16y ago
    Alas, I stand corrected. Thanks. At the same time, the author does have a good point that very slow algorithms are fundamentally better for security, but I'm glad you pointed this difference out. Classic case of me not thinking things all the way through.
sph 16y ago
The problem is that it's relatively easy to brute-force attack even a salted hash today. On the first day, people stored passwords in plain text. If someone got access to your database, they had all the passwords. On the second day, people decided to hash the passwords so that people couldn't unencrypt them. Then the attackers created rainbow tables that correlated each hash with its associated password since the password would always hash to the same value (so you have "109BCA" in your database, but they have a table that has that hash and that "12345" hashes to that value). On the third day, people decided to salt the hashes to render the rainbow tables ineffective. Now, each password would hash to a different value so they couldn't just look up the password for a given hash. However, as computing power increased it became easy to just brute-force the password. You have the hash and you have the salt so you can just try every password with the hash until you get a match. hashed_password = "ACBDEF1234567890" salt = "12345" possible_passwords = ["password1", "ilikesheep", "micro$oft"] possible_passwords.each do |pass| if Digest::SHA1.hexdigest("#{pass}#{salt}") == hashed_password real_password = pass end end The problem is that code like that has gotten really cheap to run and it's incredibly parallel (you can have loads of machines each take a piece of the workload - oh, and hopefully no one will make a joke that you'd never write that in Ruby; I just felt that would be easy pseudo-code to demonstrate). You can just try combinations of passwords at random, but there are lists of more common passwords that you can try first making it go even faster. Hashing algorithms are meant to be fast because they're meant to be usable on a large piece of data. As such, it also becomes fast to brute force check all sorts of combinations. On the fourth day, people started using things like bcrypt because bcrypt was made to be slow. The fact that bcrypt is slow means that if someone wants to brute force it, it will be very slow going for them. If one can check 10,000 SHA1 hashes in a second, but only 10 bcrypt hashes in a second, it will take 1,000x longer to crack the bcrypt stored password (those are just made-up numbers as an example). Salting is better than not salting because they have to brute force the password. However, as computing power increases it isn't so much better because brute forcing is becoming easy. One needs to use a slow algorithm to make sure that cracking it will also be slow (prohibitively slow). Bcrypt also allows you to specify how much work you want it to have to do. This way, as computing power increases, you can increase the amount of computing power needed to compute the bcrypt. By contrast, hashes are meant to go fast and so every day they're getting less secure.
amalcon 16y ago
The salt does exactly one thing: it makes the attacker pay to get each password, as opposed to making them pay once and get all of them. When the cost is a fraction of a second on a commodity CUDA setup, it's not really that helpful to make an attacker pay it multiple times.

deleted 16y ago

[deleted]

Yes, this is consensus. "Salting" isn't actually a real security practice. See: http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html http://chargen.matasano.com/chargen/2007/9/7/enough-with-the...

aidenn0 16y ago
That article actually states that salting is a real security practice, is a necessity, and that it's been in UNIX since 1976,
- frisco 16y ago
  I was more talking about bcrypt being consensus with that post. Salting slows down cracking attempts by a factor of N where N is the length of the hash; md5 and sha1 are so fast that you shouldn't be banking on salting to protect you in 2010. Also, you should assume that if an attacker has your database (with salts), they also have your code, which tells them exactly how the salt was applied. In that case, salting doesn't slow you down at all.
  - bostonvaulter2 16y ago
    I think the point is that you should use bcrypt and salt at the same time.
    - tptacek 16y ago
      You don't need to do anything like that; bcrypt does all this stuff for you. Don't salt bcrypt.
      - youngian 16y ago
        I think people would be a lot less confused if you said this first. Say "Don't salt bcrypt, bcrypt salts for you" and you'll have to explain yourself less.
  - jhchen 16y ago
    But you're talking about defending against brute force attacks? Salting's strength is in defending against rainbow tables. It seems the best policy at this point is to use both as they defend against different things and are not mutually exclusive.
    - tptacek 16y ago
      You don't need to do anything like that; bcrypt does all this stuff for you. Don't salt bcrypt.
- tptacek 16y ago
  He may be saying that because I've been making fun of people who use the word "salt" (in most other situations, crypto people would call that a "nonce"); I have in the past made the point that real crypto people never say "salt". But then Eli Biham used the term extensively in his HAIFA framework and I lost the argument. I'll still make fun of the word (salt! smoked salt! peanut salt! hah!), but I can't say no crypto people use it. I wish they wouldn't, though.
  - eru 16y ago
    That argument sounds like the German balloon fliers, who insist that they "fahren" (drive) the balloon and don't "fliegen" (fly) it.

ax0n 16y ago

In a case like the Gawker incident, it isn't safe. If the source code to the password hashing algo is compromised (it was) then the salt becomes useless. In short, just use bcrypt.

Xk 16y ago
No. No no no. The source code to the hashing algorithm means nothing. It is already open source! The reason that the salt is there is to prevent against rainbow tables. The salting did NOT become useless. If they had not salted passwords, then many many more passwords would have been broken because instead of having to brute force each and every one, you'd just look it up in a massively large hash table.
- deleted 16y ago
  [deleted]
- deleted 16y ago
  [deleted]
- jrockway 16y ago
  No, he thinks the salt is stored secretly in the source code. Of course, it's not; you store it right next to the hash so that you don't have to use the same salt for every password.
aidenn0 16y ago
Salting and choice of hashing algorithm are orthogonal. If it takes X amount of time to brute force a password of strength Y and you do salt, then an attacker can crack N passwords of strength Y in time NX. If you don't salt, then an attacker can crack all* passwords of strength Y in time N, which is a huge difference.
- ax0n 16y ago
  Alas, I stand corrected. Thanks. At the same time, the author does have a good point that very slow algorithms are fundamentally better for security, but I'm glad you pointed this difference out. Classic case of me not thinking things all the way through.

sph 16y ago

The problem is that it's relatively easy to brute-force attack even a salted hash today. On the first day, people stored passwords in plain text. If someone got access to your database, they had all the passwords. On the second day, people decided to hash the passwords so that people couldn't unencrypt them. Then the attackers created rainbow tables that correlated each hash with its associated password since the password would always hash to the same value (so you have "109BCA" in your database, but they have a table that has that hash and that "12345" hashes to that value). On the third day, people decided to salt the hashes to render the rainbow tables ineffective. Now, each password would hash to a different value so they couldn't just look up the password for a given hash. However, as computing power increased it became easy to just brute-force the password. You have the hash and you have the salt so you can just try every password with the hash until you get a match. hashed_password = "ACBDEF1234567890" salt = "12345" possible_passwords = ["password1", "ilikesheep", "micro$oft"] possible_passwords.each do |pass| if Digest::SHA1.hexdigest("#{pass}#{salt}") == hashed_password real_password = pass end end The problem is that code like that has gotten really cheap to run and it's incredibly parallel (you can have loads of machines each take a piece of the workload - oh, and hopefully no one will make a joke that you'd never write that in Ruby; I just felt that would be easy pseudo-code to demonstrate). You can just try combinations of passwords at random, but there are lists of more common passwords that you can try first making it go even faster. Hashing algorithms are meant to be fast because they're meant to be usable on a large piece of data. As such, it also becomes fast to brute force check all sorts of combinations. On the fourth day, people started using things like bcrypt because bcrypt was made to be slow. The fact that bcrypt is slow means that if someone wants to brute force it, it will be very slow going for them. If one can check 10,000 SHA1 hashes in a second, but only 10 bcrypt hashes in a second, it will take 1,000x longer to crack the bcrypt stored password (those are just made-up numbers as an example). Salting is better than not salting because they have to brute force the password. However, as computing power increases it isn't so much better because brute forcing is becoming easy. One needs to use a slow algorithm to make sure that cracking it will also be slow (prohibitively slow). Bcrypt also allows you to specify how much work you want it to have to do. This way, as computing power increases, you can increase the amount of computing power needed to compute the bcrypt. By contrast, hashes are meant to go fast and so every day they're getting less secure.

amalcon 16y ago

The salt does exactly one thing: it makes the attacker pay to get each password, as opposed to making them pay once and get all of them. When the cost is a fraction of a second on a commodity CUDA setup, it's not really that helpful to make an attacker pay it multiple times.