6 ms·

It's a good system, especially compared with the current best practice of simply hashing passwords with bcrypt and calling it a day. I can't recall it off the

by dsacco 10y ago

It's a good system, especially compared with the current best practice of simply hashing passwords with bcrypt and calling it a day. I can't recall it off the top of my head, but Facebook has a similarly impressive system with more secret sauce involved for performance at scale. I believe what they do is the following: 1. Hash the password with MD5(password). 2. Generate a 20-byte (160-bit) random salt (this is well over the 64 bits you'd need to defend against birthday attack collisions). 3. Hash with hmac_sha1(hash, salt). 4. Send this value to a separate server for further operations (mitigates offline brute-forcing). 5. Hash in a secret key with hmac_256(hash, secret). Note this operation is on a separate server. The secret key might be colloquially termed a "pepper". 6. Hash with scrypt(hash, salt) to make local computation slower. 7. Shrink the final value with hmac_256(hash, salt) for efficient database storage. If any Facebook engineers are around, please correct me if I've missed or misinterpreted any part of that.

amenghra 10y ago
It's a chain of hash because that's how passwords were migrated from being stored unsalted, to salted, to scrypted. People sometimes complain that migrating passwords is a pain, but if you wrap the older scheme with a newer hash* it kind of works out. Today, I would consider argon2 which came out of PHC. * you need to carefully study the security properties of the combined hash.
- dsacco 10y ago
  >> It's a chain of hash because that's how passwords were migrated from being stored unsalted, to salted, to scrypted. I kind of figured that, thanks for confirming :). Personally I wouldn't consider Argon2 yet for production, but only because I'd like to see it run at scale for a few years. PHC or not, I'm hoping it becomes more battle-tested in production use. That said, I'd fully respect any team for using Argon2 and have no personal qualms with it.
  - user5994461 10y ago
    Argon2i and argon2d => bad idea to use that in production (and yes, the researchers made two different algorithms with the same name)
red_admiral 10y ago
http://chunk.io/f/72f9c680ac2a4777b6dbf33c532e1d3c.jpg http://chunk.io/f/72f9c680ac2a4777b6dbf33c532e1d3c.jpg (I don't work there myself but I went to the talk.)
- dsacco 10y ago
  Thank you! This is exactly what I was referring to. There's a slideshare of this talk too. I couldn't find when I first wrote that comment, but I bet I'll find it with "onion" as a keyword.
  - alecmuffett 10y ago
    https://video.adm.ntnu.no/pres/54b660049af94 https://video.adm.ntnu.no/pres/54b660049af94
    - dsacco 10y ago
      Thanks!
- deleted 10y ago
  [deleted]
jszymborski 10y ago
Hold the phone. Using MD5 upfront opens you up to a significantly increased collision probability. That has to degrade the security here.
- Sammi 10y ago
  It's probably because of migration, as amenghra explains.
  - alecmuffett 10y ago
    Correct.
- tedunangst 10y ago
  Not in a way that matters.
tptacek 10y ago
The current best practice of simply hashing passwords with bcrypt is fine, and anything past that which doesn't doesn't involve (probably per-password) use of an HSM adds only marginal value. I wouldn't want anyone to read this and get the impression that "secret peppers" and multiple hashing rounds and HMAC were important components of a password storage system. They are not: they're things that message board nerds come up with. If you want to be a step better than just storing passwords with bcrypt, your next step is to create an authentication service that runs on separate hardware with an "is this password valid" and "enroll this password" API and nothing else. The stuff people do instead of this is basically cosmetic.
- dsacco 10y ago
  >>The current best practice of simply hashing passwords with bcrypt is fine, and anything past that which doesn't doesn't involve (probably per-password) use of an HSM adds only marginal value. Yep, I mostly agree. As I said elsewhere in the thread, I wouldn't really recommend this sequence to any company unless it were very large and had a mature ops team to handle it. There's a lot of diminishing returns here. Good clarification.
- Dylan16807 10y ago
  > The current best practice of simply hashing passwords with bcrypt is fine With the caveat that you have to make sure you're hashing the entire password. Don't silently truncate.
  - deleted 10y ago
    [deleted]
- alecmuffett 10y ago
  Yep, Tom, that's the FB solution - or rather, halfway up the stack of hashing is a callout to a service where HMACs are involved. These bring their own challenges: https://video.adm.ntnu.no/pres/54b660049af94 https://video.adm.ntnu.no/pres/54b660049af94
  - 10y ago
ValentineC 10y ago
Here's a video of the Facebook talk, if anyone's interested: http://video.adm.ntnu.no/pres/54b660049af94 http://video.adm.ntnu.no/pres/54b660049af94
swordswinger12 10y ago
If this jury-rigged, duct-taped "password hashing" scheme impresses you, I've got some land in Florida you might be interested in. Seriously, though, it's a complete fallacy to think that more complicated password hashing schemes with lots of fancy steps are better. I was at the talk where this scheme was presented, and Alec Muffett himself said the only reason it was so complicated is because they had to layer stronger hashes on top of existing ones instead of revoking all outstanding session cookies (forcing every Facebook user in the world to re-authenticate).
- dsacco 10y ago
  I'm aware of all that, and I'm not impressed by the numerous hashing steps. I'm impressed by Facebook's commitment to migrating and future-proofing their security practices as they become obsolete. Specifically, this means "wrapping" insecure hashes in more secure hashes and the addition of an encryption key stored in an HSM on a separate server.
alecmuffett 10y ago
Hi! I'm Alec, I presented that Facebook password hashing paper at PasswordCon'15 and the video is here, slides included: https://video.adm.ntnu.no/pres/54b660049af94 https://video.adm.ntnu.no/pres/54b660049af94
- deleted 10y ago
  [deleted]

by dsacco 10y ago

amenghra 10y ago

It's a chain of hash because that's how passwords were migrated from being stored unsalted, to salted, to scrypted. People sometimes complain that migrating passwords is a pain, but if you wrap the older scheme with a newer hash* it kind of works out. Today, I would consider argon2 which came out of PHC. * you need to carefully study the security properties of the combined hash.

dsacco 10y ago
>> It's a chain of hash because that's how passwords were migrated from being stored unsalted, to salted, to scrypted. I kind of figured that, thanks for confirming :). Personally I wouldn't consider Argon2 yet for production, but only because I'd like to see it run at scale for a few years. PHC or not, I'm hoping it becomes more battle-tested in production use. That said, I'd fully respect any team for using Argon2 and have no personal qualms with it.
- user5994461 10y ago
  Argon2i and argon2d => bad idea to use that in production (and yes, the researchers made two different algorithms with the same name)

red_admiral 10y ago

http://chunk.io/f/72f9c680ac2a4777b6dbf33c532e1d3c.jpg http://chunk.io/f/72f9c680ac2a4777b6dbf33c532e1d3c.jpg (I don't work there myself but I went to the talk.)

dsacco 10y ago
Thank you! This is exactly what I was referring to. There's a slideshare of this talk too. I couldn't find when I first wrote that comment, but I bet I'll find it with "onion" as a keyword.
- alecmuffett 10y ago
  https://video.adm.ntnu.no/pres/54b660049af94 https://video.adm.ntnu.no/pres/54b660049af94
  - dsacco 10y ago
    Thanks!
deleted 10y ago
[deleted]

jszymborski 10y ago

Hold the phone. Using MD5 upfront opens you up to a significantly increased collision probability. That has to degrade the security here.

Sammi 10y ago
It's probably because of migration, as amenghra explains.
- alecmuffett 10y ago
  Correct.
tedunangst 10y ago
Not in a way that matters.

tptacek 10y ago

The current best practice of simply hashing passwords with bcrypt is fine, and anything past that which doesn't doesn't involve (probably per-password) use of an HSM adds only marginal value. I wouldn't want anyone to read this and get the impression that "secret peppers" and multiple hashing rounds and HMAC were important components of a password storage system. They are not: they're things that message board nerds come up with. If you want to be a step better than just storing passwords with bcrypt, your next step is to create an authentication service that runs on separate hardware with an "is this password valid" and "enroll this password" API and nothing else. The stuff people do instead of this is basically cosmetic.

dsacco 10y ago
>>The current best practice of simply hashing passwords with bcrypt is fine, and anything past that which doesn't doesn't involve (probably per-password) use of an HSM adds only marginal value. Yep, I mostly agree. As I said elsewhere in the thread, I wouldn't really recommend this sequence to any company unless it were very large and had a mature ops team to handle it. There's a lot of diminishing returns here. Good clarification.
Dylan16807 10y ago
> The current best practice of simply hashing passwords with bcrypt is fine With the caveat that you have to make sure you're hashing the entire password. Don't silently truncate.
- deleted 10y ago
  [deleted]
alecmuffett 10y ago
Yep, Tom, that's the FB solution - or rather, halfway up the stack of hashing is a callout to a service where HMACs are involved. These bring their own challenges: https://video.adm.ntnu.no/pres/54b660049af94 https://video.adm.ntnu.no/pres/54b660049af94
- 10y ago

ValentineC 10y ago

Here's a video of the Facebook talk, if anyone's interested: http://video.adm.ntnu.no/pres/54b660049af94 http://video.adm.ntnu.no/pres/54b660049af94

swordswinger12 10y ago

If this jury-rigged, duct-taped "password hashing" scheme impresses you, I've got some land in Florida you might be interested in. Seriously, though, it's a complete fallacy to think that more complicated password hashing schemes with lots of fancy steps are better. I was at the talk where this scheme was presented, and Alec Muffett himself said the only reason it was so complicated is because they had to layer stronger hashes on top of existing ones instead of revoking all outstanding session cookies (forcing every Facebook user in the world to re-authenticate).

dsacco 10y ago
I'm aware of all that, and I'm not impressed by the numerous hashing steps. I'm impressed by Facebook's commitment to migrating and future-proofing their security practices as they become obsolete. Specifically, this means "wrapping" insecure hashes in more secure hashes and the addition of an encryption key stored in an HSM on a separate server.

alecmuffett 10y ago

Hi! I'm Alec, I presented that Facebook password hashing paper at PasswordCon'15 and the video is here, slides included: https://video.adm.ntnu.no/pres/54b660049af94 https://video.adm.ntnu.no/pres/54b660049af94

deleted 10y ago
[deleted]