[BBLISA] Reusing Passwords on Different Sites Should be OK

Patrick Cable pc at pcable.net
Thu Sep 17 18:17:13 EDT 2015


Crypto is hard. I hope you have folks reviewing your implementation,
especially if you're designing a cryptosystem to protect me from the big
bad agencies!

One thing I see missing from both your product/library github
page/indiegogo kickstarter page is a well-defined threat model. You mention
your use case and implementation (and I understand it), but I'm curious
about what boundaries/assumptions/etc. you had in mind when you built the
system?

-pc

On Thu, Sep 17, 2015 at 3:58 PM, Edward Ned Harvey (bblisa4) <
bblisa4 at nedharvey.com> 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.
>
>
>
> 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.
>
> _______________________________________________
> bblisa mailing list
> bblisa at bblisa.org
> http://www.bblisa.org/mailman/listinfo/bblisa
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.bblisa.org/pipermail/bblisa/attachments/20150917/19fc976a/attachment.html>


More information about the bblisa mailing list