Linked by Thom Holwerda on Mon 4th Jul 2011 21:43 UTC
Thread beginning with comment 479947
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/20/13 22:43 UTC
Linked by Thom Holwerda on 05/20/13 21:50 UTC
Linked by Thom Holwerda on 05/19/13 23:15 UTC
Linked by Thom Holwerda on 05/19/13 23:11 UTC, submitted by Drumhellar
Linked by Thom Holwerda on 05/18/13 21:06 UTC
Linked by Thom Holwerda on 05/18/13 7:37 UTC
Linked by fran on 05/18/13 1:38 UTC
Linked by Thom Holwerda on 05/17/13 23:35 UTC, submitted by kragil
Linked by MOS6510 on 05/17/13 22:22 UTC
Linked by Thom Holwerda on 05/17/13 22:15 UTC, submitted by Tom
More News »
Sponsored Links



Member since:
2011-01-28
Soulbender,
I did some research on bcrypt. I guess I should have realized that you were talking about a replacement for the original unix crypt, which is surprisingly still very common.
bcrypt is designed to impede brute force scanning by slowing down forward hash computation. It also uses a large salt size, unlike crypt which is embarrassingly small with only 4096 possibilities.
http://www.openbsd.org/papers/bcrypt-paper.ps
"Bcrypt uses a 128bit salt and encrypts a 192bit magic value. It takes advantage of the expensive key setup in eksblowfish"
It repeatedly encrypts the cleartext 64 times and has a specifiable cost parameter to slow down the hashing further.
Along the way I came across another "scrypt" which is said to be better than bcrypt on account of being not only computationally intense, but also by having much higher ram/state requirements. This is said to make custom ASIC processor design that much more difficult, since these often have limited states.
I think both of these would be fine for password hashing.
I still consider H(salt+password) to be vulnerable against moderately resourceful attackers since forward hashing is way too quick.