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.
-
-
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?
-
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.
- 4 more replies
New conversation -
-
-
Yes. The problem is not that logging inadvertently captures passwords, but that it is even possible to capture passwords. Even if all the logging is fixed, you never can be sure that adversary hasn’t penetrated your network and is evesdropping on your messages.
-
The adversary can be an insider. Or a SaaS used for log storage
- 3 more replies
New conversation -
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.