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.