Hacker News Reader

Comment by davidrusu | Hacker News Reader

Is anyone here using Scrypt in production?

I had do decide on a hashing scheme recently and ended up going with Bcrypt just because of how new Scrypt is.

I know Keybase (http://keybase.io) uses scrypt, but that's the only one I know of off the top of my head.

Details, in case it's helpful/interesting to anyone: https://keybase.io/docs/api/1.0/call/login . Also of note, the hashing is done client side, not server-side.

Doesn't that mean the hash is the password, not the password? If I steal the password file what keeps me from just logging in as everybody?

Can't vouch that this is the case with keybase, but where I've seen this done before, the hash is calculated in combination with some kind of time-based shared secret at both at the server and the client and then compared, with the theory being it would protect against the TLS connection is MITM'd; all the attacker would get is the hash, which is then useless as the time element isn't known.

IMHO, MITM would be better defended against using HSTS, certificate pinning, and perhaps DNSSEC.

It seems like it would be better to just use SRP (https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...). SRP defends against replay attacks, and could potentially use a modified bcrypt or scrypt for H() to limit brute force attempts.

Technically yes, but I would imagine they'd subsequently hash the hash on the server side as well.

I assume the extra client-side hashing is done to keep the plaintext passwords out of the application memory, not protect it in transit.

To clarify, this is just an assumption. I have not read up on the topic nor do I claim to be a security expert. This is just what came to mind when I had the same thought as you.

Anyone else know for sure?

The client's hash is the password but the password file contains salted hashes of the client's hash. An attacker that has the client's password hash can replay it, but they don't know the user's password. An attacker with the password file doesn't know any clients' password hashes or whether any of the password hashes are reused by different users.

Yo dawg, I heard you liked hashes...

Meme reference aside, this is actually a sane way to do things.

Yes.

https://paragonie.com/book/pecl-libsodium/read/09-recipes.md...

This is the scheme that I'm using for one of my projects. :)

As someone else mentioned, Litecoin. Not in passwords but in "mining" (proof of work). It resisted GPU for a while until it didn't. Although the difference between CPU and GPU was not big (much smaller than with SHA256). The work factor was too small and it couldn't be changed easily. After 4 years, though, nobody "cracked" it.

The work factor of a password database can be changed easily, either by re-hashing every time someone with the old scheme logs in, or by hashing all the hashes more.

Yes, but it's after 100,000 rounds of PBKDF2.

Chaining hashes seems like a great way to get the benefits of both, and to have an extra layer in case one falls. Why isn't that done more commonly in practice?

Mainly because it adds complexity, and complexity in crypto can hide subtle bugs. Example: http://blog.ircmaxell.com/2015/03/security-issue-combining-b...

I've actually seen it cause numerous issues. For example, consider this pseudocode:

    // Returns binary data
    shaPass = crypto.sha256(userPassword)
    // returns an scrypt password
    crypto.bcrypt(shaPass)

I've seen many people pass binary data into functions that will terminate reading the string at a null byte. This obviously limits the strength of the number of bytes before a null byte is hit in the binary data (mostly only concerns PHP and C).

Just noticed someone else posted the ircmaxwell blog, which is the best writing on this topic.

Reply on news.ycombinator.com