But then, if I manage to brute force a password somewhere, doesn't that give me the correct credentials to authenticate everywhere else that shares the same set of credentials?
--Matt On Thu, Sep 17, 2015 at 12:58 PM, Edward Ned Harvey (bblisa4) < [email protected]> 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 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. > > _______________________________________________ > bblisa mailing list > [email protected] > http://www.bblisa.org/mailman/listinfo/bblisa > -- "Today, vegetables... Tomorrow, the world!"
_______________________________________________ bblisa mailing list [email protected] http://www.bblisa.org/mailman/listinfo/bblisa
