8

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.

Improve this question
4
  • Related: ux.stackexchange.com/questions/21665/…
    – greenforest
    May 22, 2012 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, 2012 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, 2012 at 21:52
  • @PeterBagnall Yeah, I over-thought that one a little.
    – msanford
    Oct 22, 2012 at 17:59

4 Answers 4

Reset to default
18

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.

Improve this answer
2
  • 1
    Thanks for explanation. Now I understand the problem in such an approach to authorization.
    – Gray Bananas
    May 22, 2012 at 4:27
  • While I agree that convoluted password requirements are an antipattern, they are very widespread. Given this, I disagree with your statement "such a pattern doesn't improve anything in user experience": having a hint that this password must have an uppercase and two special characters would be very helpful when trying to remember which password was used.
    – Tamlyn
    May 25, 2022 at 8:45
4

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.

Improve this answer
2
  • 1
    +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, 2012 at 14:15
  • 1
    I'll let you in to a special hacker secret: to determine the current password requirements for a site, look at the sign up page.
    – Tamlyn
    May 25, 2022 at 8:49
2

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.

Improve this answer
1

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.

Improve this answer
2
  • 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)
    – Gray Bananas
    May 22, 2012 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, 2012 at 19:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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