You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Stefan Fritsch <sf...@sfritsch.de> on 2012/06/23 22:42:42 UTC
Choosing a stronger password hash algorithm
On Thursday 21 June 2012, Ben Laurie wrote:
> 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.
The sha message digests are designed to be fast and to be easily
implemented in hardware. In general, the speed-up when going from
general purpose CPU implementations to parallel implementations using
GPU or specialized hardware seems to be relatively high. Therefore I
think what is generally used as sha256_crypt or sha512_crypt is not
the optimal choice. [1] has some thoughts about choosing a password
hashing algorithm.
>
> 2. Use a very large salt - disk space is not at a premium for
> password stores!
Agreed. 64bit should be absolute minimum, more would be better.
> 3. Use quite a lot of rounds,.
The number should be configurable so that we can adjust the cost
without breaking backward compatibility.
> 4. Use something that is hard to optimise in hardware (ideally).
bcrypt [1] and scrypt [2] seem to be much more difficult to port to
hardware or GPUs than sha256/512_crypt [3-5]. We can't make the
operation too expensive on normal CPUs or we create a DoS problem if
someone does lots of requests with wrong passwords. Therefore I think
choosing an algorithm that does not scale well on more specialized
hardware is good.
Both bcrypt and scrypt can be adjusted in how much CPU time to use.
scrypt can also be adjusted in how much RAM it uses. bcrypt uses a
128bit salt, AFAICS scrypt can use arbitrary salt lengths.
Bcrypt has seen a lot more review than scrypt, therefore I am somewhat
in favor of bcrypt. Crypt_blowfish [6] is an implementation with a
very liberal license that we could use. Scrypt has a 2-clause BSD
license which would also be OK.
Opinions?
Cheers,
Stefan
[1] http://static.usenix.org/event/usenix99/provos.html
[2] http://www.tarsnap.com/scrypt.html
[3] http://stackoverflow.com/a/6807375
[4] http://www.openwall.com/lists/john-dev/2012/05/14/1
[5] http://www.openwall.com/lists/john-dev/2012/05/14/4
[6] http://www.openwall.com/crypt/
Re: Choosing a stronger password hash algorithm
Posted by Steve Marquess <ma...@opensslfoundation.com>.
On 06/25/2012 03:37 PM, Stefan Fritsch wrote:
> ...
>>
>> One complication to keep in mind: when you don't do all your
>> cryptography via a specific crypto library (OpenSSL, NSS, etc.)
>> then FIPS 140-2 compliance goes from trivial (for 2.4) to messy.
>> Not generally a problem outside of the U.S., but it very much
>> matters anywhere in the U.S. government market.
>
> The APR-MD5 password hashing is already implemented in apr-util and
> does not use an external crypto library. Would another password hashin
> algorithm chang anything? Or is it already necessary for FIPS
> compliance to patch apr-util or httpd?
MD5 isn't allowed in FIPS mode (with the peculiar exception of use for
TLS proper).
Note that the "FIPS capable" OpenSSL (OpenSSL built with the "fips"
build time option in the presence of a validated FIPS module) will
automatically disable use of disallowed cryptography when the FIPS mode
of operation is enabled.
The awkward thing about FIPS 140-2 validated cryptography is that it
offers absolutely no tangible advantage over otherwise comparable
non-validated cryptographic implementations -- it isn't more secure,
performance isn't better, and so forth. There is only one reason to use
it: because such use is mandated for certain environments. But, one of
those environments (U.S. government) is a huge market. As a consultant
I've been paid good money for many years to hack FIPS 140-2 (and other
kinds) of compliance into open source products like mod_ssl and OpenSSH.
That patching is getting easier over time but is still necessary for
many such products.
An open source based FIPS validated module is available for use by
anyone at no cost (the OpenSSL FIPS Object Module 1.2, soon to be joined
by 2.0). But, the need to patch many OSS products to use it is a
deterrent to many end users. Make it easy to build a FIPS compliant
httpd without patches and help put consultants like me out of business :-)
-Steve M.
--
Steve Marquess
OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess@opensslfoundation.com
marquess@openssl.com
Re: Choosing a stronger password hash algorithm
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Monday 25 June 2012, Steve Marquess wrote:
> > I rather like the fact that you can use htpasswd on one system
> > and use the result on another system, regardless of the
> > operating system. If we are willing to give that up, we may just
> > make htpasswd use the more advanced schemes offered by the
> > system's crypt() function.
>
> One complication to keep in mind: when you don't do all your
> cryptography via a specific crypto library (OpenSSL, NSS, etc.)
> then FIPS 140-2 compliance goes from trivial (for 2.4) to messy.
> Not generally a problem outside of the U.S., but it very much
> matters anywhere in the U.S. government market.
The APR-MD5 password hashing is already implemented in apr-util and
does not use an external crypto library. Would another password hashin
algorithm chang anything? Or is it already necessary for FIPS
compliance to patch apr-util or httpd?
Cheers,
Stefan
Re: Choosing a stronger password hash algorithm
Posted by Ben Laurie <be...@links.org>.
On Mon, Jul 2, 2012 at 8:46 PM, Stefan Fritsch <sf...@sfritsch.de> wrote:
> On Monday 02 July 2012, Ben Laurie wrote:
>> FWIW, I am not super-keen on this particular move. Whilst bcrypt is
>> certainly an improvement, I am wary of relying on Blowfish - it is
>> not a mainstream cipher and is not subject to the kind of scrutiny
>> that, say, AES or SHA-2/3 are.
>>
>> If we are going to change, then we should change to a mechanism
>> that is subject to ongoing cryptanalysis.
>
>
> bcrypt has the advantage that it currently does not give much speed-up
> of GPUs versus CPUs. So brute-forcing is more difficult than e.g. for
> glibc's sha256 or sha512 based algorithms. And we can't just
> arbitrarily increase the number of rounds because that would make
> httpd prone to DoS attacks. My rationale for bcrypt is here:
>
> http://mail-archives.apache.org/mod_mbox/apr-
> dev/201206.mbox/%3C201206232242.42669.sf%40sfritsch.de%3E
>
> Your comments on that would be welcome.
I don't have any response beyond what I said above. I agree about the
GPU vs CPU thing, though I'd really advocate for sufficient salt and
good passwords!
> Due to Poul-Henning Kamp's declaration that md5crypt is insecure,
> there is some renewed interest in this field. Maybe there will be a
> new algorithm soon that is both difficult to brute-force on GPUs and
> based on something standard like AES or SHA*.
>
> Maybe we could add bcrypt for now and if something better appears,
> then add that as well?
I guess. I admit I find it hard to imagine that bcrypt would be broken
any time soon. I wish there was a better answer.
Re: Choosing a stronger password hash algorithm
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Monday 02 July 2012, Ben Laurie wrote:
> FWIW, I am not super-keen on this particular move. Whilst bcrypt is
> certainly an improvement, I am wary of relying on Blowfish - it is
> not a mainstream cipher and is not subject to the kind of scrutiny
> that, say, AES or SHA-2/3 are.
>
> If we are going to change, then we should change to a mechanism
> that is subject to ongoing cryptanalysis.
bcrypt has the advantage that it currently does not give much speed-up
of GPUs versus CPUs. So brute-forcing is more difficult than e.g. for
glibc's sha256 or sha512 based algorithms. And we can't just
arbitrarily increase the number of rounds because that would make
httpd prone to DoS attacks. My rationale for bcrypt is here:
http://mail-archives.apache.org/mod_mbox/apr-
dev/201206.mbox/%3C201206232242.42669.sf%40sfritsch.de%3E
Your comments on that would be welcome.
Due to Poul-Henning Kamp's declaration that md5crypt is insecure,
there is some renewed interest in this field. Maybe there will be a
new algorithm soon that is both difficult to brute-force on GPUs and
based on something standard like AES or SHA*.
Maybe we could add bcrypt for now and if something better appears,
then add that as well?
Cheers,
Stefan
Re: Choosing a stronger password hash algorithm
Posted by Ben Laurie <be...@links.org>.
FWIW, I am not super-keen on this particular move. Whilst bcrypt is
certainly an improvement, I am wary of relying on Blowfish - it is not
a mainstream cipher and is not subject to the kind of scrutiny that,
say, AES or SHA-2/3 are.
If we are going to change, then we should change to a mechanism that
is subject to ongoing cryptanalysis.
On Mon, Jul 2, 2012 at 8:02 PM, Stefan Fritsch <sf...@sfritsch.de> wrote:
> On Sunday 01 July 2012, William A. Rowe Jr. wrote:
>> On 6/29/2012 4:23 AM, Stefan Fritsch wrote:
>> > Therefore I will go ahead and add bcrypt support to apr-util
>> > which will be a big improvement for the 95% of users who don't
>> > need FIPS.
>>
>> It sounds to me that after we spent a great deal of time to make
>> APR largely library agnostic, you are insisting on binding us to a
>> specific library. I would be very hostile to that.
>>
>
> No. As I have mentioned in one of the other mails, I prefer importing
> a suitably licensed version of the source code.
>
> What I currently have is
>
> http://people.apache.org/~sf/apr_bcrypt_password_support.diff
>
> diffstat:
>
> build.conf | 2
> crypto/apr_md5.c | 145 -------
> crypto/apr_passwd.c | 196 ++++++++++
> crypto/crypt_blowfish.c | 902 ++++++++++++++++++++++++++++++++++++++
> crypto/crypt_blowfish.h | 27 +
> include/apr_md5.h | 5
>
>
>> If you are talking about a plugable, client-agnostic approach which
>> the user can ignore the details of how apr was built, that would be
>> fine.
>>
>> Before throwing code at APR, please post a patch, because the group
>> might largely be in agreement. The delta to configure.in and the
>> headers is probably sufficient for now. But if your solution is to
>> add more mandatory dependencies or make apr less flexible, it would
>> be met with resistance.
>
> No new dependency, no configure.in change. Instead I add two files
> from the crypt_blowfish distribution. I intend to make some benchmarks
> with the assembler version, but it says it was written for Pentium 1,
> so I am not so sure that it will greatly improve performance on
> current processors. If it is actually significantly faster than the
> pure C version, I would add it plus the necessary build logic. That
> would mean one additional file (there is only an assembler version for
> i386).
>
> The diff of crypt_blowfish.c versus upstream is one line. So importing
> new versions if there happen to be any upgrades should be easy.
>
>>
>> The user should remain largely oblivious whether the pw crypt used
>> lives in bcrypt or openssl or the kernel, and the resulting pw data
>> should be always portable between different builds of apr. This
>> was the logic behind the sha1, md5 and other common password
>> schemes. The crypt scheme was an exception, one which can be
>> resolved even on win32 and hpux with the use of openssl's crypt
>> implementation or linking to fcrypt.
>>
>> Platform or library binding dependent pw data takes us back to
>> 1999.
>
> Yes. That's why I was sceptical about using apr_crypto for this task,
> too. After all, apr_crypto is still optional.
>
> Cheers,
> Stefan
Re: Choosing a stronger password hash algorithm
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Sunday 01 July 2012, William A. Rowe Jr. wrote:
> On 6/29/2012 4:23 AM, Stefan Fritsch wrote:
> > Therefore I will go ahead and add bcrypt support to apr-util
> > which will be a big improvement for the 95% of users who don't
> > need FIPS.
>
> It sounds to me that after we spent a great deal of time to make
> APR largely library agnostic, you are insisting on binding us to a
> specific library. I would be very hostile to that.
>
No. As I have mentioned in one of the other mails, I prefer importing
a suitably licensed version of the source code.
What I currently have is
http://people.apache.org/~sf/apr_bcrypt_password_support.diff
diffstat:
build.conf | 2
crypto/apr_md5.c | 145 -------
crypto/apr_passwd.c | 196 ++++++++++
crypto/crypt_blowfish.c | 902 ++++++++++++++++++++++++++++++++++++++
crypto/crypt_blowfish.h | 27 +
include/apr_md5.h | 5
> If you are talking about a plugable, client-agnostic approach which
> the user can ignore the details of how apr was built, that would be
> fine.
>
> Before throwing code at APR, please post a patch, because the group
> might largely be in agreement. The delta to configure.in and the
> headers is probably sufficient for now. But if your solution is to
> add more mandatory dependencies or make apr less flexible, it would
> be met with resistance.
No new dependency, no configure.in change. Instead I add two files
from the crypt_blowfish distribution. I intend to make some benchmarks
with the assembler version, but it says it was written for Pentium 1,
so I am not so sure that it will greatly improve performance on
current processors. If it is actually significantly faster than the
pure C version, I would add it plus the necessary build logic. That
would mean one additional file (there is only an assembler version for
i386).
The diff of crypt_blowfish.c versus upstream is one line. So importing
new versions if there happen to be any upgrades should be easy.
>
> The user should remain largely oblivious whether the pw crypt used
> lives in bcrypt or openssl or the kernel, and the resulting pw data
> should be always portable between different builds of apr. This
> was the logic behind the sha1, md5 and other common password
> schemes. The crypt scheme was an exception, one which can be
> resolved even on win32 and hpux with the use of openssl's crypt
> implementation or linking to fcrypt.
>
> Platform or library binding dependent pw data takes us back to
> 1999.
Yes. That's why I was sceptical about using apr_crypto for this task,
too. After all, apr_crypto is still optional.
Cheers,
Stefan
Re: Choosing a stronger password hash algorithm
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 6/29/2012 4:23 AM, Stefan Fritsch wrote:
>
> Therefore I will go ahead and add bcrypt support to apr-util which
> will be a big improvement for the 95% of users who don't need FIPS.
It sounds to me that after we spent a great deal of time to make APR
largely library agnostic, you are insisting on binding us to a specific
library. I would be very hostile to that.
If you are talking about a plugable, client-agnostic approach which
the user can ignore the details of how apr was built, that would be
fine.
Before throwing code at APR, please post a patch, because the group
might largely be in agreement. The delta to configure.in and the
headers is probably sufficient for now. But if your solution is to
add more mandatory dependencies or make apr less flexible, it would
be met with resistance.
The user should remain largely oblivious whether the pw crypt used
lives in bcrypt or openssl or the kernel, and the resulting pw data
should be always portable between different builds of apr. This was
the logic behind the sha1, md5 and other common password schemes.
The crypt scheme was an exception, one which can be resolved even
on win32 and hpux with the use of openssl's crypt implementation
or linking to fcrypt.
Platform or library binding dependent pw data takes us back to 1999.
Re: Choosing a stronger password hash algorithm
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Tuesday 26 June 2012, William A. Rowe Jr. wrote:
> On 6/24/2012 3:34 AM, Stefan Fritsch wrote:
> > On Sunday 24 June 2012, Graham Leggett wrote:
> >> Ideally, like we have a generic synchronous encryption API, we
> >> should have a generic hash API too, so that the user can use
> >> whatever hash that the underlying toolkit provides.
> >
> > I rather like the fact that you can use htpasswd on one system
> > and use the result on another system, regardless of the
> > operating system. If we are willing to give that up, we may just
> > make htpasswd use the more advanced schemes offered by the
> > system's crypt() function.
>
> You misunderstand. The algorithms need to exist in the apr crypt
> implementation.
Passing some salt string like "$6$" to crypt() is just a different way
to call a library. And on FIPS compliant systems, the system's
password hashes are likely also FIPS compliant. But this approach
would not work for platforms like Windows that don't have crypt().
> We might choose to provide 'fallback' implementations if the are
> absent.
>
> This gets you to things like FIPS-140-2 implementations when APR is
> correctly configured and built, without the hassle of validating
> our own implementation. We aren't put in a position of
> implementing the assembly language optimized flavor, because the
> library vendor has already done this.
>
> Nobody is talking about crypt(), although generic implementations
> of crypt() are offered by openssl and likely from gnutls etc.
There is some confusion here between crypt() the function and crypt
the algorithm (i.e. DES-crypt). On Linux and BSDs, crypt() supports
more secure algorithms than DES-crypt.
>
> > Also, using what is available in the crypto libraries would limit
> > us to PKCS5/PBKDF2, which is the only password hashing algorithm
> > supported by openssl (AFAICS). Since PBKDF2 is based on sha256,
> > though, it scales relatively well on GPUs. Of course, we could
> > also implement other schemes on top of some cryptographhic hash
> > or cipher provided by the crypto libraries. But I would rather
> > avoid that because it's a lot of work to verify the result.
>
> Take a quick glance through these two drafts;
>
>
http://csrc.nist.gov/publications/drafts/800-107/Draft_Revised_SP800-107.pdf
> http://csrc.nist.gov/publications/drafts/800-118/draft-sp800-118.pdf
>
> I think we may be dwelling too much on computation time. The
> larger issue is better seeding. An illicitly obtained password
> file of hashed p/w's will always be a risk to the accounts,
> irrespective of computation time. What is critical is the seeding
> such that duplicate passwords are not obvious, and that passwords
> recycled on other services don't demonstrate the same hash (ergo,
> collision) value.
The first paper doesn't mention password hashing at all. The second
one mentions stretching only to make creation of rainbow tables more
difficult. But increasing computation time by stretching is also
important for simple brute force attacks without rainbow tables. And
the reason why the md5crypt author has recently declared his algorithm
insecure is the too low computation time and nothing else.
The salting definitely can be improved. htpasswd only uses 2^32
different values on a given libc. htdbm only uses the timestamp as
salt.
Apart from that I think that we should do both things: Add a good non-
FIPS compliant algorithm that is built into APR and a FIPS compliant
variant (whatever that is). The former is straightforward but the
latter isn't. For example with PBKDF2, you have to define an output
format because none is defined yet. Also, one must choose a suitable
size of the resulting key. And I don't really know if PBKDF2 is
actually FIPS compliant. Then there is the question of the API: Would
we add a replacement function for apr_password_validate() that also
takes an apr_crypto_driver_t argument? Or would we make some
apr_password_set_driver() function that sets the driver to be used by
apr_password_validate()? Do we also need a way to disable non-FIPS
compliant algorithms?
Therefore I will go ahead and add bcrypt support to apr-util which
will be a big improvement for the 95% of users who don't need FIPS. I
would be willing to help anyone who wants to add a FIPS compliant
scheme, but I am not going to do the necessary research myself. And I
don't think we should delay the release of a new apr-util with bcrypt
support for a FIPS compliant scheme that may or may not be added in
the future.
Cheers,
Stefan
Re: Choosing a stronger password hash algorithm
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Tuesday 26 June 2012, William A. Rowe Jr. wrote:
> On 6/24/2012 3:34 AM, Stefan Fritsch wrote:
> > On Sunday 24 June 2012, Graham Leggett wrote:
> >> Ideally, like we have a generic synchronous encryption API, we
> >> should have a generic hash API too, so that the user can use
> >> whatever hash that the underlying toolkit provides.
> >
> > I rather like the fact that you can use htpasswd on one system
> > and use the result on another system, regardless of the
> > operating system. If we are willing to give that up, we may just
> > make htpasswd use the more advanced schemes offered by the
> > system's crypt() function.
>
> You misunderstand. The algorithms need to exist in the apr crypt
> implementation.
Passing some salt string like "$6$" to crypt() is just a different way
to call a library. And on FIPS compliant systems, the system's
password hashes are likely also FIPS compliant. But this approach
would not work for platforms like Windows that don't have crypt().
> We might choose to provide 'fallback' implementations if the are
> absent.
>
> This gets you to things like FIPS-140-2 implementations when APR is
> correctly configured and built, without the hassle of validating
> our own implementation. We aren't put in a position of
> implementing the assembly language optimized flavor, because the
> library vendor has already done this.
>
> Nobody is talking about crypt(), although generic implementations
> of crypt() are offered by openssl and likely from gnutls etc.
There is some confusion here between crypt() the function and crypt
the algorithm (i.e. DES-crypt). On Linux and BSDs, crypt() supports
more secure algorithms than DES-crypt.
>
> > Also, using what is available in the crypto libraries would limit
> > us to PKCS5/PBKDF2, which is the only password hashing algorithm
> > supported by openssl (AFAICS). Since PBKDF2 is based on sha256,
> > though, it scales relatively well on GPUs. Of course, we could
> > also implement other schemes on top of some cryptographhic hash
> > or cipher provided by the crypto libraries. But I would rather
> > avoid that because it's a lot of work to verify the result.
>
> Take a quick glance through these two drafts;
>
>
http://csrc.nist.gov/publications/drafts/800-107/Draft_Revised_SP800-107.pdf
> http://csrc.nist.gov/publications/drafts/800-118/draft-sp800-118.pdf
>
> I think we may be dwelling too much on computation time. The
> larger issue is better seeding. An illicitly obtained password
> file of hashed p/w's will always be a risk to the accounts,
> irrespective of computation time. What is critical is the seeding
> such that duplicate passwords are not obvious, and that passwords
> recycled on other services don't demonstrate the same hash (ergo,
> collision) value.
The first paper doesn't mention password hashing at all. The second
one mentions stretching only to make creation of rainbow tables more
difficult. But increasing computation time by stretching is also
important for simple brute force attacks without rainbow tables. And
the reason why the md5crypt author has recently declared his algorithm
insecure is the too low computation time and nothing else.
The salting definitely can be improved. htpasswd only uses 2^32
different values on a given libc. htdbm only uses the timestamp as
salt.
Apart from that I think that we should do both things: Add a good non-
FIPS compliant algorithm that is built into APR and a FIPS compliant
variant (whatever that is). The former is straightforward but the
latter isn't. For example with PBKDF2, you have to define an output
format because none is defined yet. Also, one must choose a suitable
size of the resulting key. And I don't really know if PBKDF2 is
actually FIPS compliant. Then there is the question of the API: Would
we add a replacement function for apr_password_validate() that also
takes an apr_crypto_driver_t argument? Or would we make some
apr_password_set_driver() function that sets the driver to be used by
apr_password_validate()? Do we also need a way to disable non-FIPS
compliant algorithms?
Therefore I will go ahead and add bcrypt support to apr-util which
will be a big improvement for the 95% of users who don't need FIPS. I
would be willing to help anyone who wants to add a FIPS compliant
scheme, but I am not going to do the necessary research myself. And I
don't think we should delay the release of a new apr-util with bcrypt
support for a FIPS compliant scheme that may or may not be added in
the future.
Cheers,
Stefan
Re: Choosing a stronger password hash algorithm
Posted by Steve Marquess <ma...@opensslfoundation.com>.
On 06/24/2012 04:34 AM, Stefan Fritsch wrote:
> On Sunday 24 June 2012, Graham Leggett wrote:
>> On 24 Jun 2012, at 12:01 AM, Stefan Fritsch wrote:
>>> Openssl is not required, neither for apr nor for httpd. I propose
>>> to import either crypt_blowfish or scrypt into apr, just like
>>> apr contains some foreign sha1 and md5 code. This way we would
>>> not get an additional external dependency.
>>
>> APR-util has a crypto library to deal with this exact problem - the
>> need for low level crypto functions without having to tightly bind
>> ourselves to one toolkit over another, or import code. With the
>> formal move by the Redhat people towards NSS as a shared crypto
>> API, this becomes more important as time goes by.
>>
>> Ideally, like we have a generic synchronous encryption API, we
>> should have a generic hash API too, so that the user can use
>> whatever hash that the underlying toolkit provides.
>
> I rather like the fact that you can use htpasswd on one system and use
> the result on another system, regardless of the operating system. If
> we are willing to give that up, we may just make htpasswd use the more
> advanced schemes offered by the system's crypt() function.
One complication to keep in mind: when you don't do all your
cryptography via a specific crypto library (OpenSSL, NSS, etc.) then
FIPS 140-2 compliance goes from trivial (for 2.4) to messy. Not
generally a problem outside of the U.S., but it very much matters
anywhere in the U.S. government market.
-Steve M.
--
Steve Marquess
OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess@opensslfoundation.com
marquess@openssl.com
Re: Choosing a stronger password hash algorithm
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 6/24/2012 3:34 AM, Stefan Fritsch wrote:
> On Sunday 24 June 2012, Graham Leggett wrote:
>>
>> Ideally, like we have a generic synchronous encryption API, we
>> should have a generic hash API too, so that the user can use
>> whatever hash that the underlying toolkit provides.
>
> I rather like the fact that you can use htpasswd on one system and use
> the result on another system, regardless of the operating system. If
> we are willing to give that up, we may just make htpasswd use the more
> advanced schemes offered by the system's crypt() function.
You misunderstand. The algorithms need to exist in the apr crypt
implementation.
We might choose to provide 'fallback' implementations if the are absent.
This gets you to things like FIPS-140-2 implementations when APR is
correctly configured and built, without the hassle of validating our
own implementation. We aren't put in a position of implementing the
assembly language optimized flavor, because the library vendor has
already done this.
Nobody is talking about crypt(), although generic implementations of
crypt() are offered by openssl and likely from gnutls etc.
> Also, using what is available in the crypto libraries would limit us
> to PKCS5/PBKDF2, which is the only password hashing algorithm
> supported by openssl (AFAICS). Since PBKDF2 is based on sha256,
> though, it scales relatively well on GPUs. Of course, we could also
> implement other schemes on top of some cryptographhic hash or cipher
> provided by the crypto libraries. But I would rather avoid that
> because it's a lot of work to verify the result.
Take a quick glance through these two drafts;
http://csrc.nist.gov/publications/drafts/800-107/Draft_Revised_SP800-107.pdf
http://csrc.nist.gov/publications/drafts/800-118/draft-sp800-118.pdf
I think we may be dwelling too much on computation time. The larger issue
is better seeding. An illicitly obtained password file of hashed p/w's
will always be a risk to the accounts, irrespective of computation time.
What is critical is the seeding such that duplicate passwords are not
obvious, and that passwords recycled on other services don't demonstrate
the same hash (ergo, collision) value.
Re: Choosing a stronger password hash algorithm
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 6/24/2012 3:34 AM, Stefan Fritsch wrote:
> On Sunday 24 June 2012, Graham Leggett wrote:
>>
>> Ideally, like we have a generic synchronous encryption API, we
>> should have a generic hash API too, so that the user can use
>> whatever hash that the underlying toolkit provides.
>
> I rather like the fact that you can use htpasswd on one system and use
> the result on another system, regardless of the operating system. If
> we are willing to give that up, we may just make htpasswd use the more
> advanced schemes offered by the system's crypt() function.
You misunderstand. The algorithms need to exist in the apr crypt
implementation.
We might choose to provide 'fallback' implementations if the are absent.
This gets you to things like FIPS-140-2 implementations when APR is
correctly configured and built, without the hassle of validating our
own implementation. We aren't put in a position of implementing the
assembly language optimized flavor, because the library vendor has
already done this.
Nobody is talking about crypt(), although generic implementations of
crypt() are offered by openssl and likely from gnutls etc.
> Also, using what is available in the crypto libraries would limit us
> to PKCS5/PBKDF2, which is the only password hashing algorithm
> supported by openssl (AFAICS). Since PBKDF2 is based on sha256,
> though, it scales relatively well on GPUs. Of course, we could also
> implement other schemes on top of some cryptographhic hash or cipher
> provided by the crypto libraries. But I would rather avoid that
> because it's a lot of work to verify the result.
Take a quick glance through these two drafts;
http://csrc.nist.gov/publications/drafts/800-107/Draft_Revised_SP800-107.pdf
http://csrc.nist.gov/publications/drafts/800-118/draft-sp800-118.pdf
I think we may be dwelling too much on computation time. The larger issue
is better seeding. An illicitly obtained password file of hashed p/w's
will always be a risk to the accounts, irrespective of computation time.
What is critical is the seeding such that duplicate passwords are not
obvious, and that passwords recycled on other services don't demonstrate
the same hash (ergo, collision) value.
Re: Choosing a stronger password hash algorithm
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Sunday 24 June 2012, Graham Leggett wrote:
> On 24 Jun 2012, at 12:01 AM, Stefan Fritsch wrote:
> > Openssl is not required, neither for apr nor for httpd. I propose
> > to import either crypt_blowfish or scrypt into apr, just like
> > apr contains some foreign sha1 and md5 code. This way we would
> > not get an additional external dependency.
>
> APR-util has a crypto library to deal with this exact problem - the
> need for low level crypto functions without having to tightly bind
> ourselves to one toolkit over another, or import code. With the
> formal move by the Redhat people towards NSS as a shared crypto
> API, this becomes more important as time goes by.
>
> Ideally, like we have a generic synchronous encryption API, we
> should have a generic hash API too, so that the user can use
> whatever hash that the underlying toolkit provides.
I rather like the fact that you can use htpasswd on one system and use
the result on another system, regardless of the operating system. If
we are willing to give that up, we may just make htpasswd use the more
advanced schemes offered by the system's crypt() function.
Also, using what is available in the crypto libraries would limit us
to PKCS5/PBKDF2, which is the only password hashing algorithm
supported by openssl (AFAICS). Since PBKDF2 is based on sha256,
though, it scales relatively well on GPUs. Of course, we could also
implement other schemes on top of some cryptographhic hash or cipher
provided by the crypto libraries. But I would rather avoid that
because it's a lot of work to verify the result.
Re: Choosing a stronger password hash algorithm
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Sunday 24 June 2012, Graham Leggett wrote:
> On 24 Jun 2012, at 12:01 AM, Stefan Fritsch wrote:
> > Openssl is not required, neither for apr nor for httpd. I propose
> > to import either crypt_blowfish or scrypt into apr, just like
> > apr contains some foreign sha1 and md5 code. This way we would
> > not get an additional external dependency.
>
> APR-util has a crypto library to deal with this exact problem - the
> need for low level crypto functions without having to tightly bind
> ourselves to one toolkit over another, or import code. With the
> formal move by the Redhat people towards NSS as a shared crypto
> API, this becomes more important as time goes by.
>
> Ideally, like we have a generic synchronous encryption API, we
> should have a generic hash API too, so that the user can use
> whatever hash that the underlying toolkit provides.
I rather like the fact that you can use htpasswd on one system and use
the result on another system, regardless of the operating system. If
we are willing to give that up, we may just make htpasswd use the more
advanced schemes offered by the system's crypt() function.
Also, using what is available in the crypto libraries would limit us
to PKCS5/PBKDF2, which is the only password hashing algorithm
supported by openssl (AFAICS). Since PBKDF2 is based on sha256,
though, it scales relatively well on GPUs. Of course, we could also
implement other schemes on top of some cryptographhic hash or cipher
provided by the crypto libraries. But I would rather avoid that
because it's a lot of work to verify the result.
Re: Choosing a stronger password hash algorithm
Posted by Nick Edwards <ni...@gmail.com>.
Away on holidays, late reply, apologies.
I would like to see bcrypt introduced, a number of sites seem to be
moving that way, would be nice if apache did too!
On 6/24/12, Stefan Fritsch <sf...@sfritsch.de> wrote:
> On Saturday 23 June 2012, William A. Rowe Jr. wrote:
>> On 6/23/2012 3:42 PM, Stefan Fritsch wrote:
>> > bcrypt [1] and scrypt [2] seem to be much more difficult to port
>> > to hardware or GPUs than sha256/512_crypt [3-5]. We can't make
>> > the operation too expensive on normal CPUs or we create a DoS
>> > problem if someone does lots of requests with wrong passwords.
>> > Therefore I think choosing an algorithm that does not scale well
>> > on more specialized hardware is good.
>> >
>> > Both bcrypt and scrypt can be adjusted in how much CPU time to
>> > use. scrypt can also be adjusted in how much RAM it uses. bcrypt
>> > uses a 128bit salt, AFAICS scrypt can use arbitrary salt
>> > lengths.
>> >
>> > Bcrypt has seen a lot more review than scrypt, therefore I am
>> > somewhat in favor of bcrypt. Crypt_blowfish [6] is an
>> > implementation with a very liberal license that we could use.
>> > Scrypt has a 2-clause BSD license which would also be OK.
>> >
>> > Opinions?
>>
>> We already have integration points to openssl, why add yet another
>> dependency? Seems foolish.
>
> Openssl is not required, neither for apr nor for httpd. I propose to
> import either crypt_blowfish or scrypt into apr, just like apr
> contains some foreign sha1 and md5 code. This way we would not get an
> additional external dependency.
>
Re: Choosing a stronger password hash algorithm
Posted by Graham Leggett <mi...@sharp.fm>.
On 24 Jun 2012, at 12:01 AM, Stefan Fritsch wrote:
> Openssl is not required, neither for apr nor for httpd. I propose to
> import either crypt_blowfish or scrypt into apr, just like apr
> contains some foreign sha1 and md5 code. This way we would not get an
> additional external dependency.
APR-util has a crypto library to deal with this exact problem - the need for low level crypto functions without having to tightly bind ourselves to one toolkit over another, or import code. With the formal move by the Redhat people towards NSS as a shared crypto API, this becomes more important as time goes by.
Ideally, like we have a generic synchronous encryption API, we should have a generic hash API too, so that the user can use whatever hash that the underlying toolkit provides.
Regards,
Graham
--
Re: Choosing a stronger password hash algorithm
Posted by Graham Leggett <mi...@sharp.fm>.
On 24 Jun 2012, at 12:01 AM, Stefan Fritsch wrote:
> Openssl is not required, neither for apr nor for httpd. I propose to
> import either crypt_blowfish or scrypt into apr, just like apr
> contains some foreign sha1 and md5 code. This way we would not get an
> additional external dependency.
APR-util has a crypto library to deal with this exact problem - the need for low level crypto functions without having to tightly bind ourselves to one toolkit over another, or import code. With the formal move by the Redhat people towards NSS as a shared crypto API, this becomes more important as time goes by.
Ideally, like we have a generic synchronous encryption API, we should have a generic hash API too, so that the user can use whatever hash that the underlying toolkit provides.
Regards,
Graham
--
Re: Choosing a stronger password hash algorithm
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Saturday 23 June 2012, William A. Rowe Jr. wrote:
> On 6/23/2012 3:42 PM, Stefan Fritsch wrote:
> > bcrypt [1] and scrypt [2] seem to be much more difficult to port
> > to hardware or GPUs than sha256/512_crypt [3-5]. We can't make
> > the operation too expensive on normal CPUs or we create a DoS
> > problem if someone does lots of requests with wrong passwords.
> > Therefore I think choosing an algorithm that does not scale well
> > on more specialized hardware is good.
> >
> > Both bcrypt and scrypt can be adjusted in how much CPU time to
> > use. scrypt can also be adjusted in how much RAM it uses. bcrypt
> > uses a 128bit salt, AFAICS scrypt can use arbitrary salt
> > lengths.
> >
> > Bcrypt has seen a lot more review than scrypt, therefore I am
> > somewhat in favor of bcrypt. Crypt_blowfish [6] is an
> > implementation with a very liberal license that we could use.
> > Scrypt has a 2-clause BSD license which would also be OK.
> >
> > Opinions?
>
> We already have integration points to openssl, why add yet another
> dependency? Seems foolish.
Openssl is not required, neither for apr nor for httpd. I propose to
import either crypt_blowfish or scrypt into apr, just like apr
contains some foreign sha1 and md5 code. This way we would not get an
additional external dependency.
Re: Choosing a stronger password hash algorithm
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Saturday 23 June 2012, William A. Rowe Jr. wrote:
> On 6/23/2012 3:42 PM, Stefan Fritsch wrote:
> > bcrypt [1] and scrypt [2] seem to be much more difficult to port
> > to hardware or GPUs than sha256/512_crypt [3-5]. We can't make
> > the operation too expensive on normal CPUs or we create a DoS
> > problem if someone does lots of requests with wrong passwords.
> > Therefore I think choosing an algorithm that does not scale well
> > on more specialized hardware is good.
> >
> > Both bcrypt and scrypt can be adjusted in how much CPU time to
> > use. scrypt can also be adjusted in how much RAM it uses. bcrypt
> > uses a 128bit salt, AFAICS scrypt can use arbitrary salt
> > lengths.
> >
> > Bcrypt has seen a lot more review than scrypt, therefore I am
> > somewhat in favor of bcrypt. Crypt_blowfish [6] is an
> > implementation with a very liberal license that we could use.
> > Scrypt has a 2-clause BSD license which would also be OK.
> >
> > Opinions?
>
> We already have integration points to openssl, why add yet another
> dependency? Seems foolish.
Openssl is not required, neither for apr nor for httpd. I propose to
import either crypt_blowfish or scrypt into apr, just like apr
contains some foreign sha1 and md5 code. This way we would not get an
additional external dependency.
Re: Choosing a stronger password hash algorithm
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 6/23/2012 3:42 PM, Stefan Fritsch wrote:
>
> bcrypt [1] and scrypt [2] seem to be much more difficult to port to
> hardware or GPUs than sha256/512_crypt [3-5]. We can't make the
> operation too expensive on normal CPUs or we create a DoS problem if
> someone does lots of requests with wrong passwords. Therefore I think
> choosing an algorithm that does not scale well on more specialized
> hardware is good.
>
> Both bcrypt and scrypt can be adjusted in how much CPU time to use.
> scrypt can also be adjusted in how much RAM it uses. bcrypt uses a
> 128bit salt, AFAICS scrypt can use arbitrary salt lengths.
>
> Bcrypt has seen a lot more review than scrypt, therefore I am somewhat
> in favor of bcrypt. Crypt_blowfish [6] is an implementation with a
> very liberal license that we could use. Scrypt has a 2-clause BSD
> license which would also be OK.
>
> Opinions?
We already have integration points to openssl, why add yet another
dependency? Seems foolish.