Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month, online, via Jitsi Meet.

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



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 / webmaster@blu.org