Copying the email address to a forgotten password page

Question

I am responsible for a website and I am questioning the logic of some 'Industry standard' policies that I have been asked to comply with.

When a user logs into the website, they get a message to tell them the login details are incorrect, but we do not specify if it is the username or the password that is incorrect.

If the user then realizes they have forgotten their password (should have used a password manager), they can click on the forgotten password link and enter their email address and press enter. They are then shown a message telling them that if they have an account, the account has been locked and that a password reset email has been sent to their email account.

So far, there is no leakage of information about which credential is incorrect or whether an account exists for the email provided.

To improve the user's experience, I suggested that if the user clicks on the forgotten password link, if it is available in the login field, we should copy the email address into the email address field in the forgotten password page.

However, I have been told this is against 'Industry Standards', even though nobody can show me anything to back this up!

I understand that simply adding it to the URL would be bad, as it would allow people to cycle through email addresses and lock people's accounts out, causing inconvenience to the users.

What security vulnerability, if any, would make this bad practice?

Edit:

An update for any new readers.

There have been some great answers on here and I am grateful for all of the input.

The process had a flaw, in the lockout on forgotten password and this will be amended. The message when a locked out account still gives the email address or password incorrect message, so the user would not know the email address was a valid one.

Answer 1

None as such
The change that you are proposing seems only to be a user experience change. Yes, someone can say that it will make it user friendly for malicious users to lock normal users out of the system but that's not on you.
The bigger problem for you is your policy of locking the user's account when they click on forgot password. It makes it very easy for a malicious user to lock you out of your account. They just have to go to forgot password -> Enter the valid email id -> Hit the reset button.

Answer 2

There aren't any major concerns here, although I would ensure that caching is disabled so that anyone visiting the page in the same browser doesn't gain access to the email address if loading the Forgotten Password page.

Header recommendations from here. Note that while pragma is by specification a request header in HTTP 1.0, many browsers and proxy servers would still interpret it if given in a response.

Cache-Control: private, no-cache, no-store, max-age=0, no-transform
Pragma: no-cache
Expires: 0

You should also mitigate cross-domain referer leakage and storage in the browser history by POSTing the redirect to the Forgotten Password page.

Other comments on your general approach

They are then shown a message telling them that if they have an account, the account has been locked and that a password reset email has been sent to their email account.

Locking the account could be done as a Denial of Service attack against a particular user. If I know that [email protected] has an account on your system and I want to deny him service, I could repeatedly request a password reset for that account in order to keep locking him out.

When a user logs into the website, they get a message to tell them the login details are incorrect, but we do not specify if it is the username or the password that is incorrect.

What do you display if the account is locked out?

If you say that their username and password is incorrect then the user may be confused if it is in fact locked (as per my DoS explanation above).

However, if you say that their account is locked out are you also doing this for non-existent accounts? I ask because if not, as an attacker I could attempt a password reset, and then immediately try logging in as the same user. If I then get a message saying the account is locked, I have then discovered a valid account (this is classed as a User Enumeration vulnerability).

Therefore you may also wish to make your logic appear to lock non-existent accounts if a password reset was attempted. You may want to appear to unlock these after a random period of time, otherwise an attacker could infer that a permanently locked account is an account that does not exist due to it never having had been unlocked.

Answer 3

I cannot see any 'industry standard' that you have broken, when copying usernames to the forgotten password page.

As far as I see it, as long as you are displaying the same message for a valid and invalid username (e-mail address), when this is submitted to the forgotten password facility, you should be fine.

I.E. Regardless of a valid or invalid e-mail address, the user will be shown a message along the lines of: "Thank You! If an account has been created with the supplied e-mail address, an e-mail will be sent to that address, with instructions to reset your password."

The only way that I can see an issue would be, if the username field is enabled with Auto Complete. Obviously if the user is on a shared computer, then they run the risk of their username (e-mail address) potentially being disclosed to an attacker, but that all depends on the type of website that is being discussed here.

Answer 4

Potential security flaw aside, this relies on the assumption that the customer was correct in thinking they had the email address right and that it was only the password that was wrong.

A customer who mistypes their email address and doesn't immediately notice this fact will hit reset password, the email address will be autofilled, and they will click 'reset password' without double checking the email address that was autofilled. A typo in the email field may not be noticed, and the user is likely to assume that the password is the thing that is wrong if the email address looks correct at a brief glance.

They will then wait for a while for a password reset that is not going to ever arrive, because it went to [email protected]

Their next step will be, depending on the nature of your business, to call customer support, to find a competititor with the same product, etc. None of the fill in the blanks here are good for you.

Answer 5

The copying of the email address already entered in the login page to the password reset page is not a security flaw.

The only difference is whether the user must re-type the address they know (or stole) into the forgot password box to reset. They already have this information. No data unknown to the user is leaked by copying user-provided data from the login to the reset screen. The email is not visibly confirmed and nothing in the reset process is changed. Literally the only difference is that the user does not need to type the email address twice.

Since they know their own email, or the stolen email, this reveals nothing. It is the equivalent of copying and pasting or retyping it.

Answer 6

On Selecting the forgotten password option and assuming the Login ID is an email address (rather than a username like some sites use), then I think its a great idea to place the email address into the email Address field.

This is not a security concern in my view. It should like you have to make a server side request when the user selects the forgotten password link. So why not have the forgotten password UI component already preloaded in some ways like a single page app? So, select the forgotten password link and then show the forgotten password view?

I am not aware of an industry standard that you have broken.

In general you are following the correct process You are correct if a user enters credentials you respond with 'Invalid Credentials' and give out no further information.

On selection of forgotten password change "views", populate the email address and allow the user select send, the server response is 'Forgotten Password Email has been issued'.

If you have to make a sever side request to get the Forgotten Password Page, you have correctly identified the Parameters should not be contained in the GET request, the reason for this is the server side logs will store the Query String parameters, and depending on your infrastructure and admin users, you may or may not allow these admin users knowing these accounts.