Reset one's password

[benel]

The general idea is to send an e-mail with a URI that cannot be forged.

A. Different options could be used in the URI to make it unforgeable:

1. a document UUID (if there are no other way to create one or to list them),
2. a hash of the login (or e-mail) salted with a secret,
3. a true asymetric digital signature,
4. a one-time token (e.g. UUID) added to the user document by an admin.

B. On CouchDB's side, the password can be reset either:

1. by the user itself (which would be applicable for password reset only with proxyauth set up on CouchDB and if the proxy can check the unforgeable URI itself),
2. by an administrator (which means that the service that checks the unforgeable URI should know the admin credential),
3. by anonymous in admin party (not applicable).

For implementation simplicity (balanced with security), I would favor solution A.4+B.2.
@franck-eyraud Do you think about other solutions or do you favor another one?

[benel]

@adeprez I will assign you to this feature as soon as you have joined the team.

[franck-eyraud]

I find your list quite exhaustive, I would probably not reach that many alternatives.

Some comments :

• A2 doesn't seem very secure if the salt is fixed, since the hash is always valid for a single user (i.e an old email found in the trash after a long time is still valid to reset the password)
• B1 is slightly preferable to B2 as it doesn't require to store CouchDB admin's password in the proxy (even if it can also be a normal account which is admin for the _users database, it is still password stored probably in clear text).

For me both A and B can be done by the proxy, so the whole password reset would be a "module" of AAAforRest. And we can avoid to store admin's credentials if we use the proxyauth (i.e. admin authenticated by proxyauth while storing UUID or new password).

Note that storing the password is a bit more complex for couchdb v1.0 and below (including cloudant) : it needs to be hashed client side. I suggest to specifically declare the incompatibility.

[benel]

@adeprez For A4 and B2, I've just tested if admin edits could be done from an _update function added to the _users database. But "Only admins can access design document actions for system databases".

So the only way to do edits with admin privileges will be from a node service that knows admin user credentials:

• one for setting an attribute in the user document with a UUID,
• the other for checking that the UUID is correct, to remove the UIID and update the password.

[franck-eyraud]

I just realized that to allow admin access through proxy authentication, it is required to use the X-Auth-CouchDB-Roles header (whatever the username) :

$ curl -H "X-Auth-CouchDB-UserName: admin" http://127.0.0.1:5984/_active_tasks                                         
{"error":"unauthorized","reason":"You are not a server admin."}
$ curl -H "X-Auth-CouchDB-UserName: whatever" -H "X-Auth-CouchDB-Roles: _admin" http://127.0.0.1:5984/_active_tasks
[]

[benel]

I just realized that to allow admin access through proxy authentication, it is required to use the X-Auth-CouchDB-Roles header (whatever the username) :

Indeed. That's why I used a different URI in my test 98fc486.

[benel]

For your information, I am refactoring the registration feature (from CouchDB attachments to Node static server) so that integration will be easier with node services needed for this part.

[benel]

I just realized that to allow admin access through proxy authentication

Please note, that the client will not initiate admin requests. Only the reset services.

[franck-eyraud]

Please note, that the client will not initiate admin requests. Only the reset services.

Yes I know, but it is a way to allow the reset services to authenticate wihthout having the actual credentials in some config file.

[Luwangel]

We have designed some mockups to show how the authentication system will work. This system will be used on TraduXio and that's why we use it as demonstrator.

User's scenario

Step 1

First of all the user who wants to connect needs to open the login page.

Step 2

We consider now that he tries to connect and fails. He has definitely forgot his password and needs to recover it. To do that he has to click on the link Mot de passe oublié ? (Forgot password? in english). As a result a formular appears on a new page and he just has to fill the field "Email" and clicks on the button.

Step 3

Then he receives a mail with a link to access to the reset formular. In this last page the user can choose a new one he will never forget (until the next reset).

[ammelanie-utt]

To have the same mockups style as the register's one (#28) we made three new mockups with the same information as the ones above.

[Luwangel]

We can now consider the mockups as finished. However we don't know if the recipe tests are necessary for this functionality. They could be difficult to write because of the external mail. For this particular reason we can imagine a test in two parts.

Part A : reset the password

1. Click on the "Forgot password" link
2. Fill the formular with an email
3. Generate the content of the email before sending it (don't forget to catch the generated content)
4. Click on the reset link catched
5. Set the new password
6. Check the login

Part B (manual testing ?) : send the mail

1. Test if the mail is really sent (after the first part occured)
2. Compare the mail content with the content catcher in the part A