[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apr-dev
Subject:    Re: Choosing a stronger password hash algorithm
From:       Ben Laurie <ben () links ! org>
Date:       2012-07-02 19:54:27
Message-ID: CAG5KPzz5cVbiNSB9gkxeSGTC5KOjC0B5SegsdPq6WSJwVaV8gg () mail ! gmail ! com
[Download RAW message or body]

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.
[prev in list] [next in list] [prev in thread] [next in thread]