Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We have many restraints we put on users when they set up their password. These restraints include password length, characters they can or cannot use, the use of numbers and letters, capitalization requirements, etc. These are enforced so a password cannot be created unless all restraints are met.

On a form that requires a user to log in with their password, should we be intercepting the password the user has provided and check it against our original restraints the user was required to follow when creating the password before sending it to LDAP for authentication.

I personally say besides basic data sanitation (to prevent SQL injection attacks, etc.) that there is no reason to check what the user provides as a password to log in after they've already created it. If it doesn't match, authentication will fail. However, other individuals in my department feel that those restraints should be checked again before sending the username/password combination to authenticate.

Which way is better? Why?

share|improve this question
up vote 7 down vote accepted

I'd recommend against it. If you want to protect from injection attacks, there are other, fundamentally better ways (e.g. prepared statements for SQL injection or correct escaping for other channels), besides the potentially malicious password will probably pass your restriction filters anyway (after all, you probably enforce minimum, not maximum password length, allow for ' character etc.)

Like Tom Leek said, it adds unnecessary complexity. If you want to enforce password change due to new restrictions taking place, you need to do this after authentication anyway, so you could store the 'password isn't good anymore' flag in session, but the validity check should be an addition to authentication process and not be done before sending the password to LDAP.

share|improve this answer

Checking again an already registered password is useful IF the rules you want to enforce have changed AND you have the possibility to make the user change his password so that the new one complies with the new rules. Otherwise it is a waste of time, and added complexity (complexity is Bad).

share|improve this answer

should we be intercepting the password the user has provided and check it against our original restraints the user was required to follow when creating the password before sending it to LDAP for authentication.

To what end? This is one more feature to get wrong and leak information. How much benefit can this feature provide for how much it costs to get right, iron out bugs, and deal with unforeseen issues that lock out customers?

share|improve this answer

Well, I agree with the commenters, that a feature which you do not implement can not go wrong. If you let your LDAP server handle the password quality verification you have a single place to configure it, and you are sure it is enforced.

However there are two things to consider, first of all from a user experience point of view it is good if the (AJAX) password form actually gives direct feedback if the password is fine or not. So I would always implement some trivial checks to just have this feedback (password strength indicator with minimum level before you can submit it).

And secondly if you have an application which depends on a shared infrastructure the capabilities of the existing directory server might just not allow the level of checks you want to do (for example running extensive cracklib runs against a large dictionary). Or it might be the case that the directory administrators dont want/can consider your use case. In such a case the directory might just not have strong enough controls.

Good new: if you implement your own controls and the directory does have its own, and given that you actually use a correct protocol to set a new password (i.e. set it as the target user not as the admin) you can be sure that the stronger of both controls always will reject, so you cannot weaken the defense.

I would say if you program a COTS software which should be used in different context, offer some policies to restrict. If you are in a specific environment you might get away with basic UI feedback style of checks.

Note: I am not discussing the idea of password policies at all here, there are pros and cons. It is very important that you try to not at all restrict the maximum complexity (charset and length). This is not only a security feature but also useability (accept auto generated passwords which are common with password safes).

share|improve this answer

Your Answer


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.