1

The thought of having input validation on my login form had come across my mind while creating the input validation for my registration form. My login form requires an e-mail and a password. Would it be overkill to validate on blur (and on keyup only if the previous input was invalid) whether what is entered in the e-mail text field is an e-mail address, and that the password is of the minimum length (registration requires that the password be at least 6 characters)?

I already coded the server-side logic to handle login, so not implementing the input validation would redirect to either the "valid input but incorrect" or "e-mail not in system" error pages.*

Knowing this, would it be overkill? Would it be nice to have a user be notified visually that their entered data is of the right format each time they login?

*(Since we're on the subject of logins, I would appreciate input on another question I have.

Currently, my system has a different notification for an incorrect e-mail/password combo than it does for an e-mail that's not in the system. I notice many sites have the same message for both (something like: "user-name or password may be incorrect"), and many don't.

This is probably because they don't want people to be able to sniff out users. However, sniffing could be done during registration as well (since all systems will notify a user if a username/e-mail is already in the system). Should I change my system to allow for ambiguity, or is it fine as is?)

Kevin
  • 2,617
  • 29
  • 35
  • 2
    one question at a time, please post your second part as a different question. – Mat Apr 16 '11 at 15:55

5 Answers5

2

Would it be overkill to validate on blur (and on keyup only if the previous input was invalid) whether what is entered in the e-mail text field is an e-mail address, and that the password is of the minimum length (registration requires that the password be at least 6 characters)?

No it would not be overkill to validate on blur. It would be overkill to validate on keyup. I personally consider that annoying as a user.

I already coded the server-side logic to handle login, so not implementing the input validation would redirect to either the "valid input but incorrect" or "e-mail not in system" error pages.*

I would recommend againts such error pages but instead redirect to the login form again with an error report saying that such and such is invalid. Error messages should be used for valid data that is not matched in the database.

Currently, my system has a different notification for an incorrect e-mail/password combo than it does for an e-mail that's not in the system. I notice many sites have the same message for both (something like: "user-name or password may be incorrect"), and many don't.

Many systems can be more complex then you would expect. Some systems have no way to detect whether the user does not exist because they treat the user / password as a single entity. If you treat them differently feel free to give more information to the user.

Should I change my system to allow for ambiguity, or is it fine as is?)

I would recommend you give to error messages "user name is incorrect" and "user name or password is incorrect". The user doesn't need to be told that said user name does not exist in your database, it merely needs to know he typed the user name wrong.

Not to mention that waiting on a server round trip is significantly higher latency then local javascript feedback. If you used something like node.js you could even have your validation in one place and not have two copies of it maintained.

Raynos
  • 166,823
  • 56
  • 351
  • 396
  • 1
    +1 but regarding, `I notice many sites have the same message for both (something like: "user-name or password may be incorrect")`: This is a security **feature** -- you should not give potential hackers knowledge that the random username they guessed is actually a valid user. – Kirk Woll Apr 16 '11 at 16:04
  • 1
    @KirkWolf That's security by **obfuscation**. It's not real security, the same data can be found through registration, _unless_ you do not have public registration. – Raynos Apr 16 '11 at 16:06
  • @Raynos, I know that -- but it's *still* considered best practice to minimize the information you are sending back when it comes to authentication. That is, to not distinguish between an invalid username and an invalid password. – Kirk Woll Apr 16 '11 at 16:06
  • @KirkWoll but it's not really going to stop a hacker. There are better techniques. I prefer to give as much user friendly data as possible. – Raynos Apr 16 '11 at 16:08
  • @KirkWoll and I'm only suggesting you let a user know if a particular user name does not exist then state "username is incorrect". If it exists state "username/password is incorrect" because they could have mispelled their username. – Raynos Apr 16 '11 at 16:12
  • @Raynos, I understand *why* you want that -- it *is* a better experience for the user. I also agree that if the usernames are publicly available anyway, it's moot. If the usernames are *not* available, however, you are making the system exponentially easier to hack. – Kirk Woll Apr 16 '11 at 16:15
  • @KirkWoll I agree with that. If usernames cannot be accessed via a list or a register form then your increasing data source from 0 to 1 instead of 1 to 2. That's a security risk. – Raynos Apr 16 '11 at 16:15
  • @Raynos - Telling that the user is known, but the password is wrong, makes it indeed easier, because you can test other passwords with the same user. As long as you don't know the user exists, you have to guess user and password. – martinstoeckli Apr 16 '11 at 16:17
  • @martinstoeckli you can find out that users exist from other places of the website. – Raynos Apr 16 '11 at 16:19
  • @Raynos - Well there you are right, i should have read your first posts better. – martinstoeckli Apr 16 '11 at 16:23
1

Would it be nice to have a user be notified visually that their entered data is of the right format each time they login?

Yes, absolutely. It could save some server requests and make login much more faster cause user don't need wait for a server response if he entered wrong data and he could fix it without page reloading.

buryat
  • 384
  • 3
  • 8
1

Its not an overkill according to me. The faster you could provide a visual feedback that something is wrong the better it is.

uncaught_exceptions
  • 21,712
  • 4
  • 41
  • 48
1

In the end it's a question of taste but i would consider this: Entering the email address would display error hints until the user has finished entering his address completely (at least until he entered a valid domain). Error hints can make users unsure, you don't like it when the system tells you, you are making errors.

Speaking of myself, i like the freedom to type and correct my input without warnings. I would spare my error messages until the user wants to send the formular.

martinstoeckli
  • 23,430
  • 6
  • 56
  • 87
  • it's still better to have client side validation on the submit button to save the latency. The bottleneck in terms of validation feedback time is server-client latency. – Raynos Apr 16 '11 at 16:28
  • @Raynos - what i wanted to say is, that warnings on keyup are too much. With "until the user wants so send..." i meant the moment before sending, that's still on the client side. – martinstoeckli Apr 16 '11 at 16:32
1

IMHO it's overkill.

Secure sites generally have the same error message irrespective of the reason for login failure (user unknown or password invalid): this is on the principle that the less information you communicate to a hacker, the better.

In the same vein, why bother communicating to a hacker what formats you consider to be valid?

Of course such validation does make sense when a new user is registering, but I don't see what value it adds when logging in, since users can be presumed to know their username and password.

Joe
  • 122,218
  • 32
  • 205
  • 338
  • "In the same vein, why bother communicating to a hacker what formats you consider to be valid?" - The input-validation on my registration form already checks for a valid e-mail format and a password of at least 6 characters and notifies the user upon incorrect input. Presumably the hacker would want to check that out before blindly initiating a dictionary attack on the login form. – Kevin Apr 16 '11 at 16:43
  • @Kevin - sure that's true. But I'd still question what value you're adding by validating client-side on a login form, since the user presumably knows his credentials, and also because regex validation of an email address is hard: http://stackoverflow.com/questions/156430/regexp-recognition-of-email-address-hard – Joe Apr 16 '11 at 16:58