couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: Improving password hashing.
Date Wed, 06 Jul 2011 14:43:39 GMT
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 <fdmanana@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 <rnewson@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 <fdmanana@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 <rnewson@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 <bchesneau@gmail.com> wrote:
>>>>> On Wed, Jul 6, 2011 at 2:43 PM, Robert Newson <rnewson@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."
>

Mime
View raw message