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