set restrictions on placement of numbers
deekayen - October 3, 2008 - 16:38
| Project: | Password policy |
| Version: | 6.x-1.x-dev |
| Component: | Miscellaneous |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Description
Example:
With only 1 numeric character in the password, the string should not contain the digit in the first or last position of the string (e.g. 2abcdefg and abcdefg4 are unacceptable passwords, while 2qpcxrm3 and 99qpcxrm are allowed passwords).
#1
#2
Out of curiosity, where does this rule come from? I never saw such a requirement.
#3
It forces the user to add a bit more entropy to the password. It basically prevents a user from updating passwords with a single incrementing digit like
#4
Is this really efficient? If I would see such a policy, I could start changing my password like:
pass1word
pass2word
pass3word
and so on. So it prevents increasing the number at the beginning and the end of the password, but it does allow to increase the number in the middle. Does it really add entropy then?
#5
I hadn't heard of it easier until fairly recently. It's a requirement from some of our enterprise customers.
The idea is that if you have the login_security module set a max number of failed logins before blocking the account, you only have a limited number of places you can try the digit before the account is blocked. The easiest and most common place to put the digits and therefore the easiest to brute force them is at the beginning and end, so even in your example if you force them to put a single digit in the middle, you have to guess in which place the digit has been placed before the account gets blocked. It's additional complexity in terms of predicting human nature in password creation and as a result, I would make the case that pass1word is more secure than password1 merely because of where I would expect someone to add a digit if I were trying to brute force guess a password.
It's an additional option that didn't come from me, other businesses are asking for it, and if people don't want to use it, then don't configure it. Do I need to write a 6.x equivalent constraint file to grease this into CVS?
#6
All new constraints I will add to the D5 branch I will also port and add to the D6 branch to make sure a smooth transition is preserved. If you could port the constraints to D6 it would for sure speed up the process.
#7
#8
Could we get rid of the hardcoded max digits number (10), or there is same requirement behind that?
#9
#10
That's not a max digit counter, that's a counter of the number of each kind of digit. It is 10 because there is one of each digit 0-9. It's a way of counting all the numerical digits in the password string to see if it meets the number of digits required by the constraint.
#11
Indeed, my fault. I should have looked more concentrated. My eyes went up to cycle, saw upper limit 10 and then stopped :)
maybe something like
$matches = array();preg_match_all('/(\d)/', $password, $matches);
if (count($matches[0]) < (int)$constraint) {
would be more readable?
Anyway, I'm going to commit your code as functionality is there.
#12
I have committed to the 5.x branch. Speaking about 6.x. version, could you add a _js() function which would add a javascript code to assert the user when he chooses not strong enough password?
In D6 branch each php password strength check function has it's twin javascript function (when applicable) to alert a user before he submit his new password.
#13
I wrote the JS and some simpletests for this new feature and committed it for 6.x-1.0-ALPHA2
#14
Automatically closed -- issue fixed for 2 weeks with no activity.