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