Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of fdmanana@gmail.com designates
 209.85.210.52 as permitted sender)
MIME-Version: 1.0
Sender: fdmanana@gmail.com
In-Reply-To: 
 <CABvT1DHMatLeR95sY019SqXmagokF+wKdVX26ebO4yUHj2PDJw@mail.gmail.com>
References: 
 <CABvT1DFkZHWMZ15DCVQiedy9+GdgCtXhMtY-8qfPq35bmeHOsw@mail.gmail.com>
	<CAJNb-9qviqvOFNZju59ixaM+8Qf=7hqUPsFHr7unh+sqi=GZ4g@mail.gmail.com>
	<CABvT1DERcrCFVkzZBSQYFruTnqEEEu0JUU3gQ2pMdPGTYawT8Q@mail.gmail.com>
	<CAL3q7H5FEYJe0gugkvAYQ7GOduYCYqbNWH37jxwTQ-ry=70b3w@mail.gmail.com>
	<CABvT1DHMatLeR95sY019SqXmagokF+wKdVX26ebO4yUHj2PDJw@mail.gmail.com>
Date: Wed, 6 Jul 2011 15:26:35 +0100
Message-ID: 
 <CAL3q7H6JqzEDknHt3cuDuC0oc_2RPjEx7g=iKBjxWGsBScRo+w@mail.gmail.com>
Subject: Re: Improving password hashing.
From: Filipe David Manana <fdmanana@apache.org>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 =3D crypto:sha_mac("=C3=A0bc", <<"123">>).
<<149,17,150,46,220,128,255,66,209,115,186,23,167,63,117,
  165,113,82,100,234>>
2>
2> H2 =3D crypto:sha_mac(unicode:characters_to_binary("=C3=A0bc"), <<"123">=
>).
<<30,96,182,160,202,26,142,36,32,79,28,250,228,105,79,11,
  73,48,52,197>>
3>
3> H1 =3D:=3D 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> wro=
te:
>>>>> All,
>>>>>
>>>>> Our current password hashing scheme is weak. In fact, it's regarded a=
s
>>>>> weak as plaintext. I'd like to change that.
>>>>>
>>>>> Some time ago I wrote some code to implement the PBKDF2 protocol. Thi=
s
>>>>> 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 th=
e
>>>>> 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 tes=
t
>>>>> vectors.
>>>>>
>>>>> The ticket for this work is https://issues.apache.org/jira/browse/COU=
CHDB-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=C3=AEt
>>>>
>>>
>>
>>
>>
>> --
>> Filipe David Manana,
>> fdmanana@gmail.com, fdmanana@apache.org
>>
>> "Reasonable men adapt themselves to the world.
>> =C2=A0Unreasonable men adapt the world to themselves.
>> =C2=A0That's why all progress depends on unreasonable men."
>>
>


--=20
Filipe David Manana,
fdmanana@gmail.com, fdmanana@apache.org

"Reasonable men adapt themselves to the world.
=C2=A0Unreasonable men adapt the world to themselves.
=C2=A0That's why all progress depends on unreasonable men."