4 ms·

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.

Karunamon 11y ago
I know Keybase (http://keybase.io http://keybase.io) uses scrypt, but that's the only one I know of off the top of my head.
- malgorithms 11y ago
  Details, in case it's helpful/interesting to anyone: https://keybase.io/docs/api/1.0/call/login https://keybase.io/docs/api/1.0/call/login . Also of note, the hashing is done client side, not server-side.
  - hinkley 11y ago
    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?
    - darkr 11y ago
      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.
      - nitrogen 11y ago
        It seems like it would be better to just use SRP (https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol 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.
    - EvanDotPro 11y ago
      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?
    - cpeterso 11y ago
      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.
      - sarciszewski 11y ago
        Yo dawg, I heard you liked hashes... Meme reference aside, this is actually a sane way to do things.
sarciszewski 11y ago
Yes. https://paragonie.com/book/pecl-libsodium/read/09-recipes.md#encrypted-password-hashes https://paragonie.com/book/pecl-libsodium/read/09-recipes.md... This is the scheme that I'm using for one of my projects. :)
pwman 11y ago
Yes, but it's after 100,000 rounds of PBKDF2.
- epistasis 11y ago
  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?
  - timmclean 11y ago
    Mainly because it adds complexity, and complexity in crypto can hide subtle bugs. Example: http://blog.ircmaxell.com/2015/03/security-issue-combining-bcrypt-with.html http://blog.ircmaxell.com/2015/03/security-issue-combining-b...
  - ejcx 11y ago
    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.
DiThi 11y ago
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.

Karunamon 11y ago

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

malgorithms 11y ago
Details, in case it's helpful/interesting to anyone: https://keybase.io/docs/api/1.0/call/login https://keybase.io/docs/api/1.0/call/login . Also of note, the hashing is done client side, not server-side.
- hinkley 11y ago
  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?
  - darkr 11y ago
    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.
    - nitrogen 11y ago
      It seems like it would be better to just use SRP (https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol 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.
  - EvanDotPro 11y ago
    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?
  - cpeterso 11y ago
    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.
    - sarciszewski 11y ago
      Yo dawg, I heard you liked hashes... Meme reference aside, this is actually a sane way to do things.

sarciszewski 11y ago

Yes. https://paragonie.com/book/pecl-libsodium/read/09-recipes.md#encrypted-password-hashes https://paragonie.com/book/pecl-libsodium/read/09-recipes.md... This is the scheme that I'm using for one of my projects. :)

pwman 11y ago

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

epistasis 11y ago
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?
- timmclean 11y ago
  Mainly because it adds complexity, and complexity in crypto can hide subtle bugs. Example: http://blog.ircmaxell.com/2015/03/security-issue-combining-bcrypt-with.html http://blog.ircmaxell.com/2015/03/security-issue-combining-b...
- ejcx 11y ago
  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.

DiThi 11y ago

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.