PCRE regex question for pw

[tork]

I'm building a regex for password control. I'm trying to have the passwords have at least: 1 small letter, 1 capital letter, 1 number, and 1 special character, while having between 8 and 20 characters inclusive. All seems to work up to this point in testing, however, the 20 limit seems to work except that when I compare the 21 (or more) first password with the comparison password entered by the user, they are interpreted as being different when in fact they were entered the same.  Any ideas?

 

#.*^(?=.{8,10})(?=.*[a-z])(?=.*[A-Z])(?=.*[0-9])(?=.*\W).*$#

[.josh]

In general, regex for what you described should be:

 

#^(?=.*[a-z])(?=.*[A-Z])(?=.*[0-9])(?=.*[^a-zA-Z0-9]).{8,20}$#

 

 

But I'm not quite sure I understand what you mean by this:

 

the 20 limit seems to work except that when I compare the 21 (or more) first password with the comparison password entered by the user, they are interpreted as being different when in fact they were entered the same.

But IMO, a more user-friendly approach would be to check each thing individually and return an error message for where specifically the user actually went wrong. Actually, I hate it when places try to enforce a password format on me to begin with. First off, it's annoying. 2nd, it's a double-edged sword. You may think you are making them pick a "stronger" password, but in reality, your form is telling crackers how to narrow down possibilities of password combinations to try. IMO it would be better to show a "strength" meter and/or offer suggested formats for a "strong" password, but don't actually enforce a format.

[tork]

Thanks .josh. I agree in principle. My challenge is that an attack on the database will have extreme consequences should user's data get to the marketplace. I'm wide open to any ideas as to how to keep other users' data safe from a lazy pw user (and I don't mean people who don't like constraints, but people who just throw in a name they know). I am already using a number of techniques to prevent attacks throughout the site. Basically, I'm down to password control now. BTW, I hear you; I too like to control my own password structures with the sites I'm on. Where's the balance?

[objnoob]

Actually, I hate it when places try to enforce a password format on me to begin with. First off, it's annoying. 2nd, it's a double-edged sword. You may think you are making them pick a "stronger" password, but in reality, your form is telling crackers how to narrow down possibilities of password combinations to try.

Not quite. If you allow weak passwords, you increase the chance the passwords can

be cracked that much faster. The reason you enforce minimums in passwords is to increase the uniqueness of passwords. This really does makes it harder to guess / crack.

 

The only problem with unnatural passwords is users are more likely to write them down because boBbYjojO1!woahwoah is ridiculous to remember right away :] Add password aging into the mix and now you're just promoting users to write down their passwords.

Edited November 26, 2013 by objnoob

[.josh]

@objnoob: well this is why i said it's a double edged sword. I agree that with no enforcement, if a user selects a super simple password, like a regular word in the dictionary like "something", it's probably going to get cracked really fast, since most sophisticated crackers will "check the obvious" first when it comes to brute forcing. But on the other hand, if the cracker knows for example it must contain at least 1 number, it can rule out all combinations involving no numbers. And if it knows pw has to be a certain length, that's even more combinations to throw out. Also, the amount of non-number strings in 8-20 length string is far larger than a standard dictionary lookup list. And that's just the "at least 1 number" equating to "rule out strings with no numbers" part of the possibilities. IOW by enforcing a pattern, you're ruling out more of what it can't be, than what it can be.

 

 

Where's the balance?

I personally usually go for enforcing a length (like the 8-20), and I also check if the pw contains or equals other form fields they enter in (e.g. I reject if he enters his name as John Doe and pw is something like "Johniscool" or "JohnDoe123"), and that's it. Depending on sensitivity of data, I might throw in mandatory pw resets every x amount of time.

[objnoob]

@objnoob: well this is why i said it's a double edged sword. I agree that with no enforcement, if a user selects a super simple password, like a regular word in the dictionary like "something", it's probably going to get cracked really fast, since most sophisticated crackers will "check the obvious" first when it comes to brute forcing. But on the other hand, if the cracker knows for example it must contain at least 1 number, it can rule out all combinations involving no numbers. And if it knows pw has to be a certain length, that's even more combinations to throw out. Also, the amount of non-number strings in 8-20 length string is far larger than a standard dictionary lookup list. And that's just the "at least 1 number" equating to "rule out strings with no numbers" part of the possibilities. IOW by enforcing a pattern, you're ruling out more of what it can't be, than what it can be.

 

 

 

I personally usually go for enforcing a length (like the 8-20), and I also check if the pw contains or equals other form fields they enter in (e.g. I reject if he enters his name as John Doe and pw is something like "Johniscool" or "JohnDoe123"), and that's it. Depending on sensitivity of data, I might throw in mandatory pw resets every x amount of time.

[Psycho]

I think a maximum of 20 is way too short. A longer length will allow pass phrases such as "I live in a green house" which add much more complexity yet are easier to remember.

Edited November 26, 2013 by Psycho

[objnoob]

Too late to edit my quote of you .josh, So here it is:

 

throw out ABC, yes it's too simple, but now your forced to check for ABC1, ABC2, ABC3, .... 3ABC, 1ABC, etc, etc. This adds more unique possible combinations and eliminates common passwords such as fido.

Make those cracker jackers work harder for what they want. Anyhow, If you don't require a digit, most users won't use 1, most will be cracked by the crackers common password list in minutes, and ABC would be bruted in notime (if not on common list)

 

I will say some websites go overbroard on password requirements. Ask yourself how topscret  your applicaiton is, and design your password requirements around that,

[objnoob]

And when it comes to passwords, before you hash it and bounce it off of the database server.... check the length    

 

 

if(($len=strlen($pass)) >= x && $len <= y){

             // meets the length requirement, hash this password and use to look if  password is right!

             // with security flaws in MD5 allow two unique values to hash into a single conflicting value.

             // checking the length of the password would limit the size of the data your hashing and lessen any the chance of a conflict.

 

 

 

}else{ 

              echo 'Always echo generic login error:   Sorry your username and/or password are wrong!';

}

Edited November 26, 2013 by objnoob