3

Based on the description of SRP, it seems that it would be possible for a client application to cache the hashed password x and reuse it for subsequent authentifications. The actual password p doesn't seem to be used for anything but calculating x on the client side.

In addition to the most obvious advantages of SRP over "regular" client- or server-side hashing (no dictionary attacks possible even on weak passwords), are the following assumptions true?

  • The server doesn't have to store passwords or password-equivalent data. If the server storage is compromised, an adversary using that information will be unable to impersonate a client after the incident.

  • The client also doesn't have to store the password or equivalent data: The hashed password can optionally be stored as an authentication token for use without user interaction; alternatively, it can be discarded and recomputed from the salt s and the user-provided password p.

3

Your assumptions are true; they are features of SRP.

In the description you link to, note that the value x is computed from the password p and salt s (so it can be re-computed on the client side if needed), and the password verifier v is obtained from x with a modular exponentiation, which is quite one-way (recovering x from v requires computing a discrete logarithm, which is known to be very hard, and not feasible if the modulus is large enough). The server stores v, not x, and knowledge of v is not sufficient to authenticate as a client -- you need x for that, which the server does not store and, indeed, never learns at all.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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