Live data from Hacker News

How To Safely Store A Password

codahale.com

21–30 of 219 posts

Re: How To Safely Store A Password

#21
post #10
post #2

I'm not so sure. The other side of the coin is that ``{MD5, SHA1, SHA256, SHA512, SHA-3, etc}'' have had extensive peer review in the cryptography world. There's a long history of ``clever new ways'' to use existing crypto algorithms turning out to have serious flaws -- a good example is early attempts to improve the strength of (56-bit key) DES by encrypting three times with three keys. This turns out to introduce e…

"A Future-Adaptable Password Scheme" by Provos and Mazieres. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.80.... An HTML version appears to be here: http://www.usenix.org/event/usenix99/provos/provos_html/node... Some of the links, particularly the main page, appear to be broken.

As with the website, that paper discusses only the speed of BCrypt. There is no cryptanalysis at all, and no indication that BCrypt was submitted anywhere for peer review of its cryptographic soundness.

This doesn't mean BCrypt is unsound. It does mean that I would want to see such analysis before using it.

Re: How To Safely Store A Password

#22
post #15
post #3

Earlier quoted context omitted.

No. Use Bcrypt. Always. Bcrypt is backed by Blowfish, designed by Bruce Schneier. Go look it/him up. It's secure. MD5/SHA1/etc are not weak because they are cryptographically weak (though some are), it is weak because they are fast. SHA3, when it is picked, will still be a very bad choice because it too will be fast. So, why Bcrypt? Well, it uses Blowfish. Blowfish has a very slow key scheduling algorithm which basic…

Question, I use SHA512 for my passwords; is that also "fast" in comparison to bcrypt?

SHA512 is very, very fast compared to Bcrypt. It's only slightly slower than SHA1 or SHA256.

Source: http://www.cryptopp.com/benchmarks.html

Re: How To Safely Store A Password

#23
post #15
post #3

Earlier quoted context omitted.

No. Use Bcrypt. Always. Bcrypt is backed by Blowfish, designed by Bruce Schneier. Go look it/him up. It's secure. MD5/SHA1/etc are not weak because they are cryptographically weak (though some are), it is weak because they are fast. SHA3, when it is picked, will still be a very bad choice because it too will be fast. So, why Bcrypt? Well, it uses Blowfish. Blowfish has a very slow key scheduling algorithm which basic…

Question, I use SHA512 for my passwords; is that also "fast" in comparison to bcrypt?

If I can believe this ( http://www.cryptopp.com/benchmarks.html ), SHA-512 can still hash data at tens to hundreds of megabytes per second on a single couple-year-old core. Bcrypt lets you configure the slowness of your key generation with a "work factor", so I suppose with a work factor of 1 it'd probably be pretty fast too, but with a work factor of 10 it takes me roughly 100ms to hash 1 10-byte password.

So yeah, SHA-512 gives you a much larger keyspace, which is awesome, but isn't demonstrably slower than MD5, SHA-1, etc. Which was one of its design goals (and also one of the goals of all entrants in the ongoing SHA-3 competition).

Re: How To Safely Store A Password

#24
post #11
post #3

Earlier quoted context omitted.

No. Use Bcrypt. Always. Bcrypt is backed by Blowfish, designed by Bruce Schneier. Go look it/him up. It's secure. MD5/SHA1/etc are not weak because they are cryptographically weak (though some are), it is weak because they are fast. SHA3, when it is picked, will still be a very bad choice because it too will be fast. So, why Bcrypt? Well, it uses Blowfish. Blowfish has a very slow key scheduling algorithm which basic…

The question is not whether BCrypt is backed by Blowfish, the question is whether BCrypt uses Blowfish in a way which is cryptographically sound. If it does not, then an attacker may not need to use brute force. Assuming the author has read more of Mr. Schneier's book than the quoted preamble, he should know this -- Schneier discusses this at length in both editions of Applied Cryptography . Again, an example of this…

Bcrypt has been around for ten years. No one has broken it yet. Is this perfect? No. But then again, we don't know that the implementation you would pick for MD5, SHA1, etc are perfect either. You take the best you can get.

Re: How To Safely Store A Password

#25
post #20
post #13

Earlier quoted context omitted.

Bcrypt is backed by Blowfish, designed by Bruce Schneier. Go look it/him up. It's secure. Well, yes, I trust the Blowfish cipher (and GP probably does too). The question is how we can be sure it isn't being somehow misapplied, i.e. whether the way bcrypt uses it opens some other hole. That's what I (and probably GP) would like to see an expert weigh in on.

Bcrypt is recommended by all the relevant experts who haven't heard of scrypt(1). Those who have(2), use scrypt because it's got a better built-in Moore's Law-defeater than bcrypt. (1) http://news.ycombinator.com/item?id=601408 (2) http://www.chromium.org/chromium-os/chromiumos-design-docs/p...

True. But this article was about Bcrypt, so I'm writing that instead of Scrypt.

Edit: I defer to tptacek.

Re: How To Safely Store A Password

#26

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

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.

Re: How To Safely Store A Password

#27

"It’s important to note that salts are useless for preventing dictionary attacks or brute force attacks. You can use huge salts or many salts or hand-harvested, shade-grown, organic Himalayan pink salt. It doesn’t affect how fast an attacker can try a candidate password, given the hash and the salt from your database." Why are you storing the whole salt in your database? Isn't it much more common to keep half of it i…

If you want to crack passwords ultrafast, you make a look-up table of the hashes of all probable passwords. Without a salt, this is rather a smaller table. A 7-bit salt makes the table larger, but not hugely larger, and not troublesomely larger.

The 128-bit salt used by bcrypt makes the table intractably hugely large. You cannot precompute it.

Of course, you know the salt (because it's stored right there in /etc/shadow), so you can still run through dictionary words and try them all. But bcrypt is designed to take arbitrarily long amounts of real time to do this.

So in the case of bcrypt, it's not really an issue that the salt is stored right there alongside the hashes password.

Re: How To Safely Store A Password

#28
post #17
post #7

Earlier quoted context omitted.

Yes, this is consensus. "Salting" isn't actually a real security practice. See: http://chargen.matasano.com/chargen/2007/9/7/enough-with-the...

That article actually states that salting is a real security practice, is a necessity, and that it's been in UNIX since 1976,

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.

Re: How To Safely Store A Password

#29

"It’s important to note that salts are useless for preventing dictionary attacks or brute force attacks. You can use huge salts or many salts or hand-harvested, shade-grown, organic Himalayan pink salt. It doesn’t affect how fast an attacker can try a candidate password, given the hash and the salt from your database." Why are you storing the whole salt in your database? Isn't it much more common to keep half of it i…

I may be mistaken, as I was only browsing. I was looking at Django's auth system last night (as all of this had me curious about the backend). I don't think that SECRET_KEY is used for part of the salt at all, I think it's primarily used for validation of site-generated data, signing requests, and cookie encoding/decoding.

Re: How To Safely Store A Password

#30

"It’s important to note that salts are useless for preventing dictionary attacks or brute force attacks. You can use huge salts or many salts or hand-harvested, shade-grown, organic Himalayan pink salt. It doesn’t affect how fast an attacker can try a candidate password, given the hash and the salt from your database." Why are you storing the whole salt in your database? Isn't it much more common to keep half of it i…

That salt is a public value. The security of salted password schemes is meant not to depend on the secrecy of the salt.

Every time this topic comes up, 15 people chime in with various schemes in which some of the "salt" is derived from the hostname and some of it is stored in an encrypted vault and some of it is inferred from the color of the user's eyes. This is why Coda is making fun of "Himalayan pink salt".

To understand how irrelevant these details are, consider AES encryption. In addition to hiding an AES key, you can also hide portions of the AES CBC IV (a public value). You could use a random number of rounds. You could mix in tweaks with the round key. All of these things are possible, but (a) nobody analyzes AES based on those random hacks, because they don't fundamentally alter the properties of AES, and (b) nobody does those things, because they are silly.

Gawker could use the best conceivable practices in cryptography to obscure passwords; they could be using Colin Percival's scrypt function (which nobody uses yet) to be (in some way) provably resilient to hardware-assisted cracking. You could still level this criticism at them, for "not doing something to further obscure the encryption they used".

This is not a new argument; what I am re-explaining here is Kerckhoffs' principle.

Post reply on HN