[Dovecot] Storing passwords encrypted... bcrypt?
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)?
--
Best regards,
Charles
On 2012-01-03 3:40 PM, Charles Marcus CMarcus@Media-Brokers.com 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
On 2012-01-03 4:03 PM, David Ford david@blue-labs.org 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
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:
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.)
On 2012-01-03 5:10 PM, WJCarpenter bill-dovecot@carpenter.org 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
On 01/03/2012 05:30 PM, Charles Marcus wrote:
On 2012-01-03 5:10 PM, WJCarpenter bill-dovecot@carpenter.org 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.
On 3 January 2012 17:30, Charles Marcus CMarcus@media-brokers.com wrote:
On 2012-01-03 5:10 PM, WJCarpenter bill-dovecot@carpenter.org 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..
Simon
On 1/3/2012 2:38 PM, Simon Brereton wrote:
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.
On 2012-01-03 6:12 PM, WJCarpenter bill-dovecot@carpenter.org wrote:
On 1/3/2012 2:38 PM, Simon Brereton wrote:
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
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.
On 2012-01-03 8:37 PM, David Ford david@blue-labs.org 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
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?
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().
Quoting Noel Butler noel.butler@ausics.net:
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.
On Wed, 2012-01-04 at 21:06 -0500, Patrick Domack wrote:
Quoting Noel Butler noel.butler@ausics.net:
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.
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.
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.1200503@localdomain.org
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 `--
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.1200504@localdomain.org
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)
Quoting Noel Butler noel.butler@ausics.net:
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.
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
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.
On 2012-01-03 8:58 PM, Michael Orlitzky michael@orlitzky.com 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
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.
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!
On 2012-01-05 10:28 AM, Michael Orlitzky michael@orlitzky.com 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.
<sigh> 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
On 1/5/2012 9:14 AM, Charles Marcus wrote:
On 2012-01-05 10:28 AM, Michael Orlitzky michael@orlitzky.com 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.
<sigh> 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."
On 2012-01-05 11:21 AM, Willie Gillespie wgillespie@es2eng.com 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
On 01/05/2012 11:36 AM, Charles Marcus wrote:
On 2012-01-05 11:21 AM, Willie Gillespie wgillespie@es2eng.com 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.
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.
<sigh> 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.
On 2012-01-05 11:31 AM, Michael Orlitzky michael@orlitzky.com wrote:
Ugh, sorry. I went to the link that someone else quoted:
https://www.grc.com/haystack.htm <snip> Gibson*is* a renowned crackpot.
Don't know about that, but I do know from long experience Spinrite rocks!
Maybe
--
Best regards,
Charles
On 01/05/2012 01:37 PM, Charles Marcus wrote:
On 2012-01-05 11:31 AM, Michael Orlitzky michael@orlitzky.com wrote:
Ugh, sorry. I went to the link that someone else quoted:
https://www.grc.com/haystack.htm <snip> 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
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.
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.1200501@localdomain.org
On 2012-01-04 8:19 PM, Pascal Volk user+dovecot@localhost.localdomain.org 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:
Storing them in bcrypted form, and
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
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:
- Storing them in bcrypted form, and
For MySQL the bcrypted password is just a varchar.
- 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.1200523@localdomain.org
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
On Tue, Jan 17, 2012 at 12:22:35AM +0000, 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:
participants (12)
-
/dev/rob0
-
Charles Marcus
-
David Ford
-
Ed W
-
Michael Orlitzky
-
Noel Butler
-
Pascal Volk
-
Patrick Domack
-
Simon Brereton
-
Willie Gillespie
-
Willie Gillespie
-
WJCarpenter