Towards a More OPAQUE World … Where Passwords or Hashed Password Are Not Stored On Servers

Towards a More OPAQUE World … Where Passwords or Hashed Password Are Not Stored On Servers

Why do we still store passwords on corporate servers?

Why do we still store hashed values of passwords on corporate servers?

Why do we still store hashed values and the salt on corporate servers?

Our fundamental problem is that Alice doesn’t want her password to be revealed to Eve, but Bob stores a hash of her password with a salt value. If Eve gets access to this, she basically just searches a dictionary of common passwords or brute force, and just adds on the salt value that he has used:

Increasingly we use ZKP (Zero-Knowledge Proofs) to prove that the Bob still has knowledge of his password. Another method is PAKE (password-authenticated key exchange) and which supports the hiding of a shared password within network communications. With this we can have a relatively weak shared password on either side, and then communicate to determine a strong shared key:

One of the most implemented PAKEs is SRP (Secure Remote Password) [here], and which is integrated into TLS and into a range of Apple products (such as with the iCloud Key Vault). But it is not the best PAKE around, and OPAQUE aims to provide the best methods around.

A perfect solution?

The perfect solution for our online world is for us to never store a user’s password or hashed version of the password on our servers, as there is no chance of an intruder finding out the password. Our data breach report which just say, that someone had stolen a whole lot of random numbers, and which can never be resolved back to anything that resembles their password.

So it seems impossible, but it’s actually easy. All we have to store is a salt value, and which is generated when the user registers their password. All that is stored is a completely random number:

Now Alice (the client) knows her password, and Bob (the server) only knows her salt. If Bob gets hacked, there is no way that an intruder will be able to know Alice’s password, as there is not even a hashed version on the server (Bob). Initially Alice registers with Bob, and generates a secret client key, and Bob gives her the server’s public key for a future key exchange.

The protocol we define is OPAQUE [link]:

So how does Alice learn the salt, without actually determining what it is? For this we use an oblivious protocol named Diffie-Hellman Oblivious PRF (Pseudo-Random Function). This passes the salt value to Alice, but she cannot determine what the actual value is. The usage of the password registration process makes sure that there are public and private keys used to validate the generation of the shared key.

The client then receives a ciphertext which can only be decrypted within the right knowledge of the keys used in the registration. The decrypted is then checked against the key generated earlier, and the client with them know if the key is correct.

Conclusions

Try not to store passwords on your server. Try not to stored hashed version on your server. Just store a random salt!

If you want to learn about oblivious transfers, have a look here:

and here is a presentation on PAKE: