apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch ...@sfritsch.de>
Subject Re: Choosing a stronger password hash algorithm
Date Sat, 23 Jun 2012 22:01:45 GMT
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