3

I consider implementing a Secure Remote Password (SRP-6a) verifier that omits the username from the x key hash. The intention is to allow authentication with multiple alternate user identifiers such as uid and email.

The verifier is normally computed like that:

v = g^x mod(N), x =H(salt || H(username || ":" || password))

Instead I consider having this (username not included):

v = g^x mod(N), x =H(salt || H(password))

Are there any security implications to that?

Improve this question
2
  • This may be an uninformed question, but is the salt unique per-user? Even if so, and the salt is randomly generated, I imagine there's the odd chance that two users with the same password could authenticate as each other if their salts happened to be the same. This would likely be a rare-ish occurrence even if all users used the same salt, and unique randomized per-user salts would make it much more so. Plus, it would presume some amount of intimate knowledge on the "attacker's" part. But then, we go into a discussion about "security through obscurity"...
    – Iszi
    Oct 19, 2011 at 4:31
  • 1
    You didn't explain why you want to leave out the username. (But @Thomas Pornin's answer is authoritative.)
    – D.W.
    Oct 20, 2011 at 8:26

1 Answer 1

Reset to default
6

The original SRP specification used H(s,P) for a not-thoroughly-specified password derivation scheme, which includes the salt and the password together (but not the identity). The first draft for RFC 2945 (that's SRP-3, predecessor to SRP-6) already includes the user name in the hash.

Usually, the inclusion of the user name in a password derivation scheme is meant to simplify security proofs; with the inclusion of the user identity, one can study the security of SRP without having to bother (much) with what happens when an attacker plays tricks between a server and several clients (e.g. tricking two users into talking to each other, each one believing that the other is the server). Protocols with more than two parties are exponentially more difficult to analyze; the user name as part of the hash makes the security of the whole thing simpler (which does not mean simple, only possible to study).

Therefore, implications of omitting the user name from the hash are, at best, not investigated. So, do not do it. This is also the general advice about cryptographic algorithms and protocols: do not fiddle with them, because security is a subtle thing and you cannot know, by yourself (even if you are a competent cryptographer), if you still have it or not after any minor modification (it takes a lot of competent cryptographers to know that).

For your specific problem, I would advise registering several "users" for all the identifiers that the user may wish to use, and logically link them to the same identity once the protocol has run.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .