[Dovecot] Storing passwords encrypted... bcrypt?

[Ed W]

On 05/01/2012 01:19, Pascal Volk wrote:
> On 01/03/2012 09:40 PM Charles Marcus wrote:
>> Hi everyone,
>>
>> Was just perusing this article about how trivial it is to decrypt
>> passwords that are stored using most (standard) encryption methods (like
>> MD5), and was wondering - is it possible to use bcrypt with
>> dovecot+postfix+mysql (or posgres)?
> Yes it is possible to use bcrypt with dovecot. Currently you have only
> to write your password scheme plugin. The bcrypt algorithm is described
> at http://en.wikipedia.org/wiki/Bcrypt.
>
> If you are using Dovecot>= 2.0 'doveadm pw' supports the schemes:
>      *BSD:                     Blowfish-Crypt
>      *Linux (since glibc 2.7): SHA-256-Crypt and SHA-512-Crypt
> 	Some distributions have also added support for Blowfish-Crypt
> See also: doveadm-pw(1)
>
> If you are using Dovecot<  2.0 you can also use any of the algorithms
> supported by your system's libc. But then you have to prefix the hashes
> with {CRYPT} - not {{BLF,SHA256,SHA512}-CRYPT}.
>

I'm a bit late, but the above is absolutely correct

Basically the simplest solution is to pick a glibc which natively 
supports bcrypt (and the equivalent algorithm, but using SHA-256/512).  
Then you can effectively use any of these hashes in your 
/etc/{passwd,shadow} file.  With the hash testing native in your glibc 
then a bunch of applications automatically acquire the ability to test 
passwords stored in these hash formats, dovecot being one of them

To generate the hashes in that format, choose an appropriate library for 
your web interface or whatever generates the hashes for you.  There are 
even command line utilities (mkpasswd) to do this for you.  I forget the 
config knobs (/etc/logins.def ?), but it's entirely possible to also 
have all your normal /etc/shadow hashes generated in this format going 
forward if you wish

I posted some patches for uclibc recently for bcrypt and I think 
sha-256/512 already made it in.  I believe several of the big names have 
similar patches for glibc.


Just to attack some of the myths here:

- Salting passwords basically means adding some random garbage at the 
front of the password before hashing.
- Salting passwords prevents you using a big lookup table to cheat and 
instantly reverse the password
- Salting has very little ability to stop you bruteforcing the password, 
ie it takes around the same time to figure out the SHA or blowfish hash 
of every word in some dictionary, regardless of whether you use the raw 
word or the word with some garbage in front of it
- Using an iterated hash algorithm gives you a linear increase in 
difficulty in bruteforcing passwords.  So if you do a million iterations 
on each password, then it takes a million times longer to bruteforce 
(probably there are shortcuts to be discovered, assume that this is best 
case, but it's still a good improvement).
- Bear in mind that off the shelf GPU crackers will do of the order 
100-300 million hashes per second!!
     http://www.cryptohaze.com/multiforcer.php

The last statistic should be scary to someone who has some small 
knowledge of the number of unique words in the [english] language, even 
multiplying up for trivial permutations with numbers or punctuation...


So in conclusion: everyone who stores passwords in hash form should make 
their way in an orderly fashion towards the door if they don't currently 
use an iterated hash function.  No need to run, but it definitely should 
be on the todo list to apply where feasible.  BCrypt is very common and 
widely implemented, but it would seem logical to consider SHA-256/512 
(iterated) options where there is application support.

Note I personally believe there are valid reasons to store plaintext 
passwords - this seems to cause huge criticism due to the ensuing 
disaster which can happen if the database is pinched, but it does allow 
for enhanced security in the password exchange, so ultimately it depends 
on where your biggest risk lies...


Good luck

Ed W