I have a web application built with PHP with a login page where the visitor is supposed to enter his / her account's email address and matching password.

Since I'm using the PHP native (slow) hashing function, every time a visitor enters the email of an existing account it will use the password verify function to check if the password is correct. This also increases the load time of the page by about 0.5 sec because of the password verification process.

If there is no existing user account with the input email, the page loads fast because it won't even attempt to verify the password if there is nothing to verify against.

Since anyone trying to brute force probably would figure out that there is an existing user account for the input email because of the page's additional processing time, would this be a possible security threat?

Note: I'm only showing a generic login error as recommended by OWASP. So that's not of any issue.

  • 2
    Do you rely on the secrecy of the user name for the security of your application? If yes, then it is a threat, if no, then it is not. Commented Sep 11, 2014 at 1:53
  • What are the user names in your app? Are they email addresses?
    – paj28
    Commented Sep 11, 2014 at 15:55
  • Yes they are, and no I don't rely on the secrecy of the email alone for User authentication. Rather a combination of an email and password. Commented Sep 11, 2014 at 16:01

5 Answers 5


This is a type of timing attack, leading to a username enumeration vulnerability.

Whether this is a threat or not depends on the design of your system. If usernames are supposed to be private them it is a concern. Some systems are written in such as way that the enumeration of users fits into the design, such as email providers, as email addresses are generally public and if someone has the email address [email protected] then they definitely have some sort of email account at example.com and there is nothing leaked by letting other users know that this exists. The username being public carries more of a risk as an attacker will know which accounts can be targeted. In an email system though, this can be achieved by an attacker sending an email to the address to find out if it bounces so there is little you can do to narrow this attack vector in this case (if you want typos in email addresses to be notified to the sender of course).

Basically the vulnerability is summed up well here:

As an attacker if I can use your login or forgotten password page to narrow my list from 10000 targets to 1000 targets, I will.

Sometimes it is assumed that if a website allows user registration with user chosen usernames or a password reset then user enumeration is always possible. This is not always the case - a user registration system can be combined with a password reset system and allow a user to select a unique email address as their username without revealing to other parties that it is already in use. This is accomplished by always returning the same message to the user on the website, but emailing the link to the next step of the process to the provided address. This ensure that only someone with access to that email address can either register or reset the password. Of course this would be for a medium security system where it is assumed an email MITM or other compromise is not a viable or worthwhile attack vector.

Timing attacks by their very nature will take time for an attacker to execute. So they might want to use this attack on your system in order to narrow their list before attempting a brute force attack on the "slow" login attempts, which will also take time.

If you wish to narrow the attack vector then you should introduce an artificial delay that will make all logins whether they have a valid username or not take around the same amount of time.


I agree this could be seen as something like a side channel attack. It could pose a significant threat, but it depends on the circumstances as most registration pages will tell you if an email is already registered. This could be an issue where users are assigned a random username such as a bank assigning a client ID.

Just hash the supplied password regardless of whether a user is found, if no user is found use something arbitrary as a salt. This will make it take a long time regardless of whether a user is found.

  • It's about a login page not registration, just to be clear. Registration page does not have this issue because the password is not needed to check if a user account already exist, just the email which is not hashed (and the rest of the form details for a valid submission). Commented Sep 10, 2014 at 22:49
  • 1
    @KidDiamond yes but if an attacker wanted to know if an email was registered on your system they could probably do so by submitting the registration form with that email.
    – thexacre
    Commented Sep 10, 2014 at 23:53
  • @thexacre - you can code the registration page to ask for their email address, then say "go check your email for further instructions" which avoids the leak. Although, Apple didn't think of that
    – paj28
    Commented Sep 11, 2014 at 20:21

I don't see this as a major threat. Yes, it gives an attacker a way to verify that a given username exists, but in a typical application, there are many other ways to get this information.

If you want to prevent this timing attack, you can re-write your login page to hash the password before checking to see if the username exists, thus slowing down all unsuccessful login attempts to the same speed.

  • So I would be fine if I was to leave it as is? Commented Sep 11, 2014 at 0:29
  • Unless there's something especially sensitive about the usernames in your particular application, yes.
    – Mark
    Commented Sep 11, 2014 at 0:52
  • 1
    If you are able to hash a password before checking to see if a username exists, you are storing them incorrectly (i.e. without a per-user salt).
    – Ry-
    Commented Sep 11, 2014 at 19:03
  • @minitech, You could be using the username as the salt.
    – Mark
    Commented Sep 11, 2014 at 19:59

Yes - this is a security threat.

As others have pointed out, this is a side channel attack. Although you are following OWASP advice and returning the same message, you are still revealing to an attacker whether the particular account exists.

If you were using user-selected names, I would say leave it be. In that case, the sign up process reveals what user names exist.

However, there are particular risks with email addresses that mean you should fix this. Specifically:

  1. An email address is linked to a person, and whether they use your site or not is private information. If your site was porn or recruitment, revealing that [email protected] is a member could be embarrassing for them.

  2. This allows spammers to perform targeted spear phishing attacks. They can start with a list of email addresses, use the leak to work out which ones are valid on your site, and send a phishing email to just those users.

The best fix is to perform the slow hash on the password regardless of whether the user exists.


One mitigation I didn't see mentioned is to add a Google reCAPTCHA (or similar). This will prevent "brute force" attempts which is what you're looking to address. Just make sure to perform the reCAPTCHA validation before validating the submitted credentials. Adding this functionality still allows one to perform timing attacks so long as they input the correct reCAPTCHA values. If this is concerning then there are probably larger issues to address (i.e. planned mitigation strategy for potential 0-day vulnerabilities).

  • 1
    As you yourself note, this doesn't address the issue of an attacker using a timing attack to determine if a username is valid or not.
    – Mark
    Commented Sep 11, 2014 at 20:57
  • @Mark, the question states "..anyone trying to brute force.." therefore I disagree with your down vote. This valid mitigation.
    – anon
    Commented Sep 11, 2014 at 21:02
  • Your solution means that a brute-force attack is (at least in theory) manual rather than automatic, but it doesn't prevent the attack from leaking the information the OP is trying to protect.
    – Mark
    Commented Sep 11, 2014 at 21:26

You must log in to answer this question.

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