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



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.



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