[Discuss] Reusing Passwords on Different Sites Should be OK

[Chris Markiewicz]

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