Implementing password-reset in a web application by authtoken over email

Question

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.

Flow

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.

So

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?

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!