I think I have a basic understanding of security concerns, but I feel like if I don't know everything, I'm going to implement lousy solutions. Below is my current strategy; Have I overlooked obvious best practices?

I've read Can anyone provide references for implementing web application self password reset mechanisms properly? and think that I have the relevant parts covered.


  1. An administrator triggers a password reset for a user in the system.
  2. The system locks out the user from the system, generates a 40 characters random alphanumeric string as a authtoken, and stores this hashed in the database with SHA1, together with the encrypted username, the time is was created and the hash of the old password. If the user have any previous authentication tokens in the db, it deletes them.
  3. The system sends a link to the email connected to the user having it's password triggered for resetting.
  4. The user clicks the link, which is over https, and the system reads the authtoken.
  5. The system hashes it again with SHA1, searches the database for it:

    • The authtoken does not match: Error page. Please contact admin
    • The authtoken was created more then 4 hours ago: Please contact admin
    • The authtoken is found and active: Goto 6
  6. The client gets presented a dialogue to select a new password and posts the new password with the same authtoken (in a hidden field) back to the server.

  7. The system checks again that the authToken exists, is active and that the password is not the same as the old one. If success, the system decrypts the username stored together with the authtoken, changes the password for this user to the new, unlocks the user, and removes the authToken from the database.
  8. The system redirects the user to the login page.


The only agent triggering the reset process is an authenticated administrator: No problem with maliciously locked-out users. All communication between client and server is going over HTTPS, with the possible and uncontrollable exception of the user's email solution.

This is how the authToken is generated:

const string authtokenAlphabet =  abcdefghijklmnopqrstuvxyzABCDEFGHIJKLMNOPQRSTUVXYZ1234567890_-.";
const int authtokenSize = 40;
var authToken = string.Empty;

while (authToken.Length < authtokenSize)  
    authToken += authtokenAlphabet[_random.Next(0, authtokenAlphabet.Length - 1)];

Although I use the Random class, which is discouraged due to less than optimal randomness, would this really be a problem considering that only an an authorized and authenticated administrator can trigger the reset?

1 Answer 1

  • In 1 Is this trigger protected from XSRF?
  • In 2 you're locking the user account for 4 hours? That's a DOS

  • In 6 you're using weak random generator. If someone discovers this he/she can generates authToeksn for anyone.

  • you never mentioned how are you encrypting usernames? Think about the ability of encrypting a username and injecting it into authToken This will lead to changing the password of that username in your system even if that username did not ask for new password to be set.

  • Also note that authToken is from client. The basic security rule is to never trust anything coming from client, so make sure you sanitize these tokens properly from sqli, slqi, etc.. This applies to the new-password as well!

  • Thanks for your answer. 1. Yes, I would say so. Locked control panel that only one or two has access to and thus know how it works, requires POST-action and is over https. 2. Well, the user gets locked out until it resets it's password. After 4 hours the authtoken is expired and have to request the admin to reset it again. But only an authorized admin can trigger this, and he should have that power. 6. I don't see how these would be usable, the authtoken must match the one that is stored in the database, within it's lifespan of four hours.
    – Alex
    Jun 9, 2014 at 3:13
  • . A slightly modified version of dotnetspider.com/resources/…, the username is not a part of the authToken, just stored together with it so that the system know whos password to reset. . I immediately hash the authToken and search for it in the DB, not much can happen here. Password is set with ASP.NET Membership provider, I think their infrastructure can handle any potentially malicious passwords.
    – Alex
    Jun 9, 2014 at 3:14
  • Oh, and the user still can change their password manually without using this functionality. This is only if the user forgets his password, gets locked out due to many failed login attempts or that the password is to old based on some policy rules. Oh, and yeah, there is the DOS. You were right about #2. Well, I don't think the threat for that is significant in this system, let's wait and see if we get a problem there.
    – Alex
    Jun 9, 2014 at 3:17
  • Oh, and regarding the xsrf, I just added verification for all relevant methods that the http-referrer is internal, so I guess that makes it really secure now in regards to xsrf. Thanks.
    – Alex
    Jun 9, 2014 at 3:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .