17 replies to this topic

[MalzoneExpress]

Hi SOSH,

My email vendor is implementing new password requirements. I manage all the email set-up/changes for my users via APIs. So when users change their email password on my site, I have to make sure they meet the requirements before sending the change to the API. I will check each of their requirements separately in code after the user submits their new password, but it would be nice if I could use a regular expression on the web page to notify them of a problem before sending the information to the server. I admit to being less than proficient in regular expressions, so I was wondering if SOSH might have a guru or two who could help me. The criteria are:

• At least eight characters in length
• No more than 20 characters in length
• Contain at least one number [0-9] character
• Contain at least one special character from: !@#$%^&*()~`-=_+[]\{}|:";',./<>?
• Contain at least one upper-case and lower-case letter

Thanks for any help.

[FL4WL3SS]

^.*(?=.{8,20})(?=.*\d)(?=.*[a-z])(?=.*[A-Z])(?=.*[!@#$%^&*()~`-=_+[]\{}|:";',./<>?]).*$

[GreenMonster49]

From this site, I modified the proferred regexp to get the following, which seems to work:

((?=.*\d)(?=.*[a-z])(?=.*[A-Z])(?=.*[!@#\$%\^&\*\(\)~`\-=_\+\[\]\\\{\}\|:";',\./<>\?]).{8,20})

But I'm not an expert, and there is probably a much more elgant way to do this.

[MalzoneExpress]

Thanks guys. I'll test and let you know how it goes.

[FL4WL3SS]

GreenMonster's will work - I just realized I didn't escape all of the special characters.

[cgori]

Depending on the language you use to do this, be careful with your input sanitization or how you use the password in the code.

(those special characters can do nasty things / have unintended side effects, e.g.

[FL4WL3SS]

That's fantastic.

EDIT: I agree -- personally I'd limit the special characters that are required or drop that requirement all together.

Edited by FL4WL3SS, 27 March 2012 - 12:08 PM.

[InstantKarmma]

Agree with the above re: special characters. I would limit it to 4-6 more innocuous choices, such as @#$%&. Allowing -, <, > and others can get you in trouble.

[MalzoneExpress]

Yes, the unintended consequences of special characters is the reason I parameterize all my database calls. No one likes to be the victim of a SQL Injection.

[MalzoneExpress]

Agree with the above re: special characters. I would limit it to 4-6 more innocuous choices, such as @#$%&. Allowing -, <, > and others can get you in trouble.

You bring up a good point. And just because my email vendor allows all those special characters doesn't mean I have to on my end.

[SumnerH]

But I'm not an expert, and there is probably a much more elgant way to do this.

I'd use multiple lines of javascript, and test conditions separately, just to make it more readable and maintainable.


"Some people, when confronted with a problem, think 'I know, I'll use regular expressions.' Now they have two problems."--JWZ, a bit tongue-in-cheekly.

That overstates things, but usually the use of the lookahead operator "(?" is a good sign that you're no longer in the land of problems that regexes are an elegant solution to. In fact, an expression that requires lookahead is not actually regular. Its inclusion in regex libraries is often considered a big mistake (thanks, Perl 5!).

[FL4WL3SS]

I'd use multiple lines of javascript, and test conditions separately, just to make it more readable and maintainable.


"Some people, when confronted with a problem, think 'I know, I'll use regular expressions.' Now they have two problems."--JWZ, a bit tongue-in-cheekly.

That overstates things, but usually the use of the lookahead operator "(?" is a good sign that you're no longer in the land of problems that regexes are an elegant solution to. In fact, an expression that requires lookahead is not actually regular. Its inclusion in regex libraries is often considered a big mistake (thanks, Perl 5!).

Ultimately, I'd have to agree with this. The regex isn't going to save your users any noticeable time and this will be much easier to maintain, especially if someone other than you needs to maintain it.

[MainerInExile]

I'd use multiple lines of javascript, and test conditions separately, just to make it more readable and maintainable.

I was thinking the exact same thing. In addition, you can use JS to encrypt BEFORE sending to the server, so that you don't have to send an unencrypted password over the wire.

[HillysLastWalk]

Testing each condition separately: +1

Although, if you just want to get better at using regular expressions and you write it in a clear (heavily commented) manner - go for it. For example, placing the regex all on one line (from the examples I see) - FAIL!

I tend to agree with this: http://www.codinghor...o-problems.html

PS. The article actually clarifies Jamie's quote too.

[SumnerH]

I was thinking the exact same thing. In addition, you can use JS to encrypt BEFORE sending to the server, so that you don't have to send an unencrypted password over the wire.

I'd definitely use SSL and not attempt to reinvent the wheel, badly, in JavaScript, on the encryption side of things (e.g. problem 1: how are you exchanging the key between the client and server? Is it secure against a man-in-the-middle attack?)

If you're worried about server overhead you can have just your login pages in SSL, but there's very little reason not to just encrypt everything that requires a login these days. The big exception is if you're hosting video or other large files (though even there it may not be worth the effort to turn off SSL for them--obviously it depends on your traffic patterns and server), but it's generally best to think of it as "what do I need to turn SSL off for?" rather than vice-versa.

[uncannymanny]

I'd also make sure you're covered if the browser has JS turned off of course

[MainerInExile]

I'd definitely use SSL and not attempt to reinvent the wheel, badly, in JavaScript, on the encryption side of things (e.g. problem 1: how are you exchanging the key between the client and server? Is it secure against a man-in-the-middle attack?)

If you're worried about server overhead you can have just your login pages in SSL, but there's very little reason not to just encrypt everything that requires a login these days. The big exception is if you're hosting video or other large files (though even there it may not be worth the effort to turn off SSL for them--obviously it depends on your traffic patterns and server), but it's generally best to think of it as "what do I need to turn SSL off for?" rather than vice-versa.

You're right, of course. I was assuming his application is on an internal network (it's email or something), where you often don't use SSL (because you don't want to pay for certificates). But you still may not want to send plain text passwords, so a quick SHA1 on the client itself can do the trick.

[MalzoneExpress]

Thanks to everyone for their input and suggestions. I think I have taken the best of the suggestions and applied them. I limited the special character I accept to avoid the more dangerous ones. I use a regular expression to validate the input on the client side. I test each condition separately on the server side for better validation and in case someone has JavaScript turned off. This method seems to work well. Thanks again. This is another example why SOSH is such a special place.