Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Reusing Passwords on Different Sites Should be OK

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.
> 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".


BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!

Boston Linux & Unix /