incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Terry Smith <terryzsm...@gmail.com>
Subject Re: Improving password hashing.
Date Wed, 06 Jul 2011 13:49:50 GMT
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 <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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message