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 -
Replying to @widdr @ErrataRob
`(domain||username||password)` is fine if you don’t care about targeted attacks. As an alternative, a new `(pk, seed)` can be sent by the client after logging in. So that these are constantly changing. By the time a database gets leaked, it’s already obsolete and useless.
1 reply 0 retweets 0 likes -
https://github.com/jedisct1/fastly-terrarium-examples/tree/605500c2828e2dc0a7a0558db4f6da59094e08c7/access_control_example … That was the initial design and implementation of this protocol. But high-profile users that never log in remain vulnerable.
1 reply 0 retweets 0 likes -
Replying to @jedisct1 @ErrataRob
I always envisioned a plain extension of the usual method: store the pk as the password serverside, bcrypted as normal. Require that it be provided like a password. Generate sk/pk with a keystretcher clientside, plus require the client to sign a server-provided random nonce.
4 replies 0 retweets 0 likes -
Client keys can be upgraded with a conditional second roundtrip: perform login with the stronger stretcher params first, then if the username the server receives needs upgrading request the pk from the prior parameters to authenticate the upgrade (then replace with the stronger).
1 reply 0 retweets 0 likes
But any of these will be an improvement over sending passwords to severs anyway.
-
-
Replying to @jedisct1 @ErrataRob
very true. we're >20 years deep on this terrible idea; i'm surprised every consecutive hour goes by that nobody seems to be doing anything about solving this
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
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.