[Dovecot] bcypt availability

[Ed W]

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