I have noticed that some sites would not let you login with the old password if a new password is requested, but was not changed.

Example: I forgot my password and requested a new one in the email. Received the email to reset it, clicked on it and then while typing, I remembered the old password. So I cancel the page and go back to the login page. However, it would not let me login with the old password as I have requested a password change.

What compromises are made possible if we let the users login with the old password, instead of making them change the password?

4 Answers 4


Yes, you should allow users to log in using the old password until they have changed the password. Otherwise it would be possible to lock users out of their account by requesting a password reset for them.

  • Not exactly, as the password would probably have been "wiped" when the OP clicked the link in mail only.
    – Tensibai
    Commented Feb 9, 2017 at 10:54
  • @Tensibai, Wipe password with what? A "", NULL or a special flag? Thats a very unconventional and weird design choice. Not to mention its un-intuitive. If I, out of mischief, use the forgot password feature to send out an email to your account and you accidentally click it. Now it means that you will have to change your password because the act of merely clicking on that link "wiped" your password!!
    – Naya Bonbo
    Commented Feb 9, 2017 at 18:18
  • @naya was my point yes, I used 'wipe' as I can't guess how the invalidation works exactly, I agree it could be a weird design but some DB framework use this pattern, empty the field before new write
    – Tensibai
    Commented Feb 9, 2017 at 18:22

The behavior you're describing makes sense in some way, your password was probably wiped out when you did open the new password page as you already proved you were the author for the change or really wished to get a new password.

In my opinion it doesn't add or remove security, it's more an implementation detail driven by either:

  • the way the framework works (cleaning up the database entry before saving the new one).
  • the dev team didn't think someone would cancel the new password and though it was better to clean it up on page load.

I'm in favor of handling the "cancel" case, the password should only be wiped/overwritten when the user has validated the form, for the same reasons @Sjoerd gave: to avoid locking out users.


The client can reset his password because he may suspect potential attacker has it. It would be a terrible idea to send him an email that states his password will be cleaned (or moved to "old_password_hash" field) even if the attacker can still use it after the client clicked the link.


You can set different policy for different user: Normal user can still login with same password until they change their password white high privileged user you should enforce password change according to your organization policy

  • Sorry, that does not answer the question
    – user13695
    Commented Feb 10, 2017 at 8:16

You must log in to answer this question.

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