5

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?

7

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.

8

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).

2

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?

0

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).

0

Password cannot be created unless all restraints are met.

The constraints you mentioned are recommended. Just to recap.

  • Minimum password length
  • Permissible characters
  • Both numbers and letters
  • Minimum mixture of alpha character case

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[?]

Which way is better? Why?

In the first question you implied (but did not explicitly state) that you would retain the original LDAP entry creation constraints (above) and then asked, "Which way?" I think that second question may have confused people trying to answer well. I'm going to assume your department is NOT thinking of REPLACING the original check but rather to duplicate it earlier in the data flow between the keyboard and the LDAP lookup.

There is no reason to check what the user provides as a password to log in after they've already created it.

Not for security. The secret in the LDAP is at neither greater nor lesser long term risk if constraints are checked earlier on. Furthermore, you are not increasing or decreasing the strength of the LDAP security by checking sooner. All the long term probabilities are untouched.

Notice I kept saying, "Long term." The speed of a brute force attack might be increased by adding the additional check because negative responses may return more quickly with an earlier check. The valid permutation space (constraint set) could be determined more quickly by a smart attacker if the negative response returns more quickly.

On the other side, attackers may have plenty of time anyway. Also, your department could add a constraint failure response delay if they chose.

Other individuals in my department feel that those restraints should be checked again before sending the username/password combination to authenticate.

To side with the other individuals for a moment, there may be value to the user if mistyped password entries are detected sooner. No one likes to wait 10 seconds during high volume times only to find out some unspecified wrong key was pressed.

There may be value to the network, the LDAP server, and lower tiers in the system during high loading periods if mistypings were caught earlier. I doubt the improvement would be significant enough to warrant the addition.

Personally, I would not add the extra check because I think it is more probable to reduce security than to increase it, and it adds a maintenance operation. Every time the constraints are changed in the LDAP server, the constraints would need to be changed in the earlier check. Adding some automation to prevent that need would be another system component that would need to be maintained. It's not a great idea.

There is no compelling need to argue against the addition if a consensus is forming in the department provided

  • The original LDAP constraints are left in place,

  • The password constraint set is conservative enough so that brute force attacks are unrealistic even if the attacker learns of the constraints,

  • And you are not personally saddled with the responsibility of keeping the new constraint check working and perfectly aligned with the LDAP server constraints.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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