Password RegEx Check

I'm trying to use RegEx to validate the password strength for a Cisco UCS password. Due to the complexity requirements I'm having a bit more trouble than I expected. This is what's expected:

 If you enable the password strength check for locally authenticated users, Cisco UCS Manager rejects any password that does not meet the following requirements:

 Must contain a minimum of 8 characters and a maximum of 64 characters.
 Must contain at least three of the following:
 1) Lower case letters
 2) Upper case letters
 3) Digits
 4) Special characters
 Must not contain a character that is repeated more than 3 times consecutively, such as aaabbb.
 Must not be identical to the username or the reverse of the username.
 Must pass a password dictionary check. For example, the password must not be based on a standard dictionary word.
 Must not contain the following symbols: $ (dollar sign), ? (question mark), and = (equals sign).
 Should not be blank for local user and admin accounts.

That comes from this documentation and and help is greatly appreciated.
Thanks

Adam

January 26th, 2015 1:32pm

Hi Adam,

question: Is RegEx a solid requirement?
I'd just validate it step by step. That's a lot simpler and reading (and fixing) it afterwards as a lot simpler.

  • Checking Length is laughably easy
  • You can do 1-4 by creating a counter and increment it for each test passed.
  • consecutive repetitions will probably need you to iterate over the string, but shouldn't be that complex.
  • Comparing with username is another simple one.
  • Dictionary is a bit more of a challenge (and forget about doing that in regex). Maybe some library for it? Or somehow hijack Word Spellchecker for it.
  • Forbidden symbols/letters are simple to detect, shouldn't be a problem.

Cheers,
Fred

Free Windows Admin Tool Kit Click here and download it now
January 26th, 2015 1:46pm

Thanks Fred. RegEx isn't a requirement but I thought it'd be easier and maybe I was missing something. Dictionary means having something like :[hg]})!P455_678{ds(^%jkl as a password would be considered dictionary based and disallowed. I might just put some text before the user enters the password so they know what to enter.
  • Edited by Adam-M Monday, January 26, 2015 10:55 AM
January 26th, 2015 1:54pm

You should print an explanation anyway - users tend to get unhappy - fast - if they enter something that appears "good enough" for them but results in an error.

In my opinion, RegEx is rarely easier (especially when someone else is trying to read it afterwards), though it often is shorter than some of the alternatives.

From a personal point of view, my boss doesn't tax me by the number of lines I produce, but he does hammer me if my code can't be understood by a non-scripting admin (they don't need to understand the "why"s, but they sure as hell have to understand what it will do).

Free Windows Admin Tool Kit Click here and download it now
January 26th, 2015 2:27pm

My bosses don't even look at the code - they just want me to make something shiny that works when they want it. Tis a lonesome life.
January 26th, 2015 2:46pm

The dictionary check is tricky to implement (for performance reasons), and also pointless.  As it turns out, this:  "[hg]})!P455_678{ds(^%jkl" is a much easier password to crack than this:  "hobbit horse sandwich truck birthday monster" .  A single dictionary word is bad, but a long passphrase is easier to remember and harder to crack than a shorter string of gibberish.  (You can, and should, still incorporate some numbers or symbols in an easy to remember way, of course; this is just demonstrating that some of those rules are silly.)

Free Windows Admin Tool Kit Click here and download it now
February 8th, 2015 10:34am

Hi Admin-M,

To check password complexity, this script maybe helpful for you to start:

Validating password strength

I recommend you can post your current script and issue for a better response.

If there is anything else regarding this issue, please feel free to post back.

Best Regards,

Anna Wang

February 8th, 2015 12:14pm

How is this script going to be run, by whom, and what else will it do?

Passwords are generally used for security and authentication purposes. If you provide a script for someone else to run to create a new account with a password that meets the password complexity policy in effect (if that is the intention), who is to say that your script will not save that information for some nefarious purpose?

No, I am not suggesting you would do this. But it should be considered poor practice to encourage users to run programs and scripts into which they enter actual production passwords, because not all programs and scripts will be as ethical as yours.

Also, a system that validates a password according to the published rules may not always agree with the underlying code of the target system. For example, if your script rules out all words in its dictionary, a validated password could be rejected because that word exists in the dictionary used by UCS.

My recommendation is to trying to duplicate this logic, and rely on the logic built in to UCS. If users find that too unfriendly, you could submit a change request to Cisco.

Free Windows Admin Tool Kit Click here and download it now
February 8th, 2015 8:04pm

The dictionary check is tricky to implement (for performance reasons), and also pointless.  As it turns out, this:  "[hg]})!P455_678{ds(^%jkl" is a much easier password to crack than this:  "hobbit horse sandwich truck birthday monster" .  A single dictionary word is bad, but a long passphrase is easier to remember and harder to crack than a shorter string of gibberish.  (You can, and should, still incorporate some numbers or symbols in an easy to remember way, of course; this is just demonstrating that some of those rules are silly.)

the trouble is that it might be impossible for your hobbit password (or a shorter equivalent) to be used with UCS. the OP is not looking for information about what makes a password actually hard to crack, but how to pre-validate a proposed password to be used with UCS.

February 8th, 2015 8:30pm

I've decided to abandon the password verification now in favour of a brief note explaining the Cisco password requirements. I understand what's being said about the dangers of entering production passwords into a potentially malicious script, but this is required because the script is ran as a GUI and proceeds to then create an account in UCS Manager using the credentials. Does the same thing for VMware but it just adds the currently logged in user to the vCenter. It's for internal use currently. I might just recommend to keep it this way.

Thanks for the advice though everyone.

Free Windows Admin Tool Kit Click here and download it now
February 9th, 2015 3:56am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics