I read RFC 2945 and 5054 describing SRP, but there was no mention of registration.
How should user registration happen in SRP? Is there a standard or paper describing it?
$\begingroup$
$\endgroup$
3
-
3$\begingroup$ This is outside the scope of SRP. Any secure method you can think of would work, just like with any other authentication protocol. $\endgroup$– otusCommented Nov 30, 2015 at 11:58
-
$\begingroup$ I know that registration process is not dealt in SRP. But i 'd like to know whole system using SRP. Do you know some system using SRP included initial registration ? $\endgroup$– Eps YooCommented Nov 30, 2015 at 13:55
-
2$\begingroup$ SRP uses cryptography, but I don't see how this question has anything to do with cryptography. In fact, I'm not even sure this question has anything to do with SRP. How does a user register their password verifier at any host? Is it different for SRP? Perhaps this question should be moved to Security.SE? $\endgroup$– mikeazoCommented Nov 30, 2015 at 17:12
Add a comment
|
1 Answer
$\begingroup$
$\endgroup$
As mentioned in the comments this is a standard problem not unique to SRP and not really about the cryptography of SRP. So this question would probably be better posted on 'security.stackexchange.com' as it is more of a generic problem.
Fundamentally setting a shared secret like a regular password or a password verifier over a public network has its challenges. For most applications the standard techniques used to reset a regular password can be reused in the setting of the password verifier.
The diagram on this page in the context of a javascript SRP library shows how the user is registered onto a websites secured using SRP. The user keys in the password into the browser and javascript generates the verifier and transmits it to the webserver. You don't want people to run an offline dictionary attack against the verifier so it is a form of shared secret. This means you want to protected it like you would protect them setting/registering/resetting a traditional password (e.g. use https and aes encrypt it within the database).
The only choices you have is whether the salt of the user is generated by the client or the server. It makes sense for the server to do this as it can ensure that the salt has high entropy and is unique to the user.
