You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Robert Newson <rn...@apache.org> on 2011/07/06 14:43:12 UTC
Improving password hashing.
All,
Our current password hashing scheme is weak. In fact, it's regarded as
weak as plaintext. I'd like to change that.
Some time ago I wrote some code to implement the PBKDF2 protocol. This
is a cryptographically sound means of deriving a key from a password.
The output is also usable as a password hash. An important part of the
protocol is that the work factor can be increased by increasing the
loop count. Additionally, it is not tied to a specific digest
algorithm. All these points are not true of the sometimes proposed
alternative called 'bcrypt' which I do not recommend.
I would like this to go into CouchDB 1.2. New passwords, and updated
passwords, from 1.2 onwards would use the new scheme, but 1.2 will,
obviously, be able to verify the current style. This work will take
place within couch_server where hash_admin_passwords currently lives.
The PKBDF2 code is here:
https://github.com/rnewson/couchdb/tree/pbkdf2. It passes all the test
vectors.
The ticket for this work is https://issues.apache.org/jira/browse/COUCHDB-1060
B.
Re: Improving password hashing.
Posted by Terry Smith <te...@gmail.com>.
While we're on the subject of password hashing I discovered an inconsistency
with respect to the password salt deserialization in the current
implementation. I haven't looked at your new code, Bob, so I don't know if
hex deserialization is relevant to it or not, but I wanted to pass this
information along.
Here's what I found.
A password's salt is defined as "(128 bit UUID generated by the crypto lib)"
from here
http://mail-archives.apache.org/mod_mbox/incubator-couchdb-dev/200810.mbox/%3cFEC771A6-9020-4C30-99A2-C4591B3066E1@apache.org%3e.
The salt starts out that way but then it is converted to a string
representation of the bytes via couch_util:to_hex(). When the hash of the
password + salt is taken the bytes for the character codes of the string
version of the 128 bit UUID are used as the salt. I'll use a 3 byte salt for
an example.
The bytes are 16#3f 16#db 16#ef
to_hex() returns "3fdbef"
list_to_binary() then converts the string into <<"3fdbef"">>... this is the
list of character codes for each character in the string. The bytes are
16#33, 16#66, 16#64, 16#62, 16#65, 16#66. This is the actual salt.
I discovered this because I am setting up an admin's name, hash and salt in
CouchDB's local.ini with an external program (because of my organization's
security requirements), but authentication in CouchDB failed with a
different hash result. I did not convert my 16 byte salt to a string and
then use those bytes (character codes) for the salt. Once I did
authentication in CouchDB succeeded.
The end result is harmless so I worked on the rest of my project and would
report it at a later time to be documented if needed. Coincidentally, I have
some time now and your proposal spurred me to finally report it.
--Terry
On Wed, Jul 6, 2011 at 9:10 AM, Robert Newson <rn...@apache.org> wrote:
> Making it pluggable is probably not much more work but I have to point
> at that "use sha256" is an inadequate description of a secure password
> hashing protocol.
>
> B.
>
> On 6 July 2011 14:05, Benoit Chesneau <bc...@gmail.com> wrote:
> > On Wed, Jul 6, 2011 at 2:43 PM, Robert Newson <rn...@apache.org>
> wrote:
> >> All,
> >>
> >> Our current password hashing scheme is weak. In fact, it's regarded as
> >> weak as plaintext. I'd like to change that.
> >>
> >> Some time ago I wrote some code to implement the PBKDF2 protocol. This
> >> is a cryptographically sound means of deriving a key from a password.
> >> The output is also usable as a password hash. An important part of the
> >> protocol is that the work factor can be increased by increasing the
> >> loop count. Additionally, it is not tied to a specific digest
> >> algorithm. All these points are not true of the sometimes proposed
> >> alternative called 'bcrypt' which I do not recommend.
> >>
> >> I would like this to go into CouchDB 1.2. New passwords, and updated
> >> passwords, from 1.2 onwards would use the new scheme, but 1.2 will,
> >> obviously, be able to verify the current style. This work will take
> >> place within couch_server where hash_admin_passwords currently lives.
> >>
> >> The PKBDF2 code is here:
> >> https://github.com/rnewson/couchdb/tree/pbkdf2. It passes all the test
> >> vectors.
> >>
> >> The ticket for this work is
> https://issues.apache.org/jira/browse/COUCHDB-1060
> >>
> >> B.
> >>
> > That sounds good. I would prefer however a customizable hashing method
> > for passwords so we can change it easily depending the target. Some
> > administrations for example require that you use some methods (like
> > sha256 in europe) and it would be very useful.
> >
> > - benoît
> >
>
Re: Improving password hashing.
Posted by Noah Slater <ns...@apache.org>.
On 6 Jul 2011, at 15:43, Robert Newson wrote:
> Essentially, in 1.2, I'm saying that the password setting
> functionality occurs solely on the Erlang side, it can't be done from
> Javascript any more. I'm unsure how controversial that is, but it's my
> experience that it's always the server that gets the plaintext of a
> password and hashes it for storage, it's only here that I've seen it
> done in the client.
There's a reason for this. Unless I'm missing something, if the client is allowed to submit the password hash itself, you may as well be using plaintext passwords. All an attacker would have to do is gain access to the hashes, and use them directly.
Re: Improving password hashing.
Posted by Robert Newson <rn...@apache.org>.
The pbkdf2 branch only proves that I implemented it correctly, the
integration work is still to be done and involves discussion.
We'll have to revisit the idea that you can send in pre-salted values
directly to the ini file or _users db. While it's practical in most
cases to do sha1(salt ++ password), the PBKDF2 algorithm is more
involved. Its security comes from its precise construction, we really
want one implementation of it.
Essentially, in 1.2, I'm saying that the password setting
functionality occurs solely on the Erlang side, it can't be done from
Javascript any more. I'm unsure how controversial that is, but it's my
experience that it's always the server that gets the plaintext of a
password and hashes it for storage, it's only here that I've seen it
done in the client.
B.
On 6 July 2011 15:26, Filipe David Manana <fd...@apache.org> wrote:
> After looking at it more closely I have 1 observation.
>
> The user's password can come either from the .ini file or from JSON
> coming from an HTTP post (couch_httpd_auth:handle_session_req/1 for
> example).
>
> I see that the password is passed to the new module, couch_passwords,
> which will end up calling cryto:sha_mac(Password, Salt).
>
> This concerns me because when the Password comes from the .ini config,
> it is a string and when it comes from JSON it is an UTF-8 binary.
> Before passing the password to crypto:sha_mac/2, I think it needs to
> be converted to an UTF-8 binary, otherwise it doesn't produce the same
> result as if it had came from JSON, example:
>
> 1> H1 = crypto:sha_mac("àbc", <<"123">>).
> <<149,17,150,46,220,128,255,66,209,115,186,23,167,63,117,
> 165,113,82,100,234>>
> 2>
> 2> H2 = crypto:sha_mac(unicode:characters_to_binary("àbc"), <<"123">>).
> <<30,96,182,160,202,26,142,36,32,79,28,250,228,105,79,11,
> 73,48,52,197>>
> 3>
> 3> H1 =:= H2.
> false
>
>
>
>
> On Wed, Jul 6, 2011 at 2:53 PM, Robert Newson <rn...@apache.org> wrote:
>> Patch will be tidied to community standards before submission.
>>
>> The upgrade code is not yet written but should be straightforward.
>>
>> B.
>>
>> On 6 July 2011 14:50, Filipe David Manana <fd...@apache.org> wrote:
>>> Looks good to me as well.
>>>
>>> Minor nitpick, ideally it would respect our coding standard of not
>>> having lines longer than 80 characters.
>>>
>>> Good work Robert
>>>
>>> On Wed, Jul 6, 2011 at 2:10 PM, Robert Newson <rn...@apache.org> wrote:
>>>> Making it pluggable is probably not much more work but I have to point
>>>> at that "use sha256" is an inadequate description of a secure password
>>>> hashing protocol.
>>>>
>>>> B.
>>>>
>>>> On 6 July 2011 14:05, Benoit Chesneau <bc...@gmail.com> wrote:
>>>>> On Wed, Jul 6, 2011 at 2:43 PM, Robert Newson <rn...@apache.org> wrote:
>>>>>> All,
>>>>>>
>>>>>> Our current password hashing scheme is weak. In fact, it's regarded as
>>>>>> weak as plaintext. I'd like to change that.
>>>>>>
>>>>>> Some time ago I wrote some code to implement the PBKDF2 protocol. This
>>>>>> is a cryptographically sound means of deriving a key from a password.
>>>>>> The output is also usable as a password hash. An important part of the
>>>>>> protocol is that the work factor can be increased by increasing the
>>>>>> loop count. Additionally, it is not tied to a specific digest
>>>>>> algorithm. All these points are not true of the sometimes proposed
>>>>>> alternative called 'bcrypt' which I do not recommend.
>>>>>>
>>>>>> I would like this to go into CouchDB 1.2. New passwords, and updated
>>>>>> passwords, from 1.2 onwards would use the new scheme, but 1.2 will,
>>>>>> obviously, be able to verify the current style. This work will take
>>>>>> place within couch_server where hash_admin_passwords currently lives.
>>>>>>
>>>>>> The PKBDF2 code is here:
>>>>>> https://github.com/rnewson/couchdb/tree/pbkdf2. It passes all the test
>>>>>> vectors.
>>>>>>
>>>>>> The ticket for this work is https://issues.apache.org/jira/browse/COUCHDB-1060
>>>>>>
>>>>>> B.
>>>>>>
>>>>> That sounds good. I would prefer however a customizable hashing method
>>>>> for passwords so we can change it easily depending the target. Some
>>>>> administrations for example require that you use some methods (like
>>>>> sha256 in europe) and it would be very useful.
>>>>>
>>>>> - benoît
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Filipe David Manana,
>>> fdmanana@gmail.com, fdmanana@apache.org
>>>
>>> "Reasonable men adapt themselves to the world.
>>> Unreasonable men adapt the world to themselves.
>>> That's why all progress depends on unreasonable men."
>>>
>>
>
>
>
> --
> Filipe David Manana,
> fdmanana@gmail.com, fdmanana@apache.org
>
> "Reasonable men adapt themselves to the world.
> Unreasonable men adapt the world to themselves.
> That's why all progress depends on unreasonable men."
>
Re: Improving password hashing.
Posted by Filipe David Manana <fd...@apache.org>.
After looking at it more closely I have 1 observation.
The user's password can come either from the .ini file or from JSON
coming from an HTTP post (couch_httpd_auth:handle_session_req/1 for
example).
I see that the password is passed to the new module, couch_passwords,
which will end up calling cryto:sha_mac(Password, Salt).
This concerns me because when the Password comes from the .ini config,
it is a string and when it comes from JSON it is an UTF-8 binary.
Before passing the password to crypto:sha_mac/2, I think it needs to
be converted to an UTF-8 binary, otherwise it doesn't produce the same
result as if it had came from JSON, example:
1> H1 = crypto:sha_mac("àbc", <<"123">>).
<<149,17,150,46,220,128,255,66,209,115,186,23,167,63,117,
165,113,82,100,234>>
2>
2> H2 = crypto:sha_mac(unicode:characters_to_binary("àbc"), <<"123">>).
<<30,96,182,160,202,26,142,36,32,79,28,250,228,105,79,11,
73,48,52,197>>
3>
3> H1 =:= H2.
false
On Wed, Jul 6, 2011 at 2:53 PM, Robert Newson <rn...@apache.org> wrote:
> Patch will be tidied to community standards before submission.
>
> The upgrade code is not yet written but should be straightforward.
>
> B.
>
> On 6 July 2011 14:50, Filipe David Manana <fd...@apache.org> wrote:
>> Looks good to me as well.
>>
>> Minor nitpick, ideally it would respect our coding standard of not
>> having lines longer than 80 characters.
>>
>> Good work Robert
>>
>> On Wed, Jul 6, 2011 at 2:10 PM, Robert Newson <rn...@apache.org> wrote:
>>> Making it pluggable is probably not much more work but I have to point
>>> at that "use sha256" is an inadequate description of a secure password
>>> hashing protocol.
>>>
>>> B.
>>>
>>> On 6 July 2011 14:05, Benoit Chesneau <bc...@gmail.com> wrote:
>>>> On Wed, Jul 6, 2011 at 2:43 PM, Robert Newson <rn...@apache.org> wrote:
>>>>> All,
>>>>>
>>>>> Our current password hashing scheme is weak. In fact, it's regarded as
>>>>> weak as plaintext. I'd like to change that.
>>>>>
>>>>> Some time ago I wrote some code to implement the PBKDF2 protocol. This
>>>>> is a cryptographically sound means of deriving a key from a password.
>>>>> The output is also usable as a password hash. An important part of the
>>>>> protocol is that the work factor can be increased by increasing the
>>>>> loop count. Additionally, it is not tied to a specific digest
>>>>> algorithm. All these points are not true of the sometimes proposed
>>>>> alternative called 'bcrypt' which I do not recommend.
>>>>>
>>>>> I would like this to go into CouchDB 1.2. New passwords, and updated
>>>>> passwords, from 1.2 onwards would use the new scheme, but 1.2 will,
>>>>> obviously, be able to verify the current style. This work will take
>>>>> place within couch_server where hash_admin_passwords currently lives.
>>>>>
>>>>> The PKBDF2 code is here:
>>>>> https://github.com/rnewson/couchdb/tree/pbkdf2. It passes all the test
>>>>> vectors.
>>>>>
>>>>> The ticket for this work is https://issues.apache.org/jira/browse/COUCHDB-1060
>>>>>
>>>>> B.
>>>>>
>>>> That sounds good. I would prefer however a customizable hashing method
>>>> for passwords so we can change it easily depending the target. Some
>>>> administrations for example require that you use some methods (like
>>>> sha256 in europe) and it would be very useful.
>>>>
>>>> - benoît
>>>>
>>>
>>
>>
>>
>> --
>> Filipe David Manana,
>> fdmanana@gmail.com, fdmanana@apache.org
>>
>> "Reasonable men adapt themselves to the world.
>> Unreasonable men adapt the world to themselves.
>> That's why all progress depends on unreasonable men."
>>
>
--
Filipe David Manana,
fdmanana@gmail.com, fdmanana@apache.org
"Reasonable men adapt themselves to the world.
Unreasonable men adapt the world to themselves.
That's why all progress depends on unreasonable men."
Re: Improving password hashing.
Posted by Robert Newson <rn...@apache.org>.
Patch will be tidied to community standards before submission.
The upgrade code is not yet written but should be straightforward.
B.
On 6 July 2011 14:50, Filipe David Manana <fd...@apache.org> wrote:
> Looks good to me as well.
>
> Minor nitpick, ideally it would respect our coding standard of not
> having lines longer than 80 characters.
>
> Good work Robert
>
> On Wed, Jul 6, 2011 at 2:10 PM, Robert Newson <rn...@apache.org> wrote:
>> Making it pluggable is probably not much more work but I have to point
>> at that "use sha256" is an inadequate description of a secure password
>> hashing protocol.
>>
>> B.
>>
>> On 6 July 2011 14:05, Benoit Chesneau <bc...@gmail.com> wrote:
>>> On Wed, Jul 6, 2011 at 2:43 PM, Robert Newson <rn...@apache.org> wrote:
>>>> All,
>>>>
>>>> Our current password hashing scheme is weak. In fact, it's regarded as
>>>> weak as plaintext. I'd like to change that.
>>>>
>>>> Some time ago I wrote some code to implement the PBKDF2 protocol. This
>>>> is a cryptographically sound means of deriving a key from a password.
>>>> The output is also usable as a password hash. An important part of the
>>>> protocol is that the work factor can be increased by increasing the
>>>> loop count. Additionally, it is not tied to a specific digest
>>>> algorithm. All these points are not true of the sometimes proposed
>>>> alternative called 'bcrypt' which I do not recommend.
>>>>
>>>> I would like this to go into CouchDB 1.2. New passwords, and updated
>>>> passwords, from 1.2 onwards would use the new scheme, but 1.2 will,
>>>> obviously, be able to verify the current style. This work will take
>>>> place within couch_server where hash_admin_passwords currently lives.
>>>>
>>>> The PKBDF2 code is here:
>>>> https://github.com/rnewson/couchdb/tree/pbkdf2. It passes all the test
>>>> vectors.
>>>>
>>>> The ticket for this work is https://issues.apache.org/jira/browse/COUCHDB-1060
>>>>
>>>> B.
>>>>
>>> That sounds good. I would prefer however a customizable hashing method
>>> for passwords so we can change it easily depending the target. Some
>>> administrations for example require that you use some methods (like
>>> sha256 in europe) and it would be very useful.
>>>
>>> - benoît
>>>
>>
>
>
>
> --
> Filipe David Manana,
> fdmanana@gmail.com, fdmanana@apache.org
>
> "Reasonable men adapt themselves to the world.
> Unreasonable men adapt the world to themselves.
> That's why all progress depends on unreasonable men."
>
Re: Improving password hashing.
Posted by Filipe David Manana <fd...@apache.org>.
Looks good to me as well.
Minor nitpick, ideally it would respect our coding standard of not
having lines longer than 80 characters.
Good work Robert
On Wed, Jul 6, 2011 at 2:10 PM, Robert Newson <rn...@apache.org> wrote:
> Making it pluggable is probably not much more work but I have to point
> at that "use sha256" is an inadequate description of a secure password
> hashing protocol.
>
> B.
>
> On 6 July 2011 14:05, Benoit Chesneau <bc...@gmail.com> wrote:
>> On Wed, Jul 6, 2011 at 2:43 PM, Robert Newson <rn...@apache.org> wrote:
>>> All,
>>>
>>> Our current password hashing scheme is weak. In fact, it's regarded as
>>> weak as plaintext. I'd like to change that.
>>>
>>> Some time ago I wrote some code to implement the PBKDF2 protocol. This
>>> is a cryptographically sound means of deriving a key from a password.
>>> The output is also usable as a password hash. An important part of the
>>> protocol is that the work factor can be increased by increasing the
>>> loop count. Additionally, it is not tied to a specific digest
>>> algorithm. All these points are not true of the sometimes proposed
>>> alternative called 'bcrypt' which I do not recommend.
>>>
>>> I would like this to go into CouchDB 1.2. New passwords, and updated
>>> passwords, from 1.2 onwards would use the new scheme, but 1.2 will,
>>> obviously, be able to verify the current style. This work will take
>>> place within couch_server where hash_admin_passwords currently lives.
>>>
>>> The PKBDF2 code is here:
>>> https://github.com/rnewson/couchdb/tree/pbkdf2. It passes all the test
>>> vectors.
>>>
>>> The ticket for this work is https://issues.apache.org/jira/browse/COUCHDB-1060
>>>
>>> B.
>>>
>> That sounds good. I would prefer however a customizable hashing method
>> for passwords so we can change it easily depending the target. Some
>> administrations for example require that you use some methods (like
>> sha256 in europe) and it would be very useful.
>>
>> - benoît
>>
>
--
Filipe David Manana,
fdmanana@gmail.com, fdmanana@apache.org
"Reasonable men adapt themselves to the world.
Unreasonable men adapt the world to themselves.
That's why all progress depends on unreasonable men."
Re: Improving password hashing.
Posted by Robert Newson <rn...@apache.org>.
Ah, ok. It's not yet available, but switching sha1->sha256 is no big deal.
B.
On 6 July 2011 16:18, Benoit Chesneau <bc...@gmail.com> wrote:
> On Wed, Jul 6, 2011 at 3:10 PM, Robert Newson <rn...@apache.org> wrote:
>> at that "use sha256" is an inadequate description of a secure password
>> hashing protocol.
>>
> I wasn't speaking about protocol but hashing method.
>
> - benoît
>
Re: Improving password hashing.
Posted by Benoit Chesneau <bc...@gmail.com>.
On Wed, Jul 6, 2011 at 3:10 PM, Robert Newson <rn...@apache.org> wrote:
> at that "use sha256" is an inadequate description of a secure password
> hashing protocol.
>
I wasn't speaking about protocol but hashing method.
- benoît
Re: Improving password hashing.
Posted by Robert Newson <rn...@apache.org>.
Making it pluggable is probably not much more work but I have to point
at that "use sha256" is an inadequate description of a secure password
hashing protocol.
B.
On 6 July 2011 14:05, Benoit Chesneau <bc...@gmail.com> wrote:
> On Wed, Jul 6, 2011 at 2:43 PM, Robert Newson <rn...@apache.org> wrote:
>> All,
>>
>> Our current password hashing scheme is weak. In fact, it's regarded as
>> weak as plaintext. I'd like to change that.
>>
>> Some time ago I wrote some code to implement the PBKDF2 protocol. This
>> is a cryptographically sound means of deriving a key from a password.
>> The output is also usable as a password hash. An important part of the
>> protocol is that the work factor can be increased by increasing the
>> loop count. Additionally, it is not tied to a specific digest
>> algorithm. All these points are not true of the sometimes proposed
>> alternative called 'bcrypt' which I do not recommend.
>>
>> I would like this to go into CouchDB 1.2. New passwords, and updated
>> passwords, from 1.2 onwards would use the new scheme, but 1.2 will,
>> obviously, be able to verify the current style. This work will take
>> place within couch_server where hash_admin_passwords currently lives.
>>
>> The PKBDF2 code is here:
>> https://github.com/rnewson/couchdb/tree/pbkdf2. It passes all the test
>> vectors.
>>
>> The ticket for this work is https://issues.apache.org/jira/browse/COUCHDB-1060
>>
>> B.
>>
> That sounds good. I would prefer however a customizable hashing method
> for passwords so we can change it easily depending the target. Some
> administrations for example require that you use some methods (like
> sha256 in europe) and it would be very useful.
>
> - benoît
>
Re: Improving password hashing.
Posted by Benoit Chesneau <bc...@gmail.com>.
On Wed, Jul 6, 2011 at 2:43 PM, Robert Newson <rn...@apache.org> wrote:
> All,
>
> Our current password hashing scheme is weak. In fact, it's regarded as
> weak as plaintext. I'd like to change that.
>
> Some time ago I wrote some code to implement the PBKDF2 protocol. This
> is a cryptographically sound means of deriving a key from a password.
> The output is also usable as a password hash. An important part of the
> protocol is that the work factor can be increased by increasing the
> loop count. Additionally, it is not tied to a specific digest
> algorithm. All these points are not true of the sometimes proposed
> alternative called 'bcrypt' which I do not recommend.
>
> I would like this to go into CouchDB 1.2. New passwords, and updated
> passwords, from 1.2 onwards would use the new scheme, but 1.2 will,
> obviously, be able to verify the current style. This work will take
> place within couch_server where hash_admin_passwords currently lives.
>
> The PKBDF2 code is here:
> https://github.com/rnewson/couchdb/tree/pbkdf2. It passes all the test
> vectors.
>
> The ticket for this work is https://issues.apache.org/jira/browse/COUCHDB-1060
>
> B.
>
That sounds good. I would prefer however a customizable hashing method
for passwords so we can change it easily depending the target. Some
administrations for example require that you use some methods (like
sha256 in europe) and it would be very useful.
- benoît
Re: Improving password hashing.
Posted by Robert Newson <rn...@apache.org>.
To benoitc's point, we could switch sha256 in for sha1 as soon as it's
available in an OTP release.
B.
On 6 July 2011 15:50, Robert Newson <rn...@apache.org> wrote:
> Because PBKDF2 has been designed and tested by cryptographers and is
> fully described in RFC 2898 which includes test vectors to verify an
> implementation. bcrypt is tied to a now obsolete cipher (blowfish), I
> don't know anything much about scrypt but anyone can claim they
> designed it to be more secure, but proving it is another matter.
>
> B.
>
> On 6 July 2011 15:43, Dirkjan Ochtman <di...@ochtman.nl> wrote:
>> On Wed, Jul 6, 2011 at 14:43, Robert Newson <rn...@apache.org> wrote:
>>> Some time ago I wrote some code to implement the PBKDF2 protocol. This
>>> is a cryptographically sound means of deriving a key from a password.
>>
>> Why is this better than stuff like bcrypt or scrypt? The page for the
>> latter, at least, states that it "is designed to be far more secure
>> against hardware brute-force attacks than alternative functions such
>> as PBKDF2".
>>
>> Cheers,
>>
>> Dirkjan
>>
>
Re: Improving password hashing.
Posted by Robert Newson <rn...@apache.org>.
Because PBKDF2 has been designed and tested by cryptographers and is
fully described in RFC 2898 which includes test vectors to verify an
implementation. bcrypt is tied to a now obsolete cipher (blowfish), I
don't know anything much about scrypt but anyone can claim they
designed it to be more secure, but proving it is another matter.
B.
On 6 July 2011 15:43, Dirkjan Ochtman <di...@ochtman.nl> wrote:
> On Wed, Jul 6, 2011 at 14:43, Robert Newson <rn...@apache.org> wrote:
>> Some time ago I wrote some code to implement the PBKDF2 protocol. This
>> is a cryptographically sound means of deriving a key from a password.
>
> Why is this better than stuff like bcrypt or scrypt? The page for the
> latter, at least, states that it "is designed to be far more secure
> against hardware brute-force attacks than alternative functions such
> as PBKDF2".
>
> Cheers,
>
> Dirkjan
>
Re: Improving password hashing.
Posted by Dirkjan Ochtman <di...@ochtman.nl>.
On Wed, Jul 6, 2011 at 14:43, Robert Newson <rn...@apache.org> wrote:
> Some time ago I wrote some code to implement the PBKDF2 protocol. This
> is a cryptographically sound means of deriving a key from a password.
Why is this better than stuff like bcrypt or scrypt? The page for the
latter, at least, states that it "is designed to be far more secure
against hardware brute-force attacks than alternative functions such
as PBKDF2".
Cheers,
Dirkjan