httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Edwards <nick.z.edwa...@gmail.com>
Subject Re: Choosing a stronger password hash algorithm
Date Thu, 12 Jul 2012 11:03:17 GMT
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.
>

Mime
View raw message