On 09/17/2015 03:58 PM, Edward Ned Harvey (blu) wrote: > The present standard practice is for clients/users to establish an HTTPS > connection and > then send username and password over the wire, where the server will encrypt > it using a > rate-limiting function such as pbkdf2, bcrypt, or scrypt, to protect it > against hackers > or bad employees who have access to the password file or database or > whatever. But wait! > We should assume, that hackers and bad employees who can access the password > file can > also access the encryption programs (drupal, wordpress, apache, etc that run > bcrypt etc) > and have access to the password in-memory before it's encrypted. > > Worse yet, even if the server is never breached and the employees are always > perfect, > users sacrifice their legal right to privacy by merely making it possible for > the > employees to see it. https://en.wikipedia.org/wiki/Third-party_doctrine
This is such a bizarre interpretation of "Third-party". A password should be considered a secret between two parties: client and server. But again, conceded that this is a problem. > This is like a > person writing their password on a postcard and assuming the mail carriers > will never > bother to look at it. Why do we make a distinction between the employees > operating the > routers on the internet, and the employees operating the web servers at > google and > facebook and everywhere else? We know we should never login to an http:// > site because > the random unknown employees who operate internet routers could see the > credentials in >-flight. We've all been trained to only login on valid https:// sites, even >though > potentially thousands of random unknown employees might be at work on the > other end, > able to see the credentials in-flight. > > tl;dr > There is no good reason to do the encryption on the server. It should be ok > to reuse > passwords on different sites, as long as the passwords are never exposed to > the servers. > > I work at Concept Blossom, and we're promoting awareness about this issue. We > produce > https://cbcrypt.org MIT open-source crypto library to address this issue. > We're > resource constrained on development, so development is taking place, but > slower than > we wish. Please spread the word and raise awareness as you wish. Even if some > other > implementation eventually becomes dominant instead of CBCrypt, this is a big > important > issue that I don't want affecting my daughter when she grows up. I've skimmed the docs. My understanding is that you're implementing per-site, unsigned client certificates that can be deterministically derived so that a certificate store isn't needed. And the protocol would basically be: - Open SSL session - Share public key - Challenge/response - Server looks up user data associated with public key A few thoughts: 1) The advantage to deterministically deriving keys is that I can go to somebody else's computer and login. The disadvantage is that now I'm giving access to my key material to any corrupted terminal. Keyloggers would be catastrophic since you're reusing passwords and don't need some kind of additional secret data. 2) You'll need browser buy-in to make the exchange happen at all on normal websites. Doing this in javascript is feasible (see clipperz.is) but doesn't resolve any trust issues at all. (For APIs you could do this no problem.) And you need some way of guaranteeing to users that *this site* is using CBCrypt or similar, otherwise reusing the password for your CBCrypt gives any password sniffer on the other end the ability to generate your keypairs as long as they can guess your username at each site, which is a catastrophic failure. 3) If you were to implement this in a password manager that could interface with a browser as a SSM, that might be the cleanest way to transition from a predominantly password-based ecosystem to a keypair ecosystem. For sites that don't have CBCrypt, randomly generated passwords can still be used. For sites that do, derived public keys could be shared, and the challenge/response could take place in the password manager, so private key material never leaves. Ultimately, replacing the SSM with a USB HSM would be ideal. 4) Given that, what advantage is deterministic key derivation giving you that a secure private key store wouldn't? Then the keylogger attack would be ineffective without also compromising the security module. Anyway, it's cool to see work along these lines. Key-based authentication that's aiming to be usable by the general public would be great. I'm glad to see the community moving away from the "everybody should learn crypto" model. Chris _______________________________________________ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
