Re: md5crypt passwords
On Wed, Jun 20, 2012 at 1:25 PM, Nick Edwards nick.z.edwa...@gmail.com wrote: Hello, I posted this to users list last week but no-one bit, so I'm trying here. With md5crypt no longer recommended for use by its author, will Apache soon support sha256/sha512 in basic authentication via MySQL. I understand the apr version is different to plain md5crypt, but it is based on the same thing from what I can tell, so its pointless upgrading our database passwords to use sha512 if Apache's still the weak link. All admin scripts run in perl, and we are currently doing this with apache_md5_crypt($password); using Crypt::PasswdMD5 For Mail and FTP, we are _now_ successfully using crypt($password, '$6$' . $16charsalt) for sha512, be nice if Apache basic auth would too! Apache currently only offers SHA1 which is about as secure (can be read as , as hopeless as) MD5. Can the project devs/team leaders indicate if there are future plans to mnprove the basic auth security methods up to SHA512? This thread is all over the place! So, a summary... * SHA-1 is not as broken as MD5 - no way to generate collisions has been found that is practical. * MD5 is still pre-image resistant even though it is possible to generate collisions. This means that repeated applications of MD5 are also pre-image resistant. * The threat against md5crypt is the same as it has always been: rainbow tables. The current attacks have not changed this. * htpasswd uses an 8 byte salt with 6 bits per byte. So, a rainbow table will have 2^48 entries per password. Assuming you can somehow manage 1 byte per entry, that's still nearly 300 TB per password. So, I'd say there's no need for panic, but there's also no reason that I can see to not move to a more modern scheme. Then the question is: what scheme? Here are some design criteria I think would be useful. 1. Use something from the SHA-2 family - SHA-512 would seem fine to me. 2. Use a very large salt - disk space is not at a premium for password stores! 3. Use quite a lot of rounds,. 4. Use something that is hard to optimise in hardware (ideally).
Re: md5crypt passwords
On 21/06/2012 12:40, Ben Laurie wrote: 4. Use something that is hard to optimise in hardware (ideally). And what about massive sites that need the crypto HW to manage the concurrent logins? Yes, you're making it harder on the hackers, but also potentially on our users. ...Or did I just put my foot in my crypto-clueless-mouth? Issac
Re: md5crypt passwords
On Thu, Jun 21, 2012 at 10:53 AM, Issac Goldstand mar...@beamartyr.net wrote: On 21/06/2012 12:40, Ben Laurie wrote: 4. Use something that is hard to optimise in hardware (ideally). And what about massive sites that need the crypto HW to manage the concurrent logins? I have never come across a site where login causes significant load. They may exist, but I figure they can do their own thing for passwords... Yes, you're making it harder on the hackers, but also potentially on our users. ...Or did I just put my foot in my crypto-clueless-mouth? Issac
Re: md5crypt passwords
On Thu, 2012-06-21 at 10:40 +0100, Ben Laurie wrote: 4. Use something that is hard to optimise in hardware (ideally). 5. Only hire web developers who know what they're doing, who know what security is, and how to audit their code :) If they cant get the database, then it wouldn't mater if they were in *gulp* plain text attachment: face-smile.png signature.asc Description: This is a digitally signed message part
Re: md5crypt passwords
On Thu, 2012-06-21 at 10:57 +0100, Ben Laurie wrote: On Thu, Jun 21, 2012 at 10:53 AM, Issac Goldstand mar...@beamartyr.net wrote: On 21/06/2012 12:40, Ben Laurie wrote: 4. Use something that is hard to optimise in hardware (ideally). And what about massive sites that need the crypto HW to manage the concurrent logins? I have never come across a site where login causes significant load. That's because all the commonly used methods are cryptographic hash's that are designed for speed, unlike password hash's, designed to makes things crawl for the norti peoples. signature.asc Description: This is a digitally signed message part
Re: md5crypt passwords
* Reindl Harald wrote:
i only needed to point out that weakhash(weakhash(weakhash()))
does not result in stronghash() no matter how often you wrap
I'm not sure, why the topic drifted there anyway. md5crypt does not actually
nest hashes like this.
nd
--
package Hacker::Perl::Another::Just;print
qq~@{[reverse split/::/ =__PACKAGE__]}~;
# André Malo # http://www.perlig.de #
Re: md5crypt passwords
Hi Stefan, On 6/21/12, Stefan Fritsch s...@sfritsch.de wrote: On Wed, 20 Jun 2012, Nick Edwards wrote: I posted this to users list last week but no-one bit, so I'm trying here. With md5crypt no longer recommended for use by its author, will Apache soon support sha256/sha512 in basic authentication via MySQL. Note that it does not really matter that much which hash algorithm is used. The number of rounds is more important. APR-MD5 ($apr1$) does 1000 times recursive md5 (which is 1000 times more secure in terms of brute forcing than plain md5). We should switch to something that needs more processing time so that it is more difficult to brute force. I understand the apr version is different to plain md5crypt, but it is based on the same thing from what I can tell, so its pointless upgrading our database passwords to use sha512 if Apache's still the weak link. All admin scripts run in perl, and we are currently doing this with apache_md5_crypt($password); using Crypt::PasswdMD5 For Mail and FTP, we are _now_ successfully using crypt($password, '$6$' . $16charsalt) for sha512, be nice if Apache basic auth would too! APR passes everything it doesn't know to the system's crypt() function. So chances are good that using $6$... already works for you. However, there is currently no way to create such hashes with htpasswd. Thanks, it does work, I did not realise this, because some time ago I tried to use our default md5cryprt password used for ftp and mail, but Apache did not like it, after much googling I found reference saying it was different and needed apr1, if it falls back why would that have failed for us? or is this fallback only something new? I would be for importing some state of the art scheme from some BSD. Good schemes allow to change the number of rounds without loosing backward compatibility. I guess bcrypt is a candidate. This new algorithm should then be the new default. Don't know much about bcrypt sorry. Thanks again for your help, all is now happy
Re: md5crypt passwords
On Wed, 20 Jun 2012, Nick Edwards wrote: I posted this to users list last week but no-one bit, so I'm trying here. With md5crypt no longer recommended for use by its author, will Apache soon support sha256/sha512 in basic authentication via MySQL. Note that it does not really matter that much which hash algorithm is used. The number of rounds is more important. APR-MD5 ($apr1$) does 1000 times recursive md5 (which is 1000 times more secure in terms of brute forcing than plain md5). We should switch to something that needs more processing time so that it is more difficult to brute force. I understand the apr version is different to plain md5crypt, but it is based on the same thing from what I can tell, so its pointless upgrading our database passwords to use sha512 if Apache's still the weak link. All admin scripts run in perl, and we are currently doing this with apache_md5_crypt($password); using Crypt::PasswdMD5 For Mail and FTP, we are _now_ successfully using crypt($password, '$6$' . $16charsalt) for sha512, be nice if Apache basic auth would too! APR passes everything it doesn't know to the system's crypt() function. So chances are good that using $6$... already works for you. However, there is currently no way to create such hashes with htpasswd. Apache currently only offers SHA1 which is about as secure (can be read as , as hopeless as) MD5. The sha1 algorithm in htpasswd is only for compatibility with some other product. It is extremely weak (no salt, one round only). The APR-MD5 algorithm is *much* more secure. Can the project devs/team leaders indicate if there are future plans to mnprove the basic auth security methods up to SHA512? I would be for importing some state of the art scheme from some BSD. Good schemes allow to change the number of rounds without loosing backward compatibility. I guess bcrypt is a candidate. This new algorithm should then be the new default. In addition, we may want to provide some md5 algorithm with more rounds. Then it should be possible to convert old $apr1$ hashes into stronger hashes without having to know the original password. Of course, people would need to take care that the old 1000-round hashes are securely deleted everywhere. Cheers, Stefan
Re: md5crypt passwords
Am 20.06.2012 22:52, schrieb Stefan Fritsch: On Wed, 20 Jun 2012, Nick Edwards wrote: I posted this to users list last week but no-one bit, so I'm trying here. With md5crypt no longer recommended for use by its author, will Apache soon support sha256/sha512 in basic authentication via MySQL. Note that it does not really matter that much which hash algorithm is used. The number of rounds is more important. APR-MD5 ($apr1$) does 1000 times recursive md5 (which is 1000 times more secure in terms of brute forcing than plain md5). jesus christ do not tell this any crypto specialist! this is completly wrong and the opposite true you do NOT NEED the right password you ONLY need a hash-collision in the worst case md5(password(md5(password)) is much more unsecure as md5(password) alone! why? because if my password is longer than a hash and you are hasing the hash again the original password will no longer matter - the collsion is based on the shorter one signature.asc Description: OpenPGP digital signature
Re: md5crypt passwords
Am 20.06.2012 23:19, schrieb Reindl Harald:
Am 20.06.2012 22:52, schrieb Stefan Fritsch:
On Wed, 20 Jun 2012, Nick Edwards wrote:
I posted this to users list last week but no-one bit, so I'm trying here.
With md5crypt no longer recommended for use by its author, will Apache
soon support sha256/sha512 in basic authentication via MySQL.
Note that it does not really matter that much which hash algorithm is used.
The number of rounds is more important.
APR-MD5 ($apr1$) does 1000 times recursive md5 (which is 1000 times more
secure in terms of brute forcing than
plain md5).
jesus christ do not tell this any crypto specialist!
this is completly wrong and the opposite true
you do NOT NEED the right password
you ONLY need a hash-collision
in the worst case md5(password(md5(password)) is much more
unsecure as md5(password) alone! why?
because if my password is longer than a hash and you are
hasing the hash again the original password will no
longer matter - the collsion is based on the shorter one
one more reason:
md5('jKül#*+-OA') is MUCH more secure
than md5(md5('jKül#*+-OA'))
recursion of hashing results in lose any benefit
of special chars and case-sensitivity because the
second ash is based only on a-z and 0-9
you do not need the original password!
you only need a hash-collision and can leave out
special chars completly to find one
signature.asc
Description: OpenPGP digital signature
Re: md5crypt passwords
On Wednesday 20 June 2012, Reindl Harald wrote:
Am 20.06.2012 23:19, schrieb Reindl Harald:
Am 20.06.2012 22:52, schrieb Stefan Fritsch:
On Wed, 20 Jun 2012, Nick Edwards wrote:
I posted this to users list last week but no-one bit, so I'm
trying here.
With md5crypt no longer recommended for use by its author, will
Apache soon support sha256/sha512 in basic authentication via
MySQL.
Note that it does not really matter that much which hash
algorithm is used. The number of rounds is more important.
APR-MD5 ($apr1$) does 1000 times recursive md5 (which is 1000
times more secure in terms of brute forcing than plain md5).
jesus christ do not tell this any crypto specialist!
this is completly wrong and the opposite true
you do NOT NEED the right password
you ONLY need a hash-collision
in the worst case md5(password(md5(password)) is much more
unsecure as md5(password) alone! why?
because if my password is longer than a hash and you are
hasing the hash again the original password will no
longer matter - the collsion is based on the shorter one
I should have written it does not really matter that much *which of
the mentioned hash algorithms* is used. If you use a very short hash,
of course you have a problem. But md5 is not short in this sense. It's
128 bit which corresponds to around 19 characters if you assume around
6.5 bits of entropy per char. This is not a relevant limitation. And
that problem is independent of the number of rounds, actually.
one more reason:
md5('jKül#*+-OA') is MUCH more secure
than md5(md5('jKül#*+-OA'))
recursion of hashing results in lose any benefit
of special chars and case-sensitivity because the
second ash is based only on a-z and 0-9
No, if your hash length is longer than the entropy in the password,
you don't loose anything. If you'd choose a hex or ascii
representation of md5, you would get a longer string (32 chars in the
case of hex). The longer length exactly cancels the reduced entropy
per character. NB, apr uses binary representation of md5 internally
(i.e. 16 bytes and every byte can actually take all 256 values).
you do not need the original password!
you only need a hash-collision and can leave out
special chars completly to find one
You need a password that gives the same value after 1000 rounds of
md5(password md5(password md5(password ...))). This is much more
expensive to find with brute force than a password that gives a
collision for a single md5.
Re: md5crypt passwords
Am 20.06.2012 23:52, schrieb Stefan Fritsch: you do not need the original password! you only need a hash-collision and can leave out special chars completly to find one You need a password that gives the same value after 1000 rounds of md5(password md5(password md5(password ...))). This is much more expensive to find with brute force than a password that gives a collision for a single md5 everybody with crypto knowledge will explain you that you are totally wrong - i can only try in my words! in the context of a hash-collision and rainbow-tables you need any string producing the same hash, no matter if 1, 10 or 1000 times md5() recursion there is a reason why even the developer of md5crypt saw the need for a offical statement that md5crypt should never again be considered as secure in any case! Original-Nachricht Betreff: CVE-2012-3287: md5crypt is no longer considered safe Datum: Fri, 8 Jun 2012 00:04:49 GMT Von: p...@freebsd.org An: bugt...@securityfocus.com The LinkedIn password incompetence has resulted in a number of just use md5crypt and you'll be fine pieces of advice on the net. Since I no longer consider this to be the case, I have issued an official statement, as the author of md5crypt, to the opposite effect: http://phk.freebsd.dk/sagas/md5crypt_eol.html Please find something better now. Thanks for using my code. Poul-Henning Kamp signature.asc Description: OpenPGP digital signature
Re: md5crypt passwords
On Wednesday 20 June 2012, Reindl Harald wrote: there is a reason why even the developer of md5crypt saw the need for a offical statement that md5crypt should never again be considered as secure in any case! http://phk.freebsd.dk/sagas/md5crypt_eol.html Follow the link in his statement: http://2012.sharcs.org/slides/sprengers.pdf They can try around 1 million md5crypt operations per second (md5crypt is basically the same as APR-MD5). For plain md5 (one round) there are programs that do more than 200 million operations per second. That's a rather big difference. And plain sha1 or even sha512 is much closer to plain md5 than to md5crypt. I agree that we should use something more secure, really soon. But there is no reason to panic, yet. Cheers, Stefan
Re: md5crypt passwords
Am 21.06.2012 00:14, schrieb Stefan Fritsch: On Wednesday 20 June 2012, Reindl Harald wrote: there is a reason why even the developer of md5crypt saw the need for a offical statement that md5crypt should never again be considered as secure in any case! http://phk.freebsd.dk/sagas/md5crypt_eol.html Follow the link in his statement: http://2012.sharcs.org/slides/sprengers.pdf They can try around 1 million md5crypt operations per second (md5crypt is basically the same as APR-MD5). For plain md5 (one round) there are programs that do more than 200 million operations per second. That's a rather big difference. And plain sha1 or even sha512 is much closer to plain md5 than to md5crypt. I agree that we should use something more secure, really soon. But there is no reason to panic, yet. here we are agree no reason for panic now i only needed to point out that weakhash(weakhash(weakhash())) does not result in stronghash() no matter how often you wrap signature.asc Description: OpenPGP digital signature
Re: md5crypt passwords
On Wed, 2012-06-20 at 22:52 +0200, Stefan Fritsch wrote:
On Wed, 20 Jun 2012, Nick Edwards wrote:
I posted this to users list last week but no-one bit, so I'm trying here.
With md5crypt no longer recommended for use by its author, will Apache
soon support sha256/sha512 in basic authentication via MySQL.
Note that it does not really matter that much which hash algorithm is
used. The number of rounds is more important. APR-MD5 ($apr1$) does 1000
times recursive md5 (which is 1000 times more secure in terms of brute
forcing than plain md5). We should switch to something that needs more
processing time so that it is more difficult to brute force.
yup, I'm not a crypto expert but IIRC sha512 by default uses rounds=5000
(if not rounds= is not specified)
I brought this up with (I think it was) Bill, a year ago (using SHA2)
and at that time there were no plans, however, in light of recent
events, I'd agree it needs to be revisited.
For Mail and FTP, we are _now_ successfully using crypt($password,
'$6$' . $16charsalt) for sha512, be nice if Apache basic auth would
too!
APR passes everything it doesn't know to the system's crypt() function. So
chances are good that using $6$... already works for you. However, there
is currently no way to create such hashes with htpasswd.
If the OP is using crypt() correctly with a modern nix OS it certainly
will, I've been using sha512 for a while.
I'm surprised he did not just try it, he might have had his answer a
week ago.
in perl I've been using
$psalt= join '', ('.', '/', 0..9, 'A'..'Z', 'a'..'z')[map {rand 64}
(0..15)];
$epass = crypt($PASS, '$6$' . $psalt);
the end result will be readable by httpd to auth users
In php, I've used
$psalt = uniqid(16);-- yes i know a bad cheat :) ... but I'm far
from knowledgeable with php
$epass = crypt($PASS,'$6$'.$csalt);
attachment: face-smile.png
signature.asc
Description: This is a digitally signed message part
