Forgot password feature / email new credentials on accout change

[nkoester]

Users tend to forget their passwords. Its a quite repetitive task to reset it and send them an email. A nice feature would be a "Forgot password" mechanism on the login page so that users can reset the passwords themselves. Alternatively, it could be an option to add the same "Email these credentials to the user?" capability when updating account details (ofc. only if the password is changed).

[wheelybird]

I'll add an email-on-password-update option in the next release. I'm not sure about the 'forgot password' option though. In order to get this working so that it can't be abused you'd need to send the user an email with a secure link to reset the password. The problem with this is that the application would need to keep a record of the valid token, and it's designed to run statelessly. We'd have to store the token in LDAP itself somewhere; there's no suitable attribute where we could store this at the moment.

[stodge]

Could you use a local sqlite database to save this data?

[wheelybird]

Hi. No, as this wouldn't be stateless. However the ability for an administrator to email the user their new credentials when they reset them is available in release v1.5 (Docker image wheelybird/ldap-user-manager:v1.5)

[fbartels]

You probably know that application already, but maybe it would be helpful to see how this was implemented in https://github.com/ltb-project/self-service-password

[wheelybird]

@fbartels Cheers. That application stores the tokens in a file, which is something I want to avoid. I did notice it uses questions for password resets too, and those are stored in LDAP, so I don't know why they don't store the reset tokens in there too. I'll look into this for a future release.

[couling]

I'll add an email-on-password-update option in the next release. I'm not sure about the 'forgot password' option though. In order to get this working so that it can't be abused you'd need to send the user an email with a secure link to reset the password. The problem with this is that the application would need to keep a record of the valid token, and it's designed to run statelessly. We'd have to store the token in LDAP itself somewhere; there's no suitable attribute where we could store this at the moment.

The issue with implementing the email credentials option is security. Email really isn't secure. Obviously that's the user's choice, but it's always going to a "if you want to shoot yourself in the foot..." feature.

For the password reset feature, there may be a way to implement this statelessly. Rather than storing the token you only need to verify that a token was generated by ldap-user-manager. So the token would container:

• Generated timestamp
• User dn
• A random salt

Then you have two choices:

• Sign with a public/private key pair (eg gpg). When it comes back you just have to check the signature matches the server's private key and check the token hasn't expired by timestamp.
• Hash (eg: sha256) all along with a server side secret (enough bytes to make it impossible to predict). Send the three components above along with the hash and when it comes back re-generate the hash to confirm that what has been sent matches.

If there's anyway to get the last modified timestamp from an LDAP record this would be useful to stop replay attacks.

[micw]

@wheelybird Would you mind to implement this feature using stateless cryptography as suggested above? The easiest way is to use a HMAC which is more lightweight than a signature and has cryptographically the same security. It is important that the message contains the user's principal (of course), a short-living expiry date (because stateless means you have no option to prevent replay attacks) and the HMAC. The latter is created with an application secret and can be used to verify that the request is really valid.