Imagine this: You have postfixadmin setup for example.ORG which manages email forwarding only, no mailboxes. Postfixadmin manages the example.ORG virtual mail domain. You have user1@example.ORG who has - long time ago - setup or received a password to manage his mail forwarding service via postfixadmin, and has postfixadmin configured to forward mail to user1@example.COM, where he can still receive email.
Now user1 wants to change the email address his mail is forwarded to from user1@example.COM to user1@example.NET, but he forgot his postfixadmin password. Now would it not be nice if user1 was able to receive an email to his email address on file (user1@example.ORG), thus forwarded to user1@example.COM, allowing him to confirm that he is in fact the 'owner' of this forwarder and therefore allowing him to regain access to postfixadmin so that he can change the address user1@example.ORG forwards to?
This is a common use case for our setup where we have email aliases only and many users who need to configure them. Currently, if you (being a non privileged user) forgot your password, and try to login with an incorrect one, all you get to see is "Your email address or password are not correct." There is no way to regain access for the user. As such, right now, we need to spend lots of support time on resetting passwords for users. This could, however, be automated, and a user self-help functionality for password resets would be appreciated.
Below the login form for users, display a 'reset password' link. Once clicked, display an informative page explaining the password reset process to the user.
Send a confirmation email to the user's email address on file. This email should contain a URL which refers to a (new) script of the postfixadmin installation. The URL contains a unique identifier which allows the user to confirm that he has had access to this confirmation request email. When clicking the URL, the user is forwarded to a web page where, if the unique ID matches, the user can then set a new password by himself. If the unique ID doesn't match, an error page is displayed.
The unique ID can either be randomly generated and stored on the database (preferred security-wise) in relation to the email address it was generated for, or, more easily implementable, can be a hash of email address, date (in format YYYYmmdd) and a secret key (which is shared sitewide and stored in config.inc.php). This hash can later be generated by the application and checked against the UID which was passed via the URL.
The password reset function should be rate limited per email address: when a given number over a given time of reset requests has been triggered (such as three password reset request per day and email address), further requests within this time frame are refused.
Log in to post a comment.