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
