Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

In registration form, I have client side validation for strength of password. For example password should be not less than 6 symbols, consists at least 1 digit, and at least 1 letter.

For example: hello1 and dk43do are valid passwords, but difmbfd and 3242354 are not.

Is it normal to make such a validation in auth (log in) form too? So, if user tries to log in, inputs a password, that is easy and can't be a password, it means - user had mistaken, so we should to tell him about it before he pressed Submit.

share|improve this question
    
Related: ux.stackexchange.com/questions/21665/… –  greenforest May 22 '12 at 7:54
    
+1 I see what you did there: you're trying to optimize your log-in process by offloading some processing to the client (i.e., Why should the server bother to validate a password that doesn't respect the mask you required when the user registered?). Not a bad idea at first glance, but the problem doing that is that you expose part of your password mask/validation process to the client (through your client-side validation script), and you probably never want to do that. –  msanford Oct 19 '12 at 14:11
    
@msanford, your password validity rules are already public knowledge. Anyone who has an account will have been told them. It's also a form of security by obscurity, which should never be relied on. Always assume an attacker has complete knowledge of the workings of your system, up to and including a copy of your password database (which is why they're stored with a one way hash function). You're quite right that client side checking isn't a good idea, but leaking your validity rules isn't really an issue. –  Peter Bagnall Oct 19 '12 at 21:52
    
@PeterBagnall Yeah, I over-thought that one a little. –  msanford Oct 22 '12 at 17:59
add comment

4 Answers

up vote 15 down vote accepted

First of all, you shouldn't require such convoluted & complicated passwords. Instead, you should simply put a password strength meter next to the password field and let users decide whether they want a strong password or a weak one.

Secondly, your system shouldn't have 2 different ways of dealing with wrong and/or invalid passwords. It should simply try to validate the already-invalid password as a login attempt because, otherwise, you might train your users to expect the warning of a wrong password without performing the submit action. Moreover, such a pattern doesn't improve anything in user experience: it doesn't alleviate any pain or simply a process.

share|improve this answer
1  
Thanks for explanation. Now I understand the problem in such an approach to authorization. –  Innuendo May 22 '12 at 4:27
add comment

Added to other answers, I'd like to highlight the fact than giving two distinct error messages (your password is not well formed / your password is wrong) can be a security issue: by providing some information, it helps hacker to know which kind of string they should use in order to find a user's password.

share|improve this answer
    
+1 And as I mention in my comment, you don't even need distinct error messages for this to be a problem: you're exposing the allowed password mask to a hacker if any client-side processing is happening because it's probably implemented in an interpreted scripting language (like JavaScript). –  msanford Oct 19 '12 at 14:15
add comment

As a user, I do not care that I entered a password that couldn't have been a password, I only care that I entered the wrong password. Giving the user an explanation for the former would be verbose and might be confusing. I would not go the extra mile to have that validation in the log in form.

share|improve this answer
1  
No, I don't want to explain that error. just to say password is wrong. (We haven't checked yet - wrong or not is it, but if password is invalid, then it can't be a password stored in database) –  Innuendo May 22 '12 at 4:09
    
Usually one doesn't say password is wrong because it might be the user id what is wrong, and because it's a hint for the bad guys (gee, I got an id!). Usually one says something generic like invalid credentials. –  Juan Lanus Oct 19 '12 at 19:19
add comment

You should not optimise testing passwords, quite the reverse. If you get the password wrong a small time penalty is no bad thing, since it slows down the rate at which you can try out passwords. Some unix systems will pause for a few seconds after you get your login password wrong to slow down any brute force attack.

The other reason not to do client side checking is that you want the server to know if people are getting the password wrong. That lets you log failures and warn the legitimate user that someone tried to get into their account. If you do client side checking you lose some of that valuable information.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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