Why aren't zero-knowledge proofs used in practice for authentication?

Question

I read on Wikipedia that zero-knowledge proofs are not used for authentication in practice. Instead (I think) the server is entrusted with seeing a password in plaintext form, which it should then add a salt to and hash. But for a split moment, the server knows the secret. Why should I implicitly trust the server like this? It could go rogue and record my password in plaintext form. I could use that same password for other sensitive things. Aren't zero-knowledge proofs a necessity? Why aren't they used? Or are they used?

Update, an alternative: What about never reusing your password and instead generating different passwords from a master password and website name using only a program that runs on the client? It seems much simpler, because you never reveal the master password. That way, you don't need to trust the website nearly as much.

This clarifies my previous question.

Answer 1

Answering the question in your title (and not addressing your proposed alternative, which I don't quite understand), there is a zero-knowledge proof of password protocol "SRP," which is fast and effective.

Having implemented SRP and being an advocate of its use, I don't understand why everyone doesn't use it all the time. Some reasons that I have seen for dismissing SRP are:

• A belief that a server is either totally 'good' or totally 'bad' and that using HTTPS ensures you always talk to 'good' servers, which can be trusted with plaintext passwords. Real life isn't like the movies; it is more complex. The Heartbleed debacle shows that an otherwise trustworthy site can leak bits of memory such that 3rd parties can observe a plaintext password sent over HTTPS. More common would be poor error handling in custom website code which would print out a plaintext password into a log file which can be read by an intruder who can only see the file system on the server. Large systems stream logs to a central location. This makes the possibility of revealing a plain text password more likely due to poor error handling.
• A belief that the client is either fully secure or completely compromised, such that an attacker can see nothing else and can record what is being typed. If an attacker can record what is being typed, they can steal the password directly; SRP only protects against interception on the wire, and the TLS protects the wire. In reality, interception is much more routine than people realise, even using well-configured HTTPS. Large employers routinely decrypt and scan HTTPS to protect themselves from employee intellectual property theft. Even if they are only doing this to protect their digital property rights, it increases the risk of bugs leaking plaintext passwords else a rogue employee controlling that snooping software to steal all the passwords. Big laptop suppliers install things like superfish to decrypt customers HTTPS traffic to sell "smart ads" on pages. They might not be all bad people, but it increases the risks of bugs leaking passwords or a rogue employee stealing them. There have also been examples of certs being compromised, meaning encrypted traffic can be snooped. All this means that it might often be the case that an attacker cannot directly record what the user typed at the keyboard, but can view anything passed over the network even when HTTPS is being used. SRP can protect against any such interception as it is zero-knowledge password proof.
• A belief that SRP is positioned as an alternative to HTTPS. SRP does not (out of the box) verify the server (upon registration), so you might be talking to a fake server. So in an "either-or comparison" of SRP and HTTPS (assuming none of the problems detailed above) then, HTTPS is often judged superior. This is a false dichotomy as, in practice, real-world HTTPS has many weaknesses which can be addressed by using SRP over HTTPS. Performing SRP over HTTPS gives you server verification which strengthens SRP. So people should always be using both together.
• A lot of focus on two factor authentication as an enhancement to plaintext passwords. Companies who have identified that passwords are high risk tend to employ a second factor (say, a text to your phone). The site may still leak passwords, which users often use across multiple sites, many of which don't use a second factor. If sites upgraded to SRP and a second factor, they would fully protect their users.

When it comes to implementing SRP, there are a couple of inhibitors:

• A historical lack of pure JavaScript examples. An early authoritative demo used a Java applet. Recently after the Heartbleed debacle, SRP has been revived, and there are now a few solid open-source JavaScript libraries and demos.
• An extra round trip to log in. With plaintext, you send a username and password in one post. With SRP, you first send a username to get the salt (and a challenge) and then generate the password proof to send to the server. Most web security frameworks assume that everything is sent in one round trip. This can be addressed by an AJAX call for the first round trip and posting the password proof as the password. More sites are now splitting username and password across two pages to implement" social login". Based on your social email account submitted via the first page, they present a password input page that targets the correct social login server. This two-page pattern fits well with SRP, and end users are becoming more familiar with it.

There is no good reason why every site or mobile app doesn't now use SRP. So you are correct in being surprised that plaintext passwords are still in use.

Update: I still encounter aggressive pushback about SRP from crypto experts arguing about TLS being sufficient. I am sure they are only hired by high-security outfits that (in theory) would never make the mistakes listed above. The fact that they use their theoretical knowledge to shoot down a practical additional defence in-depth strategy of both TLS and SRP is surprising to me. I didn't become a fan of SRP for theoretical reasons. After the online banking system I had just upgraded failed its penetration testing with perfectly configured TLS allowing the external White Hat tester to harvest live passwords, I became a fan of SRP.

As my grandfather told me, " In theory, both theory and practice are the same. In practice, they are not." Passenger airlines use redundancy to keep people alive. Security practitioners should use defence in depth rather than a theoretical security model.

Answer 2

SRP does DH key exchange with authentication, and has the capability to also authenticate the server as well (though usually the server is authenticated by keeping the verifier secret). If the key is generated strictly from a password and salt, with the salt stored on the server, you can do a dictionary attack on the verifier (e.g. if the server is compromised or the server is malicious), but there are ways to strengthen resistance to that.

Without doing a (fairly expensive) dictionary attack, the server never sees the password, and there are various possibilities to make a dictionary attack infeasible.

Update to answer updated question: If the algorithm is known, the site-specific key is just as susceptible to a dictionary attack as any other scheme.

You could use a two-password method to make it infeasible to do a dictionary attack.

Example:
$MasterKey = HMAC(MasterPassword, Identity)$
$SiteKey = HMAC(MasterKey, Password, SiteIdentifier)$

where $Identity$ can be anything you want (e.g. e-mail address, SS#, nickname). I'm using $SiteIdentifier$ as some form of persistent identity. Domain name may not be stable enough, so either some sort of GUID or a public key or something could be used.

The $MasterKey$ could also be derived from a value stored on a key-server or on a specialized device (perhaps still in combination with a master password). There are many possibilities.

$SiteKey$ could be used directly as the secret key in a protocol like SRP, or turned into a typable password in the same way a random password generator works.

With SRP, the protocol for the standard implementation has a salt that's supplied by the server, and could be used instead of $Password$, or just generate a typable password and combine that with the salt as usual (though the need for a salt is eliminated with a random password, that would allow using the password with other implementations of SRP by typing in the generated password manually).

Answer 3

Having a client (ex. your web browser) use zero-knowledge proofs to authenticate itself to a server only makes sense if the server knows about the client's public key in advance, and if the client keeps the same private key forever. So you could have the client-side generate a keypair when you register your account, and the server records your public key along with your login info. Then you could use a zero-knowledge proof to log in. Great. I think SSH supports this kind of authentication. There are some second-factor authentication methods that work this way too, but in practice it's more trouble than it's worth; what if:

1. The user clears their browser cache?
2. The user tries to log in from a different computer?
3. Some other bad thing happens to their private key.

In all these cases the user will be unable to log in, and will have to recover their account. It'll be super annoying.

You could, I suppose, have the user type their password, and on client-side use that password to re-generate the private key. That way it's still password-based, you can't lose the private key, and you get to use zero-knowledge proofs for the actual data exchange. The counter-argument that comes to mind is that using the password as a seed does not add any strength to the password, since an attacker still only has to guess the password, but you have to perform a full RSA key gen each time you want to log into something, which can take minutes on a mobile device. Most people would find that infuriating.

In relation to your point about letting the server see your password in plaintext: Yes. This is true. I don't know what to tell you. This is why hard-core security experts will tell you to use a different password for every website, and use a password manager to keep track of them all.

Answer 4

Actually there are SaaS platforms that use Zero-Knowledge Proof for authentication, so the end user can prove to the authentication service that they know a secret, without revealing that secret to the verifying party. No security-related information is stored on the service-providers servers or the client servers which means that there is nothing for a hacker to steal.

M-Pin uses a multi-factor zero knowledge authentication protocol, the idea behind M-Pin is that each registered client is issued with a large cryptographic secret. They then prove to a server that they are in possession of this secret using a zero-knowledge proof. This removes the requirement for any information related to client secrets to be stored on the server.

You can read the full crypto paper by Dr Mike Scott at https://www.miracl.com/miracl-labs/m-pin-a-multi-factor-zero-knowledge-authentication-protocol

Answer 5

Sovrin is an identity ledger that aims to use verifiable credentials with zero knowledge proofs for authentication. Currently it supports equality and predicates with plans for zero knowledge set memberships as well. The crypto is based on Jan Camenischs work for attribute based credentials.

Instead of passwords you use commitments to secrets known only to provers in all her credentials that link credentials to the same prover. Issuers sign these blinded attributes in each credential and the commitments allow each presentation to be unique.

Answer 6

I have made it practical to use Zero-Knowledge Proof for authentication; to create an open-source fully decentralized communication platform. Have a look at HexHoot: https://github.com/zenineasa/HexHoot, https://hexhoot.com

The idea here is that a user's password is represented by a private-key and the username is represented by the corresponding public-key. These are generated in accordance with Elliptic-curve Diffie–Hellman (ECDH).

Now, assume that user1 and user2 have their respective private and public keys. They exchange their public keys with each other. Using user1's private key and user2's public key, a shared key can be obtained according to ECDH, which will be identical to the shared key generated using user2's private key and user1's public key.

Both the users can now use this shared key to encrypt and decrypt messages. The messages are encrypted/decryptd using Advanced Encryption Standard (AES) method.

I would love it if someone is interested in contributing to this project.

Answer 7

But for a split moment, the server knows the secret

... and so is the wireless bug in the cable of the keyboard, the web-cam of your laptop and iPhone, the microwave microphone of the satellite eavesdropping the sound of your keystrokes, etc. If you are afraid of the server don't go in Internet (it is not the server, BTW -it is the screen memory capturing your passwords that is not getting out of the memory ... but remains traces that can be traced and captured) you may use a smart-card for hashing and salting your password before supplying it to the server.

I could use that same password for other sensitive things. Aren't zero-knowledge proofs a necessity?

When you start using a one-time pad as multi-time breakout in the cryptography the zero-knowledge proof is your least problem. Any start up hacker on the communication line can break your 'same password' just for breakfast.