<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, May 7, 2018 at 11:43 PM, Kristian Gjøsteen <span dir="ltr"><<a href="mailto:kristian.gjosteen@ntnu.no" target="_blank">kristian.gjosteen@ntnu.no</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
</span>While zero knowledge proofs are great, they are on often not what you are looking for.<br>
<br>
Quite often, what you actually want is authenticated key exchange. If you want to use a password to authenticate the key exchange, you need password-based authenticated key exchange (PAKE). There is an extensive literature on the topic. There are standards and software that allows you to use PAKE with TLS.<br>
<br>
For various reasons, we don’t use it.</blockquote><div><br></div><div>We should be heading in that direction.  However, Zero Knowledge proofs don't work for passwords.  The problem is that passwords are guessable.  Zero knowledge proofs work only for proving knowledge of secrets so difficult to guess, that we can ignore that case.  For example, a zero-knowledge proof of the discrete log of a number in a field where the discrete log is hard to compute wont work for passwords, because the proof relies on g^s, where g is the base and s is the secret.  If s is derived from a low-entropy password, anyone can mount a brute-force attack on s.</div><div><br></div><div>We do have <a href="https://en.wikipedia.org/wiki/Zero-knowledge_password_proof">Zero Knowledge Password Proofs</a>, which is a misleading term: the verifier must be in possession of data derived from the password, meaning that the verifier can mount a brute-force attack.</div><div><br></div><div>We should be able to eliminate sending passwords to servers in most cases, and instead let our devices authenticate for us.  We authenticate to the device, possibly with a password, pin, fingerprint, etc.  Then the device proves possession of a private key to the server, which is enough for the server to allow access to that user's data (unless we have 2-factor on, which is superior).</div><div><br></div><div>However, even then, we still have the "new device" problem."  How do we give access to a user's account when the user is on a new device that she has never used before, and when they have no access to previously registered devices?</div><div><br></div><div>So, we still require companies to secure their password-derived data.  One angle to work here is to secure that data better.  For example, encrypt the password-derived secret to the public key of trusted hardware, rather than writing a password hash and salt to a database.</div><div><br></div><div>If there is another angle, where companies no longer require password-derived data to help authenticate users on new devices (and previously registered devices are not available), I'd love to hear about it.</div><div><br></div><div>Bill</div></div></div></div>