<div dir="ltr">But then, if I manage to brute force a password somewhere, doesn't that give me the correct credentials to authenticate everywhere else that shares the same set of credentials? <div><br></div><div>--Matt</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 17, 2015 at 12:58 PM, Edward Ned Harvey (bblisa4) <span dir="ltr"><<a href="mailto:bblisa4@nedharvey.com" target="_blank">bblisa4@nedharvey.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="#0563C1" vlink="#954F72">
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">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.
<a href="https://en.wikipedia.org/wiki/Third-party_doctrine" target="_blank">https://en.wikipedia.org/wiki/Third-party_doctrine</a> 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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">tl;dr<u></u><u></u></p>
<p class="MsoNormal">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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I work at Concept Blossom, and we're promoting awareness about this issue. We produce
<a href="https://cbcrypt.org" target="_blank">https://cbcrypt.org</a> 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.<u></u><u></u></p>
</div>
</div>

<br>_______________________________________________<br>
bblisa mailing list<br>
<a href="mailto:bblisa@bblisa.org">bblisa@bblisa.org</a><br>
<a href="http://www.bblisa.org/mailman/listinfo/bblisa" rel="noreferrer" target="_blank">http://www.bblisa.org/mailman/listinfo/bblisa</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">"Today, vegetables... Tomorrow, the world!" </div>
</div>