Re: [Dovecot] Storing passwords encrypted... bcrypt?
On Tue, Jan 17, 2012 at 12:22:35AM +, Ed W wrote: > 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... Exactly. In any security decision, consider the threat model first. There are too many kneejerk "secure" ideas in circulation. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: [Dovecot] Storing passwords encrypted... bcrypt?
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
Re: [Dovecot] Storing passwords encrypted... bcrypt?
On 01/05/2012 12:31 PM Charles Marcus wrote: > … > You said above that 'yes, I can use it with dovecot' - but what about > postfix and mysql... where/how do they fit into this mix? My thought was > that there are two issues here: > > 1. Storing them in bcrypted form, and For MySQL the bcrypted password is just a varchar. > 2. The clients must support *decrypting* them... Sorry, i don't know if clients need to know anything about the used password scheme. The used password scheme is mostly relevant for Dovecot. Don't mix password scheme and authentication scheme. > So, since I use postfixadmin, I'm guessing that for #1, it will have to > support encrypting them in bcrypt form, and then I have to worry about > dovecot - and since I'm planning on using postfix+dovecot-sasl, once > dovecot supports it, postfix will too... > > Is that about right? I think that's correct. Postfix uses Dovecot for the authentication stuff. If I'm wrong, please let me know it. Regards, Pascal -- The trapper recommends today: c01dcafe.1200...@localdomain.org
Re: [Dovecot] Storing passwords encrypted... bcrypt?
On 01/05/2012 11:36 AM, Charles Marcus wrote: On 2012-01-05 11:21 AM, Willie Gillespie wrote: If the phone knows the password and I have the phone, then I have the password. Similarly, if I compromise the workstation that knows the password, then I also have the password. Interesting... I thought they were stored encrypted. I definitely use a (strong) Master Password in Thunderbird to protect the passwords, so it would take some doing on the workstations. True. If you are using a master password, they are encrypted.
Re: [Dovecot] Storing passwords encrypted... bcrypt?
On 01/05/2012 01:37 PM, Charles Marcus wrote: > On 2012-01-05 11:31 AM, Michael Orlitzky wrote: >> Ugh, sorry. I went to the link that someone else quoted: >> >>https://www.grc.com/haystack.htm > >> Gibson*is* a renowned crackpot. > > Don't know about that, but I do know from long experience Spinrite rocks! > > Maybe he often piggybacks on common sense but makes it into an elaborate grandiose presentation. a lot of his topics tend to wander out to left field come half-time. -d
Re: [Dovecot] Storing passwords encrypted... bcrypt?
On 2012-01-05 11:31 AM, Michael Orlitzky wrote: Ugh, sorry. I went to the link that someone else quoted: https://www.grc.com/haystack.htm Gibson*is* a renowned crackpot. Don't know about that, but I do know from long experience Spinrite rocks! Maybe -- Best regards, Charles
Re: [Dovecot] Storing passwords encrypted... bcrypt?
On 2012-01-05 11:21 AM, Willie Gillespie wrote: If the phone knows the password and I have the phone, then I have the password. Similarly, if I compromise the workstation that knows the password, then I also have the password. Interesting... I thought they were stored encrypted. I definitely use a (strong) Master Password in Thunderbird to protect the passwords, so it would take some doing on the workstations. Even if the user doesn't know the password, the phone/workstation does. And it has to be stored in a retrievable way. Yes, if an attacker has unfettered physical access to the workstation/phone, it can be compromised... That's what he's trying to say when he was talking about a "$400 post-it note." Got it... As I said, there is no perfect system... but ours has worked well in the 11+ years we've been doing it this way. -- Best regards, Charles
Re: [Dovecot] Storing passwords encrypted... bcrypt?
On 01/05/12 11:14, Charles Marcus wrote: > > Ummm... yes, he does... from tfa: > > "Salts Will Not Help You > > It’s important to note that salts are useless for preventing dictionary > attacks or brute force attacks. You can use huge salts or many salts or > hand-harvested, shade-grown, organic Himalayan pink salt. It doesn’t > affect how fast an attacker can try a candidate password, given the hash > and the salt from your database. > > Salt or no, if you’re using a general-purpose hash function designed for > speed you’re well and truly effed." Ugh, sorry. I went to the link that someone else quoted: https://www.grc.com/haystack.htm The article you posted is correct. Salt will not prevent brute-force search, but it isn't meant to. Salt is meant to prevent the attacker from using precomputed tables of hashed passwords, called rainbow tables. To prevent brute-force search, you use a better algorithm, like the author says. >> but he's a crackpot anyway. Gibson *is* a renowned crackpot. > Why? I asked because I'm genuinely unsure (don't know enough about the > innards of the different encryption methods), and that's why I asked. > Simply saying he's a crackpot means nothing. > > Also... > >> Use a slow algorithm (others already mentioned bcrypt)to prevent >> brute-force search, > > Actually, that (bcrypt) is precisely what *the author of the article* > (the one who you are saying is a crackpot) is suggesting to use - I > guess you didn't even bother to read it or else you'd know that, so why > bother commenting? Again, sorry, I don't always know how to work my email client. > > I don't see it as an extraordinary claim, and anyone who goes around > claiming someone else is a crackpot without evidence to support the > claim is just yammering. > Your article is fine, but you should always be skeptical because for every article like the one you posted, there are 100 like Gibson's. > > No, they don't, your claim is baseless and without merit. > > Most people have never even known what their password *is*, much less > written it down, because as I said (more than once), *I* set up their > email clients (workstations, home computers and phones) *for them*. > The password is on the phone, in plain text. If I have the phone, I can read it as easily as if it was written in sharpie.
Re: [Dovecot] Storing passwords encrypted... bcrypt?
On 1/5/2012 9:14 AM, Charles Marcus wrote: On 2012-01-05 10:28 AM, Michael Orlitzky wrote: On 01/05/12 06:26, Charles Marcus wrote: You realize they're just walking around with a $400 post-it note with the password written on it, right? Nope, you are wrong - as I have patiently explained before. They do not *need* to write their password down. They have them written down on their phones. If someone gets a hold of the phone, he can just read the password off of it. No, they don't, your claim is baseless and without merit. Most people have never even known what their password *is*, much less written it down, because as I said (more than once), *I* set up their email clients (workstations, home computers and phones) *for them*. If the phone knows the password and I have the phone, then I have the password. Similarly, if I compromise the workstation that knows the password, then I also have the password. Even if the user doesn't know the password, the phone/workstation does. And it has to be stored in a retrievable way. That's what he's trying to say when he was talking about a "$400 post-it note."
Re: [Dovecot] Storing passwords encrypted... bcrypt?
On 2012-01-05 10:28 AM, Michael Orlitzky wrote: On 01/05/12 06:26, Charles Marcus wrote: To prevent rainbow table attacks, salt your passwords. You can make them a little bit more difficult in plenty of ways, but salt is the /solution/. Go read that link (you obviously didn't yet, because he claims that salting passwords is next to *useless*... He doesn't claim that, Ummm... yes, he does... from tfa: "Salts Will Not Help You It’s important to note that salts are useless for preventing dictionary attacks or brute force attacks. You can use huge salts or many salts or hand-harvested, shade-grown, organic Himalayan pink salt. It doesn’t affect how fast an attacker can try a candidate password, given the hash and the salt from your database. Salt or no, if you’re using a general-purpose hash function designed for speed you’re well and truly effed." but he's a crackpot anyway. Why? I asked because I'm genuinely unsure (don't know enough about the innards of the different encryption methods), and that's why I asked. Simply saying he's a crackpot means nothing. Also... Use a slow algorithm (others already mentioned bcrypt)to prevent > brute-force search, Actually, that (bcrypt) is precisely what *the author of the article* (the one who you are saying is a crackpot) is suggesting to use - I guess you didn't even bother to read it or else you'd know that, so why bother commenting? and use salt to prevent pre-computed lookups. Anyone who tells you otherwise can probably be ignored. Extraordinary claims require extraordinary evidence. I don't see it as an extraordinary claim, and anyone who goes around claiming someone else is a crackpot without evidence to support the claim is just yammering. You realize they're just walking around with a $400 post-it note with the password written on it, right? Nope, you are wrong - as I have patiently explained before. They do not *need* to write their password down. They have them written down on their phones. If someone gets a hold of the phone, he can just read the password off of it. No, they don't, your claim is baseless and without merit. Most people have never even known what their password *is*, much less written it down, because as I said (more than once), *I* set up their email clients (workstations, home computers and phones) *for them*. -- Best regards, Charles
Re: [Dovecot] Storing passwords encrypted... bcrypt?
On 01/05/12 10:28, Michael Orlitzky wrote: >> >> Nope, you are wrong - as I have patiently explained before. They do not >> *need* to write their password down. >> > > They have them written down on their phones. If someone gets a hold of > the phone, he can just read the password off of it. I should point out, I don't think this is a bad thing!
Re: [Dovecot] Storing passwords encrypted... bcrypt?
On 01/04/12 21:06, Patrick Domack wrote: > > But still, the results are all the same, if they get the hash, it can be > broken, given time. Using more cpu expensive methods make it take longer > (like adding salt, more complex hash). But the end result is they will > have it if they want it. > Unless someone breaks either math or the hash algorithm, this is false. My password will be of little use to you in 10^20 years.
Re: [Dovecot] Storing passwords encrypted... bcrypt?
On 01/05/12 06:26, Charles Marcus wrote: > >> To prevent rainbow table attacks, salt your passwords. You can make them >> a little bit more difficult in plenty of ways, but salt is the >> /solution/. > > Go read that link (you obviously didn't yet, because he claims that > salting passwords is next to *useless*... > He doesn't claim that, but he's a crackpot anyway. Use a slow algorithm (others already mentioned bcrypt) to prevent brute-force search, and use salt to prevent pre-computed lookups. Anyone who tells you otherwise can probably be ignored. Extraordinary claims require extraordinary evidence. >> You realize they're just walking around with a $400 post-it note with >> the password written on it, right? > > Nope, you are wrong - as I have patiently explained before. They do not > *need* to write their password down. > They have them written down on their phones. If someone gets a hold of the phone, he can just read the password off of it.
Re: [Dovecot] Storing passwords encrypted... bcrypt?
Quoting Noel Butler : On Thu, 2012-01-05 at 04:05 +0100, Pascal Volk wrote: On 01/05/2012 03:36 AM Noel Butler wrote: > > Because with multiple servers, we store them all in (replicated) > mysql :) (the same with postfix/dovecot). > and as I'm sure you are aware, Apache does not understand standard > crypted MD5, hence why there is the second option of apache_md5_crypt() Oh, let me guess: You are using Windows, Netware, TPF as OS for your web servers? ;-) man htpasswd | grep -- '-d ' -d Use crypt() encryption for passwords. This is not supported by the httpd server on Windows and Netware and TPF. As you may have seen in my previous mail, the password is generated using crypt(). HTTP Authentication works with that password hash, even with the httpd from the ASF. I think you need to do some homework, and although I now have 3.25 days of holidays remaining, I don't intend to waste them educating anybody hehe. Assuming you even know what I'm talking about, which I suspect you don't since you keep using console commands and things like htpasswd, which does not write to a mysql db, you don't seem to have comprehended that I do not work with flat files nor local so it is irrelevant, I use perl scripts for all systems management, so I hope you are not going to suggest that I should make a system call when I can do it natively in perl. But please, by all means, create a mysql db using a system crpyted md5 password, I'll even help ya, openssl passwd -1 foobartilly $1$e3a.f3uW$SYRQiMlEhC5XlnSxtxiNC/ pop the entry into the db and go for your life trying to authenticate. and when you've gone through half bottle of bourbon trying to figure out why its not working, try the apache crypted md5 version $apr1$yKxk.DrQ $ybcmM8mC1qD5t5FvoY9820 Mysql supports crypt right in it, so you can just submit the password to the mysql crypt function. We know perl has to support it also. The first thing I did when I was hired was to convert the password database from md5 to $6$. After that, I secured the machines that could and majorly limited what ones of them could get access to the list. About a month or two after this, we had about a thousand accounts compromised. So someone obviously got the list in how the old system was set, as every compromised password contains only lowercase letters less than 8 long. I wont say salted anything is bad, but keep the salt lengths up. Start with 8bytes atleast. crypts new option to support rounds also makes it a lot of fun, too bad I haven't seen consistant support for it yet, so I haven't been able to make use of that option.
Re: [Dovecot] Storing passwords encrypted... bcrypt?
On 2012-01-04 8:19 PM, 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}.
Hmmm... thanks very much Pascal, I think that gets me half-way to an
answer (but since ianap, this is mostly greek to me and so is not quite
a solution I can implement yet)...
You said above that 'yes, I can use it with dovecot' - but what about
postfix and mysql... where/how do they fit into this mix? My thought was
that there are two issues here:
1. Storing them in bcrypted form, and
2. The clients must support *decrypting* them...
So, since I use postfixadmin, I'm guessing that for #1, it will have to
support encrypting them in bcrypt form, and then I have to worry about
dovecot - and since I'm planning on using postfix+dovecot-sasl, once
dovecot supports it, postfix will too...
Is that about right?
Thanks again,
--
Best regards,
Charles
Re: [Dovecot] Storing passwords encrypted... bcrypt?
On 2012-01-03 8:58 PM, Michael Orlitzky wrote: On 01/03/2012 08:25 PM, Charles Marcus wrote: What I'm worried about is the worst case scenario of someone getting ahold of the entire user database of *stored* passwords, where they can then take their time and brute force them at their leisure, on *their* *own* systems, without having to hammer my server over smtp/imap and without the automated limit of *my* fail2ban getting in their way. To prevent rainbow table attacks, salt your passwords. You can make them a little bit more difficult in plenty of ways, but salt is the /solution/. Go read that link (you obviously didn't yet, because he claims that salting passwords is next to *useless*... As for people writing their passwords down... our policy is that it is a potentially *firable* *offense* (never even encountered one case of anyone posting their password, and I'm on these systems off and on all the time) if they do post these anywhere that is not under lock and key. Also, I always set up their email clients for them (on their workstations and on their phones - and of course tell it to remember the password, so they basically never have to enter it. You realize they're just walking around with a $400 post-it note with the password written on it, right? Nope, you are wrong - as I have patiently explained before. They do not *need* to write their password down. -- Best regards, Charles
Re: [Dovecot] Storing passwords encrypted... bcrypt?
On 2012-01-03 8:37 PM, David Ford wrote: part of my point along that of brute force resistance, is that when security becomes onerous to the typical user such as requiring non-repeat passwords of "10 characters including punctuation and mixed case", even stalwart policy followers start tending toward avoiding it. Our policy is that we also don't force password changes unless/until there is a reason (an account is hacked/abused. I've been managing this mail system for 11+ years now, and this has *never* happened (knock wood). I'm not saying we're immune, or it can never happen, I'm simply saying it has never happened, so out policy is working as far as I'm concerned. if anyone has a stressful job, spends a lot of time working, missing sleep, is thereby prone to memory lapse, it's almost a sure guarantee they *will* write it down/store it somewhere -- usually not in a password safe. Again - there is no *need* form them to write it down. Once their workstation/home computer/phone is set up, it remembers the password for them. or, they'll export their saved passwords to make a backup plain text copy, and leave it on their Desktop folder but coyly named and prefixed with a few random emails to grandma, so mr. sysadmin doesn't notice it. And if I don't notice it, no one else will either, most likely. There is *no* perfect way, but ours works and has been working for 11+ years. on a tangent, you should worry about active brute force attacks. fail2ban and iptables heuristics become meaningless when the brute forcing is done by bot nets which is more and more common than single-host attacks these days. one IP per attempt in a 10-20 minute window will probably never trigger any of these methods. Nor will it ever be successful in brute forcing a strong password either, because a botnet has to try the same user+different passwords, and is easy to monitor for an excessive number of failures (of the same user login attempts) and notify the sys admin (me) well in advance of the hack attempt being successful. -- Best regards, Charles
Re: [Dovecot] Storing passwords encrypted... bcrypt?
On Wed, 2012-01-04 at 22:16 -0500, David Ford wrote: > > with multiple servers, we use pam & nss, with a replicated ldap backed. public accessible mode :P oh dont start me on that, but luckily I'm not subjected to its dangers...and telling Pascal bout Bourbon made me realise its time to head out for last couple of nights of freedom and have a few. <> signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Storing passwords encrypted... bcrypt?
On Thu, 2012-01-05 at 04:05 +0100, Pascal Volk wrote: > On 01/05/2012 03:36 AM Noel Butler wrote: > > > > > Because with multiple servers, we store them all in (replicated) > > mysql :) (the same with postfix/dovecot). > > and as I'm sure you are aware, Apache does not understand standard > > crypted MD5, hence why there is the second option of apache_md5_crypt() > > Oh, let me guess: You are using Windows, Netware, TPF as OS for your > web servers? ;-) > > man htpasswd | grep -- '-d ' >-d Use crypt() encryption for passwords. This is not supported by > the httpd server on Windows and Netware and TPF. > > > As you may have seen in my previous mail, the password is generated > using crypt(). HTTP Authentication works with that password hash, even > with the httpd from the ASF. > I think you need to do some homework, and although I now have 3.25 days of holidays remaining, I don't intend to waste them educating anybody hehe. Assuming you even know what I'm talking about, which I suspect you don't since you keep using console commands and things like htpasswd, which does not write to a mysql db, you don't seem to have comprehended that I do not work with flat files nor local so it is irrelevant, I use perl scripts for all systems management, so I hope you are not going to suggest that I should make a system call when I can do it natively in perl. But please, by all means, create a mysql db using a system crpyted md5 password, I'll even help ya, openssl passwd -1 foobartilly $1$e3a.f3uW$SYRQiMlEhC5XlnSxtxiNC/ pop the entry into the db and go for your life trying to authenticate. and when you've gone through half bottle of bourbon trying to figure out why its not working, try the apache crypted md5 version $apr1$yKxk.DrQ $ybcmM8mC1qD5t5FvoY9820 If you stop, and think about what I've said, you just might wake up to what I've been saying. Cheers PS me use windaz? wash your bloody mouth out mister! ;) (Slackware all the way) <> signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Storing passwords encrypted... bcrypt?
> Because with multiple servers, we store them all in (replicated) mysql > :) (the same with postfix/dovecot). and as I'm sure you are aware, > Apache does not understand standard crypted MD5, hence why there is > the second option of apache_md5_crypt() with multiple servers, we use pam & nss, with a replicated ldap backed. this serves all auth requests for all services and no services cares if it is sha, md5, or a crypt method. -d
Re: [Dovecot] Storing passwords encrypted... bcrypt?
On 01/05/2012 03:36 AM Noel Butler wrote: > > Because with multiple servers, we store them all in (replicated) > mysql :) (the same with postfix/dovecot). > and as I'm sure you are aware, Apache does not understand standard > crypted MD5, hence why there is the second option of apache_md5_crypt() Oh, let me guess: You are using Windows, Netware, TPF as OS for your web servers? ;-) man htpasswd | grep -- '-d ' -d Use crypt() encryption for passwords. This is not supported by the httpd server on Windows and Netware and TPF. As you may have seen in my previous mail, the password is generated using crypt(). HTTP Authentication works with that password hash, even with the httpd from the ASF. Regards, Pascal -- The trapper recommends today: cafefeed.1200...@localdomain.org
Re: [Dovecot] Storing passwords encrypted... bcrypt?
On Thu, 2012-01-05 at 03:26 +0100, Pascal Volk wrote: > On 01/05/2012 02:59 AM Noel Butler wrote: > > We use Crypt::PasswdMD5 - > > unix_md5_crypt() for all general password storage including mail/ftp > > etc, except for web, where we need to use apache_md5_crypt(). > > Huh, why do you need to store passwords in Apaches md5 crypt() format? > Because with multiple servers, we store them all in (replicated) mysql :) (the same with postfix/dovecot). and as I'm sure you are aware, Apache does not understand standard crypted MD5, hence why there is the second option of apache_md5_crypt() > ,--[ Apache config ]-- > | AuthType Basic > | AuthName "bla …" > | AuthBasicProvider dbm > | AuthDBMUserFile /path/2/.htpasswd > | Require valid-user > | Order allow,deny > | Allow from 203.0.113.0/24 2001:db8::/32 > | Satisfy any > `-- <> signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Storing passwords encrypted... bcrypt?
On Wed, 2012-01-04 at 21:06 -0500, Patrick Domack wrote: > Quoting Noel Butler : > > > On Tue, 2012-01-03 at 20:58 -0500, Michael Orlitzky wrote: > > > > > >> To prevent rainbow table attacks, salt your passwords. You can make them > >> a little bit more difficult in plenty of ways, but salt is the /solution/. > > > > > > > > Agreed... > > We use Crypt::PasswdMD5 - > > unix_md5_crypt() for all general password storage including mail/ftp > > etc, except for web, where we need to use apache_md5_crypt(). > > But still, the results are all the same, if they get the hash, it can > be broken, given time. Using more cpu expensive methods make it take > longer (like adding salt, more complex hash). But the end result is > they will have it if they want it. > > The only solution is to use two factor authenication, or rotate your > passwords quicker than they can get broken. > Yup, anything can be broken, given time and resources, no mater what, but using crypted MD5 is better than using normal md5 (like sadly way too many use) and having easy rainbow attacks succeed in mere seconds. No mater how good your database security is, always assume the worse, too many think that a DB compromise just can't happen to them, and as murphy's law shows, their usually the ones it does happen to. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Storing passwords encrypted... bcrypt?
On 01/05/2012 02:59 AM Noel Butler wrote:
> We use Crypt::PasswdMD5 -
> unix_md5_crypt() for all general password storage including mail/ftp
> etc, except for web, where we need to use apache_md5_crypt().
Huh, why do you need to store passwords in Apaches md5 crypt() format?
,--[ Apache config ]--
| AuthType Basic
| AuthName "bla …"
| AuthBasicProvider dbm
| AuthDBMUserFile /path/2/.htpasswd
| Require valid-user
| Order allow,deny
| Allow from 203.0.113.0/24 2001:db8::/32
| Satisfy any
`--
,--[ stdin/stdout ]--
| user@localhost ~ $ python
| Python 2.5.4 (r254:67916, Feb 17 2009, 20:16:45)
| [GCC 4.3.3] on linux2
| Type "help", "copyright", "credits" or "license" for more information.
| >>> import anydbm
| >>> dbm = anydbm.open('/path/2/.htpasswd')
| >>> dbm['user']
|
'$6$Rn6L.3hT2x6dnX0t$d0/Tx.Ps3KSRxxm.ggFBYqum54/k8JmDzUcpoCXre88cBEXK8WB.Vdb1YzN.8fOvz3fJU4uLgW0/AlTiB9Ui2.::Real
Name'
| >>>
`--
Regards,
Pascal
--
The trapper recommends today: deadbeef.1200...@localdomain.org
Re: [Dovecot] Storing passwords encrypted... bcrypt?
Quoting Noel Butler : On Tue, 2012-01-03 at 20:58 -0500, Michael Orlitzky wrote: To prevent rainbow table attacks, salt your passwords. You can make them a little bit more difficult in plenty of ways, but salt is the /solution/. Agreed... We use Crypt::PasswdMD5 - unix_md5_crypt() for all general password storage including mail/ftp etc, except for web, where we need to use apache_md5_crypt(). But still, the results are all the same, if they get the hash, it can be broken, given time. Using more cpu expensive methods make it take longer (like adding salt, more complex hash). But the end result is they will have it if they want it. The only solution is to use two factor authenication, or rotate your passwords quicker than they can get broken.
Re: [Dovecot] Storing passwords encrypted... bcrypt?
On Tue, 2012-01-03 at 20:58 -0500, Michael Orlitzky wrote: > To prevent rainbow table attacks, salt your passwords. You can make them > a little bit more difficult in plenty of ways, but salt is the /solution/. Agreed... We use Crypt::PasswdMD5 - unix_md5_crypt() for all general password storage including mail/ftp etc, except for web, where we need to use apache_md5_crypt(). signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Storing passwords encrypted... bcrypt?
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}.
Regards,
Pascal
--
The trapper recommends today: deadbeef.1200...@localdomain.org
Re: [Dovecot] Storing passwords encrypted... bcrypt?
On 1/3/2012 5:25 PM, Charles Marcus wrote: I think ya'll are missing the point... not sure, because I'm still not completely sure that this is saying what I think it is saying (that's why I asked)... I'm sure I'm not missing the point. My comment was that password length and complexity are probably more important than bcrypt versus sha1, and you've already addressed those. Given that you use strong 15-character passwords, pretty much all hash functions are already out of reach for brute force. bcrypt is probably better in the same sense that it's harder to drive a car to Saturn than it is to drive to Mars.
Re: [Dovecot] Storing passwords encrypted... bcrypt?
On 01/03/2012 08:25 PM, Charles Marcus wrote: What I'm worried about is the worst case scenario of someone getting ahold of the entire user database of *stored* passwords, where they can then take their time and brute force them at their leisure, on *their* *own* systems, without having to hammer my server over smtp/imap and without the automated limit of *my* fail2ban getting in their way. To prevent rainbow table attacks, salt your passwords. You can make them a little bit more difficult in plenty of ways, but salt is the /solution/. As for people writing their passwords down... our policy is that it is a potentially *firable* *offense* (never even encountered one case of anyone posting their password, and I'm on these systems off and on all the time) if they do post these anywhere that is not under lock and key. Also, I always set up their email clients for them (on their workstations and on their phones - and of course tell it to remember the password, so they basically never have to enter it. You realize they're just walking around with a $400 post-it note with the password written on it, right?
Re: [Dovecot] Storing passwords encrypted... bcrypt?
On 01/03/2012 08:25 PM, Charles Marcus wrote: > > I think ya'll are missing the point... not sure, because I'm still not > completely sure that this is saying what I think it is saying (that's > why I asked)... > > I'm not worried about *active* brute force attacks against my server > using the standard smtp or imap protocols - fail2ban takes care of > those in a hurry. > > What I'm worried about is the worst case scenario of someone getting > ahold of the entire user database of *stored* passwords, where they > can then take their time and brute force them at their leisure, on > *their* *own* systems, without having to hammer my server over > smtp/imap and without the automated limit of *my* fail2ban getting in > their way. > > As for people writing their passwords down... our policy is that it is > a potentially *firable* *offense* (never even encountered one case of > anyone posting their password, and I'm on these systems off and on all > the time) if they do post these anywhere that is not under lock and > key. Also, I always set up their email clients for them (on their > workstations and on their phones - and of course tell it to remember > the password, so they basically never have to enter it. perhaps. part of my point along that of brute force resistance, is that when security becomes onerous to the typical user such as requiring non-repeat passwords of "10 characters including punctuation and mixed case", even stalwart policy followers start tending toward avoiding it. if anyone has a stressful job, spends a lot of time working, missing sleep, is thereby prone to memory lapse, it's almost a sure guarantee they *will* write it down/store it somewhere -- usually not in a password safe. or, they'll export their saved passwords to make a backup plain text copy, and leave it on their Desktop folder but coyly named and prefixed with a few random emails to grandma, so mr. sysadmin doesn't notice it. on a tangent, you should worry about active brute force attacks. fail2ban and iptables heuristics become meaningless when the brute forcing is done by bot nets which is more and more common than single-host attacks these days. one IP per attempt in a 10-20 minute window will probably never trigger any of these methods.
Re: [Dovecot] Storing passwords encrypted... bcrypt?
On 2012-01-03 6:12 PM, WJCarpenter wrote: On 1/3/2012 2:38 PM, Simon Brereton wrote: http://xkcd.com/936/ As they saying goes, entropy ain't what it used to be. https://www.grc.com/haystack.htm However, both links actually illustrate the same point: once you get past dictionary attacks, the length of the password is dominant factor in the strength of the password against brute force attack. I think ya'll are missing the point... not sure, because I'm still not completely sure that this is saying what I think it is saying (that's why I asked)... I'm not worried about *active* brute force attacks against my server using the standard smtp or imap protocols - fail2ban takes care of those in a hurry. What I'm worried about is the worst case scenario of someone getting ahold of the entire user database of *stored* passwords, where they can then take their time and brute force them at their leisure, on *their* *own* systems, without having to hammer my server over smtp/imap and without the automated limit of *my* fail2ban getting in their way. As for people writing their passwords down... our policy is that it is a potentially *firable* *offense* (never even encountered one case of anyone posting their password, and I'm on these systems off and on all the time) if they do post these anywhere that is not under lock and key. Also, I always set up their email clients for them (on their workstations and on their phones - and of course tell it to remember the password, so they basically never have to enter it. -- Best regards, Charles
Re: [Dovecot] Storing passwords encrypted... bcrypt?
On 1/3/2012 2:38 PM, Simon Brereton wrote: http://xkcd.com/936/ As they saying goes, entropy ain't what it used to be. https://www.grc.com/haystack.htm However, both links actually illustrate the same point: once you get past dictionary attacks, the length of the password is dominant factor in the strength of the password against brute force attack.
Re: [Dovecot] Storing passwords encrypted... bcrypt?
On 3 January 2012 17:30, Charles Marcus wrote: > On 2012-01-03 5:10 PM, WJCarpenter wrote: >> >> In his description, he uses the example of passwords which are >> "lowercase, alphanumeric, and 6 characters long" (and in another place >> the example is "lowercase, alphabetic passwords which are ≤7 >> characters", I guess to illustrate that things have gotten faster). If >> you are allowing your users to create such weak passwords, using bcrypt >> will not save you/them. Attackers will just be wasting more of your CPU >> time making attempts. If they get a copy of your hashed passwords, >> they'll likely be wasting their own CPU time, but they have plenty of >> that, too. > > > I require strong passwords of 15 characters in length. Whats more, they are > assigned (by me), and the user cannot change it. But, he isn't talking about > brute force attacks against the server. He is talking about if someone > gained access to the SQL database where the passwords are stored (as has > happened countless times in the last few years), and then had the luxury of > brute forcing an attack locally (on their own systems) against your password > database. 24+ would be better.. http://xkcd.com/936/ Simon
Re: [Dovecot] Storing passwords encrypted... bcrypt?
On 01/03/2012 05:30 PM, Charles Marcus wrote: > On 2012-01-03 5:10 PM, WJCarpenter wrote: >> In his description, he uses the example of passwords which are >> "lowercase, alphanumeric, and 6 characters long" (and in another place >> the example is "lowercase, alphabetic passwords which are ≤7 >> characters", I guess to illustrate that things have gotten faster). If >> you are allowing your users to create such weak passwords, using bcrypt >> will not save you/them. Attackers will just be wasting more of your CPU >> time making attempts. If they get a copy of your hashed passwords, >> they'll likely be wasting their own CPU time, but they have plenty of >> that, too. > > I require strong passwords of 15 characters in length. Whats more, > they are assigned (by me), and the user cannot change it. But, he > isn't talking about brute force attacks against the server. He is > talking about if someone gained access to the SQL database where the > passwords are stored (as has happened countless times in the last few > years), and then had the luxury of brute forcing an attack locally (on > their own systems) against your password database. when it comes to brute force, passwords like "51k$jh#21hiaj2" are significantly weaker than "wePut85umbrellasIn2shoes". considerably difficult for humans which makes them far more likely to write it on a sticky and make it handily available.
Re: [Dovecot] Storing passwords encrypted... bcrypt?
On 2012-01-03 5:10 PM, WJCarpenter wrote: In his description, he uses the example of passwords which are "lowercase, alphanumeric, and 6 characters long" (and in another place the example is "lowercase, alphabetic passwords which are ≤7 characters", I guess to illustrate that things have gotten faster). If you are allowing your users to create such weak passwords, using bcrypt will not save you/them. Attackers will just be wasting more of your CPU time making attempts. If they get a copy of your hashed passwords, they'll likely be wasting their own CPU time, but they have plenty of that, too. I require strong passwords of 15 characters in length. Whats more, they are assigned (by me), and the user cannot change it. But, he isn't talking about brute force attacks against the server. He is talking about if someone gained access to the SQL database where the passwords are stored (as has happened countless times in the last few years), and then had the luxury of brute forcing an attack locally (on their own systems) against your password database. -- Best regards, Charles
Re: [Dovecot] Storing passwords encrypted... bcrypt?
On 2012-01-03 4:03 PM, David Ford wrote:
md5 is deprecated, *nix has used sha1 for a while now
That link lumps sha1 in with MD5 and others:
"Why Not {MD5, SHA1, SHA256, SHA512, SHA-3, etc}?"
--
Best regards,
Charles
Re: [Dovecot] Storing passwords encrypted... bcrypt?
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)? Ooop... forgot the link: http://codahale.com/how-to-safely-store-a-password/ AFAIK, that web page is correct in a relative sense, but getting bcrypt support might not be the most urgent priority. In his description, he uses the example of passwords which are "lowercase, alphanumeric, and 6 characters long" (and in another place the example is "lowercase, alphabetic passwords which are ≤7 characters", I guess to illustrate that things have gotten faster). If you are allowing your users to create such weak passwords, using bcrypt will not save you/them. Attackers will just be wasting more of your CPU time making attempts. If they get a copy of your hashed passwords, they'll likely be wasting their own CPU time, but they have plenty of that, too. There are plenty of recommendations for what makes a good password / passphrase. If you are not already enforcing such rules (perhaps also with a lookaside to one or more of the leaked tables of passwords floating around), then IMHO that's much more urgent. (One of the best twists I read somewhere [sorry, I forget where] was to require at least one uppercase and one digit, but to not count them as fulfilling the requirement if they were used as the first or last character.) Side note, but for the sake of precision ... attackers are not literally decrypting passwords. They are guessing passwords and then performing a one-way hash to see if they guessed correctly. As a practical matter, that means that you have to ask your users to update their passwords any time you change the password storage scheme. (I don't know enough about bcrypt to know if that would be required if you wanted to simply increase the work factor.)
Re: [Dovecot] Storing passwords encrypted... bcrypt?
md5 is deprecated, *nix has used sha1 for a while now
Re: [Dovecot] Storing passwords encrypted... bcrypt?
On 2012-01-03 3: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)? Ooop... forgot the link: http://codahale.com/how-to-safely-store-a-password/ But after perusing the wiki: http://wiki2.dovecot.org/Authentication/PasswordSchemes it appears not? Timo - any chance for adding support for it? Or is that web page incorrect? -- Best regards, Charles
