On 7/15/2012 2:14 AM, Ed W wrote:

Interestingly, there doesn't seem to be so much difference between iterated sha-512 (sha512crypt) and bcrypt. Based on looking at latest john the ripper results (although I'm a bit confused because they don't seem to quote the baseline results using the normal default number of rounds?)

So I think right now, many/most modern glibc are shipping with sha256/512crypt implementations (recently uclibc also added this).

Indeed. What I have seen is a create deal of variation in the configuration (/etc/login.defs or your distro's equivalent) in terms of making use of such things.

I don't see any added value to bcrypt over iterated SHA-512, really, and while I don't even pretend to claim I've looked at all distros, even "old-school" ones like Slackware have full support for it. I suspect many admins doubt this because of configurations that don't make use of the modern hashing functionality.

Converting shadow files and/or login.defs would seem to be the bulk of the SysAdmin work to beef up the protection to bcrypt levels here.

Remember to keep this in perspective though - as the nature of this "vulnerability" extends to the case where your shadow file's hashes have been cloned, meaning a root-compromise or local device clone/access was made of it, etc.

=R=

On 16/07/2012 11:05, Noel Butler wrote:

On Sun, 2012-07-15 at 11:32 -0700, Robin wrote:

...

Indeed. What I have seen is a create deal of variation in the configuration (/etc/login.defs or your distro's equivalent) in terms of making use of such things.

I don't see any added value to bcrypt over iterated SHA-512, really, and

bcrypt and scrypt are password hash's - they are designed to be slow md5/sha/sha2 are cryptographic hash's - they are designed to be fast

But the hash under discussion is sha256crypt, which is a "slow hash" built using sha256 (there is also an sha512crypt)

However, if you keep your database secure, yes, this means using competent coders, then it matters little what method you use.

Yes, but the basis for our discussion is that decent companies with a security budget and reputation to protect have made mistakes, it would be foolish to assume that all our own machines are so much better... The topic is about assuming something goes wrong and a compromise occurs, ie security in depth

Today the speeds on single cpus for bcrypt/sha512crypt are in "under 1,000 checks per second" kind of range, so given 4-8 cores per processor you end up with cracking around the "under 10,000 checks per second" kind of range. At present GPUs can test sha512 approx 5x faster than a multicore processor using the latest john the ripper code http://openwall.info/wiki/john/OpenCL-SHA-512

At present bcrypt on GPU is tested at around the same speed as a multicore processor, but a) it's often easier to add multiple GPUs to build a distributed cracker, b) there are estimated performance improvements possible with newer GPUs (bcrypt tries to muddle memory a lot to slow things down, but it doesn't actually do enough to prevent implementation on GPUs). A rough estimate suggested that an upper bound of up to a 10x performance improvement might be possible with the bcrypt on GPU code (probably less, that is a straight instruction for instruction estimate)

So at present it seems like sha512crypt is slightly weaker than bcrypt, work will continue on sha256 on GPU in particular (bitcoin...) and can only get faster, possibly this work will benefit sha512 cracking speeds also. However, likely also bcrypt cracking speeds can be improved to within an order of magnitude of sha512 and so they are only a small constant multiple different in performance (change your work factor to make them equivalent...)

So my opinion has gone back to being satisfied with sha512crypt.

Unfortunately though sha512crypt with default 5,000 rounds is still being broken at rates of 10,000 checks a second on latest GPUs and I personally had a lot of success in the 1990s with dictionaries and breaking original DES crypt at <200 checks a second.... I think if possible it would be desirable to increase the default work factor to something higher than the default, 10,000 checks a second will give up a lot of real user passwords in a reasonable length of time (real users are going to have simple derivatives of dictionary words)

Good luck

Ed W