Dirk Boer
Dirk Boer

Reputation: 9075

Should a Reset Password link be different every time?

The approach that I'm taking right now is:

The advantage is that it is pretty straightforward, and I don't need to create any new database columns.

The disadvantage could be that the link is always the same for that user.

Is this a security problem?

Upvotes: 1

Views: 105

Answers (2)

SilverlightFox
SilverlightFox

Reputation: 33538

This seems a big compromise simply to avoid extra database columns and to provide simplicity for you.

You should securely generate a token for use in the link and for storage in the DB. This has the advantage that it can be randomly generated each time and an expiry data can be associated to the token.

This will minimise the risk as the reset link has a limited life span and has less chance of falling into the wrong hands.

I disagree with security questions being used at all (in @Marcus Adams's answer) because these questions can usually be easily guessed if the attacker knows the victim (or can usually easily find out these days via publically available information such as Facebook profiles). Also, they have the disadvantage of not being able to be updated easily (e.g. your favourite pet's name will remain the same unless you buy a new, better pet - or if you make one up you'll probably forget it, defeating the object of it in the first place).

Upvotes: 1

Marcus Adams
Marcus Adams

Reputation: 53850

I'm assuming that you're emailing the password reset links and that the user has to enter a userid/email address to start the process.

Make sure you generate a new random salt each time the user resets their password, so that there can't be any replay attacks.

For example, if the salt doesn't change, the password reset link wouldn't change, even after a password reset. If a hacker were able to obtain the link, even a year later, the hacker would be able to re-use that link to reset the password to whatever they want.

Quite often, after clicking the password reset link, the user is asked to answer a security question that they setup previously. This helps mitigate the issue of a hacker obtaining and using the link before the user does.

The fact that you can reset a password at any time, even if it wasn't requested, smells, but since doing this requires the password salt, secret application-level salt (really, a key, since it's not random), and perhaps a security question, not to mention the fact that requesting a password reset link is trivial (only need userid/email address), it should be good enough.

You may have some performance issues down the road since in order to verify a password reset link, you'll have to scan all the rows in the user table, applying the hash to each row, until you find one that matches.

Upvotes: 0

Related Questions