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.

  • 49
    "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 you can lock anyone's account by entering their email address? – Joshua Taylor Aug 5 '16 at 13:51
  • 3
    There might be a perception from some people that by setting the e-mail address in the forgotten password page that you are implying it is valid in your system. – gabe3886 Aug 5 '16 at 16:20
  • 2
    I think the "standard practice" for this is to obfuscate the email address associated with the account to some degree, and this is what Apple, Microsoft and Google do in their products (to name 3 big companies whose products I've seen using this approach), displaying something like u******e@domain.com instead of the whole address. Why they do this is covered in the answers, but I didn't see anyone point out this approach as a standard or convention. – HopelessN00b Aug 5 '16 at 16:58
  • 2
    This could be done entirely through localstorage (ideally sessionstorage) on the client if need be, which means that you aren't having to work out strategies to POST the request for the forgotten password page with the email address as a in the POST body. The email address never leaves their browser for this request (it obviously will have bee POSTed for the login request, if made) and can be autofilled using JavaScript. If you do want to do this, do make sure you feature detect so you don't break things for users with legacy user agents. – pwdst Aug 5 '16 at 17:24
  • 3
    They're right. Convenience and good UX definitely aren't industry standard. Making people type things in multiple times for no reason is pretty standard. – jpmc26 Aug 6 '16 at 0:21
up vote 57 down vote accepted

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.

  • 4
    "it will make it user friendly for malicious users to lock normal users out" I don't see how? – njzk2 Aug 5 '16 at 13:39
  • 3
    But pre populating the field implies the email field was already populated in the login page to begin with. Also, I don't understand what kind of luck you would be expecting? what is the benefit for a malicious user to use this function, and how does it help them getting access to the account? – njzk2 Aug 5 '16 at 13:54
  • 2
    And malicious user can simply launch a denial of service on you. He can lock you out with this implementation. Not gain access to your account – Limit Aug 5 '16 at 13:59
  • 12
    So it's user friendly for a bad guy in exactly the same way that it is user friendly for the user. hmm The simple change is to not lock the account – Tyrannosaur Aug 5 '16 at 15:00
  • 4
    @limit Having a user friendly interface for an attacker is not a security concern. A security concern would be if it somehow makes an attack more likely or easier to achieve (easier as in less technically difficult, not as in the attacker has a user friendly experience while doing it). – Jon Bentley Aug 6 '16 at 12:30

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 bob@example.com 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.

  • 1
    Lovely information leak - well spotted! :D – Dewi Morgan Aug 6 '16 at 15:35

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.

  • 1
    Incidently, it might be worth checking for any CIS Benchmarks, or equivalent which could have some more information on this. OWASP has some good information on Username Enumeration: owasp.org/index.php/… – James Aug 5 '16 at 12:00

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 customer.name@gmali.com

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.

  • That is an excellent point. Perhaps a message / text can be updated to point that out. – Karl Gjertsen Aug 8 '16 at 7:10

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.

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.

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.