Hi Bill,
I've reworked your original expression; the most evident error is the
abuse of the [class]{n,m} pattern, which tries to match n consecutive
(that is: not randomly placed) instances of any of the characters of the
class.
Here's what I come up with:
(?=.*[A-Z]+.*[A-Z]+) # At least 2 uppercase characters
(?=.*[a-z]+.*[a-z]+) # At least 2 lowercase characters
(?=.*[0-9]+.*[0-9]+) # At least 2 digits
([EMAIL PROTECTED]&\*_\-+=':;,[EMAIL PROTECTED]&\*_\-+=':;,\.]+) # At least 2
special characters
^.{10,25}$ # 10 to 25 characters
As you could see, I've also overworked the last expression to get back
its capture (instead of adding another .*$ expression just to achieve
the same result).
Hope this helps.
--
Efran Cobisi
http://www.cobisi.com
Bill Bassler wrote:
I've been looking at the use of both client side RegularExpression
validators and for the server overriding OnValidatingPassword Membership
provider method to ensure adherence to a strong password format consisting
of:
-10-25 Characters.
Two or more of the special characters ! @ # $ % ^ & * _ - +
= ' : ; , .
-Two or more Uppercase Letters
-Two or more Lowercase Letters
-Two or more Numbers.
This is what I have so far (?=^.{10,})(?=.*[A-Z]{2,})(?=.*[a-z]{2,})(?=.*
[0-9]{2,})(?=(.*\W){1,})(?!.*\s).*$
The main issue I'm having are the requirements for 2 or more of a type of
character for a match. The use of quantifiers {2,} appear to only match 2
successive character types, for example uppercase characters. MU46_!28gs
is a match but not Mu46_28Gs! is not. However, both should be valid
matches.
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
