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.
`(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.
-
-
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.
-
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.
- 1 more reply
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.