On Thu, Sep 17, 2015 at 12:57:42PM PDT, Edward Ned Harvey (lopser) spake thusly: > 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.
I'm not sure I understand you here. But my initial reaction is to caution you against confusing the public by pushing this. They are much better off using separate passwords and a password manager. > 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. We should also assume (because it is true) that it is much easier for bad guys to access the passwords in the database than in memory post-decryption or in the decryption software itself etc. I have seen plenty of cases where SQL injection caused db contents to be spilled out in a web page and very few where attackers stole directly from RAM (rare, but happens) or from the crypto code itself (certainly possible but I am not aware of specific incidents). These are very different levels of risk. > 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? The employees operating the routers could see ALL passwords to EVERY site that passes through their router. And have no business reason not to compromise the passwords. The employee operating Google (for example) can only see Google passwords and when my Google-specific password gets leaked I will know who to blame. Again, very different levels of risk. > 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. Sure, but less likely. Different levels of risk and different threat models. > 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 really hope you can phrase this very differently. Rather than saying "It should be ok to reuse passwords" please focus on "use cbcrypt instead of encrypting passwords". Otherwise it is only a matter of time before some newbie software developer out there will be pointing to this as a reason to not encrypt and they won't be using cbcrypt. -- Tracy Reed
pgpCtwC4KJkNx.pgp
Description: PGP signature
_______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
