I've got a login page with a form where they can input their account's email address and password.

I'm doing the following things before even attempting to authenticate a user:

  • Validating the email address for correct format.

  • Validating the password for not being empty.

If any of these are invalid, I report back with the validation errors like:

  • "You did not enter an email address." and/or "You must enter a password.".

It's also susceptible to timing attacks since password verifying is not attempted when there are errors.

Would it be safer to just accept any input and just report back with a generic "Login failed." error?

  • How are you validating the email address? There are about a zillion obvious but wrong ways that will reject valid addresses, and only a few ways that actually work.
    – Mark
    Commented Sep 26, 2014 at 10:40
  • @Mark I'm validating the email address the same way I validate it upon a new user registration; with PHP its FILTER_VALIDATE_EMAIL filter. Commented Sep 26, 2014 at 10:41

2 Answers 2


Sorry, I do not get the part on your concern with timing attacks. As long as the passwords are properly hashed and the comparison is done on the hashes, your application should be safe from this kind of side channel attack. Whether a database call has been made or not (2s vs 1s) does not leak any information on your password.

It is always good to validate form inputs, regardless of whether they are stored in the database, in case your database query is susceptible to an SQL injection. This strategy is known as defence in depth. You never know when your query parser is made vulnerable by some weird user input like the recent shellshock exploit.

There is really not much of a security issue whether you report the failed login by showing individual errors of or by grouping them together. What an attacker can gain from here (whether an email address is valid) can also be gleaned from the registration page by trying to register with that email address.

  • Thanks for your answer. It's just that when there are validation errors, the page reloads fast because the password won't be verified. So I was just wondering if that would be an issue. Commented Sep 26, 2014 at 11:28
  • That's not a timing attack as no usable information is revealed except that the password failed to validate. Commented Sep 26, 2014 at 11:35

Validating the format of email address or password field for being empty can be done on client side and does not result in timing attack, because there is no comparison being done with the actual hash of the password(or password) which is stored on the server side.

The timing attack occurs if the comparison operation is not implemented properly.

Let us consider one scenario where, Attacker's guess = "12345678" Actual password = "password"

Upon the submission of the guessed password, the server should complete the check and not return the result after the first mismatch. In above case, first mismatch is at first character itself since 1 != p. If server reports this result, then the attacker learns that the guessed password was completely wrong. The server should compare every letter of guessed password with Actual password and return the result. In the above scenario all 8 character should be compared and finally the attacker should be notified about the invalid username or password.

  • I am doing that on the client-side, but also on the server-side. Secondly, my password validation is not validating against the actual password, but just checking if the input field is empty or not before even trying to authenticate the user. My question just asks if I should validate the input field (to return any input field validation errors to the user) or not. Commented Sep 26, 2014 at 10:54
  • Why can't you complete your validation on client side? Checking for the email format or blank password field can be done on client side itself. Then you can specifically point out invalid email-format or blank password field.
    – Curious
    Commented Sep 26, 2014 at 10:59
  • I just said that I am doing it on the client-side. A large part of my audience has JavaScript turned off. Commented Sep 26, 2014 at 11:08
  • You can validate those field on server side too. As I explained there is no threat of timing attack if you are not comparing the passwords.
    – Curious
    Commented Sep 26, 2014 at 11:58

You must log in to answer this question.

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