211–215 of 215 posts
To see if I understand bcrypt correctly, would this pseudo code achieve a similar adaptable computational cost? function(uniqueSalt128Bit, password, rounds) { var hash = SHA1(uniqueSalt128Bit + password); var length = Math.pow(2, rounds); while (length--) hash = SHA1(hash); return hash; }
Earlier quoted context omitted.
What about Debian's reason for not using bcrypt, claiming the time it takes to hash is not a weak point in security of /etc/shadow? http://groups.google.com/group/linux.debian.user/browse_thre...
DISCLAIMER: I'm a web developer, not a cryptographer. I've had a passing interest in cryptography for the last few months, but I've never worked in the field. I learned about it by reading Cryptography Engineering (great book) and various HN comments and blog posts. So take the following with a grain of salt... and I hope someone knowledgeable can chime in. That being said, let's roll. > What about Debian's reason fo…
the only argument i've heard is that sha-2 can be implemented in specialized hardware (well-funded attacker) that is much much faster than CPU/GPU, whereas this is not as easy for bcrypt?
however, with multi-iteration hashing, you can strengthen the hash further w/o the user having to log in again.
Earlier quoted context omitted.
DISCLAIMER: I'm a web developer, not a cryptographer. I've had a passing interest in cryptography for the last few months, but I've never worked in the field. I learned about it by reading Cryptography Engineering (great book) and various HN comments and blog posts. So take the following with a grain of salt... and I hope someone knowledgeable can chime in. That being said, let's roll. > What about Debian's reason fo…
Thank you, that is an excellent reply, covering all of the main points raised in the link. My impression is that SHA512 with 5000 rounds is competitive with bcrypt (per Schneier in February, at least). But ... this is not the default on Debian, DES is, which I understand is not remotely competitive with bcrypt. I checked my server, and it uses the default DES... time to harden the passwords. Refs 1. SHA512 vs. Blowfi…
- when a webapp loses its user table, the devs will be responsible for compromising thousands of password (which user often re-use elsewhere). This is what happened with the Gawker hack and the recent lulzsec database dumps.
- when somebody accesses your /etc/shadow file, he likely already has root access to your machine, so you are pretty much owned anyway. Protecting your password might help a little, but it's less useful than in the above case.
tptacek talked a little about this in one of the posts I linked above: http://news.ycombinator.com/item?id=1091445
------------------------
Now, to address your point: stretched SHA512 (SHA512 iterated 5000 times) is indeed a lot better than calling SHA512 once. But bcrypt still has some advantages over it by design, which makes it even better for password hashing. Some links:
http://news.ycombinator.com/item?id=1091465
http://news.ycombinator.com/item?id=995685
http://chargen.matasano.com/chargen/2007/9/7/enough-with-the...
------------------------
Regarding your second link (Schneier on SHA-512 variants), I don't see anything about bcrypt or password hashing there. He talks about the advances of hash functions, but those are fast hash functions. Fast hash functions are very useful in cryptography, but they are the opposite of what you want for a password hashing scheme.
Earlier quoted context omitted.
DISCLAIMER: I'm a web developer, not a cryptographer. I've had a passing interest in cryptography for the last few months, but I've never worked in the field. I learned about it by reading Cryptography Engineering (great book) and various HN comments and blog posts. So take the following with a grain of salt... and I hope someone knowledgeable can chime in. That being said, let's roll. > What about Debian's reason fo…
why is multi-iteration sha-2 less ideal than bcrypt, even if the work factors between the two are calibrated to require the same amount of computation? the only argument i've heard is that sha-2 can be implemented in specialized hardware (well-funded attacker) that is much much faster than CPU/GPU, whereas this is not as easy for bcrypt? however, with multi-iteration hashing, you can strengthen the hash further w/o t…
http://news.ycombinator.com/item?id=1091465
> the only argument i've heard is that sha-2 can be implemented in specialized hardware (well-funded attacker) that is much much faster than CPU/GPU, whereas this is not as easy for bcrypt?
Yep. I think that's one of the main reasons. As tptacek said in the above link:
"There's a difference: bcrypt (and moreso scrypt) were designed to be hard to speed up, while SHA1 was designed at least in part to be easy to speed up."
In my opinion, the main advantage of bcrypt is the simplicity. It handles everything for you: salting, "slow" hashing, password checking. You simply have to specify a work factor and you are good to go. No need to implement any crypto yourself.
> however, with multi-iteration hashing, you can strengthen the hash further w/o the user having to log in again.
That's a very good point, I hadn't thought about that. I wonder if we can do this with bcrypt too.
IMO, as long as you use either bcrypt, scrypt, PBKDF2, or password stretching, you are good to go...
For PHP users, phpass is a really nice password library. http://www.openwall.com/phpass/