0
$\begingroup$

I am looking into zero-knowledge proof-based security. I noticed that a server never needs to be sent the user's password to authenticate them - the password can be used to generate another value that is sent instead. The server has the password so it can generate that value on it's side. This way the user can prove they are who they say they are without sending the password. This shared secret value can be used to seed a random number generator, which can then be used to perform actions on their messages that make the data look random to a would-be-attacker but can be undone by the receiver (which has the seed and can recreate the scrambling process).

Such a system seems to have the following problems:

  • The attacker can now break the system by predicting the password. Since people tend to use passwords that are partially based on real words a attacker doesn't normally need to consider all 26^k possibilities for a k digit password
  • Even if you use a salt/nonce/timestamp to mutate the resulting key, it needs to either be sent to the server (allowing the attacker to use it) or the server must know it without being told, allowing the attacker to also know it without being told.
  • Even if you transform the password with something like HMAC the fact remains that the original password is not particularly secure. An attacker can simply pass their guesses at the password through whatever algorithm is used to transform the password.
  • If you want to have some counter or other data that mutates the password on a session by session basis (and you don't want to send the mutator but rather have user and server infer it from their past interactions e.g. number of logins) the user has to either remember the mutator (meaning they will be locked out of their account if they lose/forget/incorrectly remember the mutator) or have it stored on their machine (preventing them from logging in on different devices)

A possibility would be to only accept passwords with a minimum level of unpredictability (making salts, nonces and mutators less necessary) but users won't be keen to remember a soup of letters and numbers.

Is there any other issues with using the user password to generate the shared secret (the shared secret would be the seed of a random number generator) I would need to overcome?

Improve this question
$\endgroup$
0

1 Answer 1

Reset to default
1
$\begingroup$

I'm still not entirely sure what you're asking but you can use password authenticated key agreement (PAKE). It will prevent off-line brute-forcing of the password.

Improve this answer
$\endgroup$
1
  • $\begingroup$ PAKE looks like just what I need. Thanks for pointing it out. $\endgroup$
    – O.Ortega
    Aug 15, 2017 at 15:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.