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.
"bad employees" can mean many things. Yes, you're right about malicious employees. But what about idiots that copy production data to a laptop then lose it? What about your automated backup system that really just deals in files? What if your long-term backup doesn't have the same data-at-rest properties as the production servers themselves? Encryption of the on-disk stuff is really just an insurance policy against mistakes (and end-to-end security is hard enough that there /will/ be mistakes, either in the design or implementation). But even in the case of malicious employees, there is a defense-in-depth argument. Not everyone in the company actually has the programming chops to slip a bit of data-extraction code into the production servers without being noticed. Snowden is a great example: he didn't hack all the runtime systems, he just collected stuff that was laying around unencrypted at rest. > 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. I don't think that is actually sound legal reasoning. Has that interpretation come out of a court? The theoretical possibility of something does not make me forfeit anything, particularly if the company in question has a terms of service / privacy policy that doesn't include "we will capture everything you do and let our employees sift through it". Just because a malicious FedEx employee could open your package doesn't mean you forfeit your right to privacy. Likewise, just because a malicious employee could run wireshark on the production boxes doesn't make me forfeit my expectation of privacy. > 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? Good point, and it's actually worse than you think. Because most SSL sessions are actually terminated at Akami (or similar third-party content-distribution). But I don't think lack of encryption actually implies "forfeit all legal right to privacy". -- Matt _______________________________________________ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss