Facebook Password Hashing & Authentication
Why Information Security Stack Exchange recommends it
Security Stack Exchange answerers cite it as a first-hand account of Facebook's password storage, from why near-miss passwords still log you in to the scrypt parameters it uses.
Recommended by 1 people across 1 different months, 2019 to 2020.
What it is
A conference talk by Facebook engineer Alec Muffett on how Facebook hashes and checks user passwords. It covers the layered hashing pipeline, including scrypt, and how login handles small typing mistakes. The video is a recording of his presentation on Facebook's authentication design.
What people said
Recommends wexla · 2019-08 · Information Security Stack Exchange · on “Why can I log in to my Facebook account with a misspelled email/password?”
Facebook is allowing you to make a handful of mistakes to ease the login process. A Facebook engineer explained the process at a conference [this video] . The gist of it is that Facebook will try various permutations of the input you submitted and see if they match the hash they have in their database. For example, if your password is "myRealPassword!" but you submit "MYrEALpASSWORD!" (capslock on, shift inverting capslock). The submitted password obviously doesn't match what they have stored in their database. Rather than reject you flat out, Facebook tries to up the user experience by trying to "correct" a few common mistakes such as inserting a random character before or after, capitalizing (o
Cites Royce Williams · 2020-07 · Information Security Stack Exchange · on “Is bcrypt(strtolower(hex(md5(pass)))) ok for storing passwords?”
As a password cracker, I encourage all of my targets to use this technique. This (understandably!) seems like a good idea, but it turns out that against real-world attacks, wrapping an unsalted hash with bcrypt is demonstrably weaker than simply using bcrypt . (EDIT: First, to be clear up front, bcrypt(md5($pass)) is much better than md5($pass) alone - so none of this should be take to mean that this scheme should be left as is.) Wrapping an unsalted hash is problematic from a real-world attack perspective because attackers can do this: Acquire existing MD5 passwords from leaks - even MD5s that haven't been cracked yet After simpler attacks have been exhausted, run these MD5s as a "wordlist"
Cites Royce Williams · 2020-07 · Information Security Stack Exchange · on “Why isn't it more popular to increase the p (parallelization) parameter of scrypt?”
There are two reasons I can think of: First, because it weakens the main use case . An explicit design goal of scrypt is to make parallelization hardware expensive - and by "hardware" here, we do not mean merely GPU, but also FPGAs and, ultimately, custom ASICs. Building fast-access RAM close to the processor cores necessary to do the calculation is what drives the cost up. If the workload can be subdivided, it's more likely that it can be parallelized by an attacker, which reduces the cost of the hardware necessary to attack scrypt at scale. For more background on this, see Percival's slides from his talk announcing scrypt [LINK] , in which the hardware cost trade-off is explicitly discusse
Cites sox supports the mods · 2020-12 · Information Security Stack Exchange · on “Does Facebook store plain-text passwords?”
"Run the result through the scrypt KDF (using undisclosed tuning parameters)" this was answered in a follow-up question at the conference, [this video] at min 18:15. The parameters are `(2^14, 8, 1)`