On 02/01/2012 20:27, Jones, Barry wrote:
Specifically, I need to enforce the use of length, special characters, and be able to validate the enforcement of such.
I always like to look at policies like this from an analytical point of view. Let's take a look at some numbers. Let's say that you insist on mixed case, numbers, punctuation, 8 characters. I find anything more than 8 characters really difficult to remember; probably lots of other people too, which is why they all write them down on post-it notes if they're longer - and then stick them to their monitors. This creates a pool of 26 + 26 + 10 + 10 = 72 possible characters. So in theory you're talking about a pool of 72^8 = 7.2*10^15 possibly passwords. Thing is, your password policy insists on punctuation, which means that your actual password pool is now 10*72^7. i.e. one character is pulled from the pool of 10 punctuation chars, and the rest are anything at all. And if you insist on at least one number + one item of punctuation, it's 10*10*72^6 - same reasoning. But really, you're also insisting that you use at least one upper case + one lower case letter, which means that your password pool becomes 10(punctuation)*10(number)*26(upper case)*26(lower case)*72^4 = 1.8*10^13. In other words, by enforcing a strict password policy on your users, you've just reduced your potential password pool size by a factor of 400, which means that your password is 400 times easier to brute-force. The next step in this process is to take a look around at the current capabilities of GPU based hash generators. E.g. whitepixel currently claims to be able to handle 3.3*10^11 md5 hashes per second (unsalted) on a computer with a very small capital outlay. If for some odd reason you were storing your passwords as unsalted md5 hashes, your entire password set would be cracked within about 1 minute. But real life is different; we don't use md5, we do use salt, and we don't choose stupid password policies. Oh but wait, we do. So the real question you need to ask yourself is this: "what is the intention of my password policy?" Is it to create a sequence of characters which is effectively impossible to brute-force? Or is it to create a sequence of hieroglyphics which your users will find difficult to remember and will cause them to grind their teeth in anger every time they are forced to type it in? At best, these hieroglyphics provide an elevated sense of security. At worst, they are a mockery of actual security. My favourite choice is "Pa$$w0rd". It scores top marks on pretty much all password strength checkers that I've ever tried it on. And every time the policy requires a change, I prepend a digit which apparently makes it secure for another 6 months. If you are more interested in creating passwords which are difficult to brute force and easier to remember, one useful approach is to take a list of a couple of thousand short-ish words, and to use a random list of five or six of these words for a password. Much easier for people to remember; gets around silly mistakes with typos; and there's no requirement for mixed case, punctuation and all those other silly things which look great on paper but serve only to confuse and annoy. Nick