Thanks Colin. I did note that I knew little about scrypt, I appreciate
the details.
Agree about sha-1, of course, the main reason the code doesn't use
sha-256 is that it's not currently available in the Erlang OTP
platform. Even when it is, it will be a while before we can move the
lower bound of
[Replying via the list archives; sorry for breaking In-Reply-To: threading.
Please CC me on replies.]
Robert Newson wrote:
Because PBKDF2 has been designed and tested by cryptographers
I'm a cryptographer, and I designed and tested scrypt.
and is fully described in RFC 2898
I fully described
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
On Wed, Jul 6, 2011 at 2:43 PM, Robert Newson rnew...@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
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 bchesn...@gmail.com wrote:
On Wed, Jul 6, 2011 at 2:43 PM, Robert Newson rnew...@apache.org
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
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 rnew...@apache.org wrote:
Making it pluggable is probably not much more work but I have to point
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 fdman...@apache.org wrote:
Looks good to me as well.
Minor nitpick, ideally it would respect our coding standard of
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
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 ++
On Wed, Jul 6, 2011 at 14:43, Robert Newson rnew...@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
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
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 rnew...@apache.org wrote:
Because PBKDF2 has been designed and tested by cryptographers and is
fully described in RFC 2898 which includes test vectors to
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
On Wed, Jul 6, 2011 at 3:10 PM, Robert Newson rnew...@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
Ah, ok. It's not yet available, but switching sha1-sha256 is no big deal.
B.
On 6 July 2011 16:18, Benoit Chesneau bchesn...@gmail.com wrote:
On Wed, Jul 6, 2011 at 3:10 PM, Robert Newson rnew...@apache.org wrote:
at that use sha256 is an inadequate description of a secure password
hashing
16 matches
Mail list logo
