It's important to note in this "Facebook plain-text password" story that the passwords are being stored with salted scrypt hashes, that's not the issue. Instead, the issue is inadvertent logging of web requests -- which happen to contain clear-text passwords.
-
Show this thread
-
Replying to @ErrataRob
Servers should not see cleartext passwords ever. This is a ticking bomb. https://00f.net/2018/10/18/on-user-authentication/ … https://github.com/jedisct1/fastly-terrarium-examples/tree/master/access_control_example …
2 replies 6 retweets 43 likes -
Replying to @jedisct1 @ErrataRob
After reading over this (and the docs correction I posted, thanks for the quick fix), I'm curious: What's the driving motivation behind adding the complexity and extra round trip of OPRF salt construction just to involve the server in the construction of the client's secret key?
2 replies 0 retweets 1 like -
I'm not sure I can see what attacks would be viable against a model where we skip this step and simply construct our secret key from a key-stretched (domain || username || password) that are mitigated by the addition of this step.
2 replies 0 retweets 0 likes
(domain||username||password) will not prevent targeted attacks against high profile users. The salt will. But if the server knows the salt, brute force attacks are still possible for people having access to it. The 2 party computation prevents this.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.