Change of user ID (email) throw exception with library

[Benny Nissen]

When I try to change the user ID of a user I get the following exception in step 2:

Client M1 does not match Server M1

How shall I handle the case where a user like to change the ID of the account - shall I really treat it as if the user have created a new account?

/Benny

[Benny Nissen]

Eg. I need to generate a new srpverifier

[Benny Nissen]

The email is in my case just a sort of ID but with the thinbus library it becomes part of the autentification process

[simon]

The email is used as part of the verifier. So yes if they change their email/username you need to regenerate the verifier.

[simon]

Not a bug.

This is becuase SRP as defined in RFC 2945 concats the username to the password as published at https://www.ietf.org/rfc/rfc2945.txt

   Password entries are generated as follows:

        <salt> = random()
        x = SHA(<salt> | SHA(<username> | ":" | <raw password>))
        <password verifier> = v = g^x % N

   The | symbol indicates string concatenation,

So if the user changes either their password or their username you need both and to generate a new verifier (as though they are a new user).

The reason for this is to avoid ever leaking whether any two users use the same password to someone who can see the database. We cannot enforce uniqueness of user passwords and the space of possible user passwords may be small. It is recommended to use a password strength meter to prompt users to use complex passwords but that may not have been setup. It is also recommend that the salt has enforces uniqueness with a database constraint; but someone may not do that. The salt can optionally be generated at the browser. Browsers can be buggy and may have a not-so-random number generator. So two users may get the same salt and also choose the same password. If we don't concat the unique user name to the password when generating the verifiers then they will be equal. That is a bad thing as anyone looking at the database who sees two users with matching verifiers can instantly know that those two users have chosen the same password.

Any leak of any information can be exploited. In this case let us say one of the two users was the system administrator and the other was a 'read-only user' without any strong permissions on the site who has a low paranoia about their password. Now the attacker knows that if he tricks the relaxed user into telling their password they will have obtained the system administrator password.

As you can see a lot of careful thought has gone into the both the design of SRP, the RFCs and the choices made to give strong security.

[simon]

The verifier is generated by the JS library which lives in the main project so I have added a note to the readme on that project to point this out so that people will know about it.

[Benny Nissen]

Do you think there is any demand to update the srp salt value when changing id or password?

[Benny Nissen]

E.g. it is just a unique ID

[simon]

The salt is public in terms of the algorithm. By which I mean it is not a secret. So I do not foresee any reasons to change it. Then again there is no harm to changing it so that code can be reused.