8 ms·

"Applications should enforce password complexity rules to discourage easy to guess passwords." - ARGH! To clarify, to avoid downvotes for a non-'productive' co

"Applications should enforce password complexity rules to discourage easy to guess passwords." - ARGH! To clarify, to avoid downvotes for a non-'productive' comment, I firmly disagree since this will probably result in me having to pick a password that's harder to remember than I otherwise would. It might also might it more awkward to type quickly, making shoulder-surfing easier. (Note that this is probably not i18n-friendly, either)

x1798DE 12y ago
While in some ways I agree that these password rules enforcements are not ideal (they are hardly scientific, they seem much more "common sense" to me), I think making you use a harder-to-remember password is part of the point. The current received wisdom on passwords is that if it's easy to remember, it's easy to guess. That said, I'm not crazy about the inherent paternalism of this sort of thing. I think allowing weak passwords with a warning is, in most instances (not including corporate IT and situations where you're requiring that the user protect your private information rather than their own), a preferred way to go. Informing people when they are making a weak password should at the very least let them make a choice about how much they care about their own security.
wglb 12y ago
It is more palatable if the rules provide for phrases, say 20 characters or longer. Then you can do a few substitutions for word separators and the like. And yes, I agree that it is seriously annoying.
bradleyjg 12y ago
It depends on your threat model of course, but in most situations an attacker that is physically near you is less concerning than an attacker that can be anywhere in the world. In most cases I'd rather you had a twelve character random string written on a post it attached to your monitor than the password "password" not written down anywhere.
paulojreis 12y ago
At my company this typically results in users printing or writing the password down. I wonder if the guys who create these heuristics/recommendations ever had contact with humans. I believe that their research is thorough in their area of expertise (info sec), however, it sounds like they are only considering data per se, ignoring human behavior variables. There's little value in enforcing hard-to-break passwords while also encouraging users to write them down. What I believe: Info sec researchers should team up with HCI people.
- tinco 12y ago
  There's not much wrong with writing passwords down. Printing thema is less desirable. It's a hundred times better to have a difficult password on a post-it on a monitor than it is to have an easily guessable password. Who do you suspect is going to hack you? Ask that question honestly and you'll know how best to thwart them.
  - hackuser 12y ago
    > It's a hundred times better to have a difficult password on a post-it on a monitor than it is to have an easily guessable password. Who do you suspect is going to hack you? It depends on the threats you face. Generally, most attacks are from insiders.
  - noamyoungerm 12y ago
    > Who do you suspect is going to hack you? According to my experience: 1. People I know in real life 2. People who execute phishing attacks Your strategy is harmful in the first case, though irrelevant in the second
  - paulojreis 12y ago
    I understand your point, and I agree that the biggest threats aren't physically nearby. In that scenario ("remote" attacks), of course, there are bigger problems than written/printed passwords. However, at the enterprise level, physically visible passwords are a big problem. Imagine a less-than-happy worker, about to leave the company, having the opportunity to get coworkers passwords. In such scenario, less strict rules (let's say, rules that didn't make people writing the passwords down) would have been beneficial. And there's another point: the "perception" about IT security rules. If they ask too much of people (think "non-IT people"), they might create a image of overzealousness/"overcomplication". I wonder if this doesn't make people less compliant, with security rules, on the long term.
ssharp 12y ago
I think context is important. If it's a bank password, I don't mind coming up with something complex. If it's for something that requires me to have an account, but I don't care at all whether or not someone else gains access to the account, I have no problem using a much simpler password and would be rather annoyed if I had to do something more complex.
- IgorPartola 12y ago
  Then you might as well do the RMS thing and set your password to be blank :). Passwords are currently a necessary evil. My hope is that we will ditch them sooner or later. For now, use a password manager to prevent really bad things that will result from what you are doing.
M4v3R 12y ago
I agree on that as well. Enforced - NO (only minimum length should be enforced imho). Encouraged - Yes. Just show a good password strength meter to the user and fine-tune it to your security requirements. If you enforce all kinds of weird password rules to the user, he will have to write the password down somewhere, because one couldn't possible remember all passwords. And for non-technical users that means some random pieces of paper or post-it notes. On the other hand, encouraging them to come up with something that is strong makes it more likely that they will invent a password that they can remember, thus making it more secure.
- sarciszewski 12y ago
  "Just show a good password strength meter to the user and fine-tune it to your security requirements." That's the approach I follow in my projects. I offer a Javascript (window.crypto powered) Diceware passphrase generator and use zxcvbn to let users know the relative strength of the password they've supplied. I've also been planning an experiment to see if the width of a password field results in users choosing longer passwords, because more empty space. :)
- AceJohnny2 12y ago
  > If you enforce all kinds of weird password rules to the user, he will have to write the password down somewhere, because one couldn't possible remember all passwords. I'm going to use the appeal to authority argument, and bring over Schneier to argue that writing your passwords down isn't bad: https://www.schneier.com/blog/archives/2005/06/write_down_your.html https://www.schneier.com/blog/archives/2005/06/write_down_yo... (and others posts since, google "schneier writing passwords down" or something) Remembering your password isn't necessarily more secure, especially since it easily leads to password re-use, which is even worse.
DoggettCK 12y ago
Having recently had to implement improved password security for a customer who wouldn't read XKCD #936, the internationalization thing was a pain in the ass. They wanted at least 10 characters, and at least one uppercase, one lower, one digit, and one special character. Easy enough with .NET's built-in membership stuff by setting: passwordStrengthRegularExpression="(?=.{10,})(?=(.\p{Lu}){1,})(?=(.\d){1,})(?=(.*\W){1,})" The "\p{Lu}" part handles uppercase characters even in Unicode chars, but Javascript has no equivalent, so I couldn't do client-side validation of that. Should be validating on both ends anyway, but it's still a pain. The real part I hated was having to keep track of users' last N passwords to make sure they didn't re-use them. Since everything's hashed and salted, I just kept a table of previous hashes by user. Seems simple, but MS didn't see fit to include a HashPassword(string plainTextPassword, byte[] userSalt) method in the membership provider, so I had to reverse engineer their password-hashing method to check when they change passwords if it's something that's been used before. Then I realized that they could just change their password N+1 times in about a minute, then re-use their expired password anyway, so we wound up having to set a minimum age of N weeks before a password could be reused as well. The whole problem is an exploding requirements nightmare that could easily be solved by saying "Must be >32 characters and don't write it down anywhere, idiot." The worst part is as much as I hate these types of requirements, I now perfectly understand why these systems are the way that they are.
- bkoehler 12y ago
  How did you handle password++ iteration? For example P@ssword01, P@ssword02, P@ssword03 hash differently.
  - spydum 12y ago
    I would guess that it didn't.. just another example of the exploding requirements.
    - wernercd 12y ago
      How do you handle (Do you?): * not more than 2 identical characters in a row (e.g., 111 not allowed) * Name/Username in password (Name: Chuck Norris, username: ChuckNorris, Password: ChuckNorris#1) These are reasons why I don't look forward to doing this and also why I'm leaning towards G+/FB/twitter/etc authentication in an app I'm planning.
matthewmacleod 12y ago
I see your point, but given the number of 'test', 'password' and '12345' passwords we see whenever there's a leak, that could be an issue. Maybe just a minimum length? I too get annoyed when there are specific complexity requirements, like 'must include an uppercase letter' even though I've used a 20-character long password including numbers and punctuation.
- mtviewdave 12y ago
  If the problem is that people are using "password" as a password, why not just ban that example specifically? So you can't use "password", but you can use "djwipvbs". Assuming you're using bcrypt with an appropriate work factor, wouldn't "djwipvbs" be an acceptable password? More generally, you could ban the top X passwords from those "most frequently use password" lists.
- coldpie 12y ago
  Consider the sources of those leaks. They're usually from places like adobe.com, where my own password is 1234 because I just had to make an account to download some trial software or whatever.
- tracker1 12y ago
  The worst for me is when there is a strong complexity requirement, but some other stupid limitation, like only specific special characters can be used. I usually result to something like "ThisIsBullshit!1" or something similar (though I started using lastpass, also 2fa where available) I did come across a site that had a cuss word filter, then wouldn't let me change my password... lol. No mention of why it was an invalid password. If you must have certain complexity requirements, spell them out. Personally, if it's over 8-10 characters (with leading and trailing whitespace trimmed off), I'll take anything... convert to UTF8 bytes before 1-way hashing... As for using SCrypt, if it takes a modern CPU 1/2 second on a process to hash a password, then that's ripe for a DDOS against your authentication server, which is where failed attempt counts, and locking for X minutes comes in.
robert_tweed 12y ago
No link handy but I'm sure someone recently wrote an open source effective entropy calculator, which avoids either enforcing stupid entropy-reducing, complexity-increasing rule sets, while also preventing anyone using stupidly easy to guess passwords. Others do things like check against a normalised dictionary (i.e., I, 1 or L are all considered the same character). I really don't know why in this day and age of complex software with libraries for even trivial functionality, this practise isn't more widespread. People are still writing dumb complexity rules like it's 1980. This should really be the new "don't do your own crypto".
- VLM 12y ago
  "This should really be the new "don't do your own crypto"." oauth / openid for the win Unless your companies "secret sauce" is user authentication and management, you probably shouldn't be doing it.
  - bradleyjg 12y ago
    You still almost certainly need to implement a backup system. It is rarely a good idea to force a new user to enter his facebook/google/ms credentials to use your service. Even if 99% of your potential userbase has such credentials they may not want to connect them to your service. That's even before getting into the question about whether or not such systems make it more likely that users will fall to phishing attacks by conditioning them to enter their credentials somewhere other than the website where they were issued that they went to directly.
  - elithrar 12y ago
    Using OAuth also doesn't give you a free pass. Plenty of apps/sites/organizations mess up OAuth implementation, and OAuth doesn't solve things for corporate/enterprise users either. It's also not suitable for certain demographics, which puts you back at square one (rolling your own).
- nothrabannosir 12y ago
  This is a step in the right direction, but down a dead end. Like trying to reach the moon by climbing up a tree. Taking a step back, what we are doing is essentially: you may choose your own password! But, not really. We are going to tell you what not to. After you try it. And it's not a human, or equivalent AI: it's a (dumb) algorithm. If you are going to let someone choose a password, ask yourself: why? Is convenience that much more important than security? Putting, what many people will perceive as, onerous constraints on the passwords greatly reduces that convenience. But users will still try to make it as low entropy as possible, so security suffers, nonetheless. Or is security so important, to hell with convenience? Then why not just generate a PW for them? Here, print this out, since you were going to, anyway. Click "save this password", since you were going to, anyway. Cut out the middle man and save everyone time. Now, instead of forcing your users to do the try-to-cheat-the-entropy-algorithm dance, you can show them what a good password can look like. String four words together: happy (or less annoyed) users, good entropy, happy admins.
darkarmani 12y ago
Exactly. If my password is 20 characters, why is it more secure to have it be 10 characters with using upper, numbers, and symbols? (ie: 26^20 >> 95^10).
- gnopgnip 12y ago
  Dictionary attacks work very well on passwords like this.
simi_ 12y ago
At Lavaboom, we simply check against the 10k most used passwords (in memory), but we plan to move to 1 million soon (on disk – account creation is relatively infrequent for the slower access speed to not matter). Our problem is that we SHA the passwords on the client side, so each password is 256 bits long. The resulting hashtable (or bloom filter) is still a reasonable size for disk storage, though.
- ddlatham 12y ago
  With a bloom filter that's still just 2MB of memory for a 99.99% accuracy.
- jamiesonbecker 12y ago
  We SHA256 the passwords on the client side at Userify (SSH key management for EC2) as well (bcrypt is too slow in mobile browsers), and then bcrypt on the server side the resultant hash. (We don't cache it, though.) Even in the event of a TLS leakage, we still never see your original password, and the server doesn't end up doing any more work. It's not perfect, but I definitely agree it's a great step forward.
  - simi_ 12y ago
    That's exactly what we do, too, except we've bravely switched to scrypt at some point.
stouset 12y ago
Why are you not already using a password manager? They have existed in fantastically-useful form for probably well over five years now. If a password is easy to remember, it is easy to guess, and if you reuse a password it's likelihood of being compromised increases dramatically. There is no simple solution for this problem. Password managers make the best of a crappy and likely unavoidable situation.
- AndrewDucker 12y ago
  Because I cannot install applications on my work PC. Which means that I have to sit there carefully copying long strings from my phone to my PC if I want to log into a site at work. Which is frankly more effort than I can be bothered with.
Spooky23 12y ago
If you answer to any kind of external or security compliance regime, that compliance is usually built around NIST guidance. They are big about strong passwords and MFA.
slavak 12y ago
A personal pet peeve of mine is websites that happily inform me my 20-character long, randomly generated by a secure algorithm with an extra heaping of entropy, password is not "strong enough." I just love generating 3 or 4 different COMPLETELY RANDOM passwords with KeePass because your stupid password rules were written by people who wouldn't know entropy if a dictionary open to 'en' hit them square in the jaw.

x1798DE 12y ago

While in some ways I agree that these password rules enforcements are not ideal (they are hardly scientific, they seem much more "common sense" to me), I think making you use a harder-to-remember password is part of the point. The current received wisdom on passwords is that if it's easy to remember, it's easy to guess. That said, I'm not crazy about the inherent paternalism of this sort of thing. I think allowing weak passwords with a warning is, in most instances (not including corporate IT and situations where you're requiring that the user protect your private information rather than their own), a preferred way to go. Informing people when they are making a weak password should at the very least let them make a choice about how much they care about their own security.

wglb 12y ago

It is more palatable if the rules provide for phrases, say 20 characters or longer. Then you can do a few substitutions for word separators and the like. And yes, I agree that it is seriously annoying.

bradleyjg 12y ago

It depends on your threat model of course, but in most situations an attacker that is physically near you is less concerning than an attacker that can be anywhere in the world. In most cases I'd rather you had a twelve character random string written on a post it attached to your monitor than the password "password" not written down anywhere.

paulojreis 12y ago

At my company this typically results in users printing or writing the password down. I wonder if the guys who create these heuristics/recommendations ever had contact with humans. I believe that their research is thorough in their area of expertise (info sec), however, it sounds like they are only considering data per se, ignoring human behavior variables. There's little value in enforcing hard-to-break passwords while also encouraging users to write them down. What I believe: Info sec researchers should team up with HCI people.

tinco 12y ago
There's not much wrong with writing passwords down. Printing thema is less desirable. It's a hundred times better to have a difficult password on a post-it on a monitor than it is to have an easily guessable password. Who do you suspect is going to hack you? Ask that question honestly and you'll know how best to thwart them.
- hackuser 12y ago
  > It's a hundred times better to have a difficult password on a post-it on a monitor than it is to have an easily guessable password. Who do you suspect is going to hack you? It depends on the threats you face. Generally, most attacks are from insiders.
- noamyoungerm 12y ago
  > Who do you suspect is going to hack you? According to my experience: 1. People I know in real life 2. People who execute phishing attacks Your strategy is harmful in the first case, though irrelevant in the second
- paulojreis 12y ago
  I understand your point, and I agree that the biggest threats aren't physically nearby. In that scenario ("remote" attacks), of course, there are bigger problems than written/printed passwords. However, at the enterprise level, physically visible passwords are a big problem. Imagine a less-than-happy worker, about to leave the company, having the opportunity to get coworkers passwords. In such scenario, less strict rules (let's say, rules that didn't make people writing the passwords down) would have been beneficial. And there's another point: the "perception" about IT security rules. If they ask too much of people (think "non-IT people"), they might create a image of overzealousness/"overcomplication". I wonder if this doesn't make people less compliant, with security rules, on the long term.

ssharp 12y ago

I think context is important. If it's a bank password, I don't mind coming up with something complex. If it's for something that requires me to have an account, but I don't care at all whether or not someone else gains access to the account, I have no problem using a much simpler password and would be rather annoyed if I had to do something more complex.

IgorPartola 12y ago
Then you might as well do the RMS thing and set your password to be blank :). Passwords are currently a necessary evil. My hope is that we will ditch them sooner or later. For now, use a password manager to prevent really bad things that will result from what you are doing.

M4v3R 12y ago

I agree on that as well. Enforced - NO (only minimum length should be enforced imho). Encouraged - Yes. Just show a good password strength meter to the user and fine-tune it to your security requirements. If you enforce all kinds of weird password rules to the user, he will have to write the password down somewhere, because one couldn't possible remember all passwords. And for non-technical users that means some random pieces of paper or post-it notes. On the other hand, encouraging them to come up with something that is strong makes it more likely that they will invent a password that they can remember, thus making it more secure.

sarciszewski 12y ago
"Just show a good password strength meter to the user and fine-tune it to your security requirements." That's the approach I follow in my projects. I offer a Javascript (window.crypto powered) Diceware passphrase generator and use zxcvbn to let users know the relative strength of the password they've supplied. I've also been planning an experiment to see if the width of a password field results in users choosing longer passwords, because more empty space. :)
AceJohnny2 12y ago
> If you enforce all kinds of weird password rules to the user, he will have to write the password down somewhere, because one couldn't possible remember all passwords. I'm going to use the appeal to authority argument, and bring over Schneier to argue that writing your passwords down isn't bad: https://www.schneier.com/blog/archives/2005/06/write_down_your.html https://www.schneier.com/blog/archives/2005/06/write_down_yo... (and others posts since, google "schneier writing passwords down" or something) Remembering your password isn't necessarily more secure, especially since it easily leads to password re-use, which is even worse.

DoggettCK 12y ago

Having recently had to implement improved password security for a customer who wouldn't read XKCD #936, the internationalization thing was a pain in the ass. They wanted at least 10 characters, and at least one uppercase, one lower, one digit, and one special character. Easy enough with .NET's built-in membership stuff by setting: passwordStrengthRegularExpression="(?=.{10,})(?=(.\p{Lu}){1,})(?=(.\d){1,})(?=(.*\W){1,})" The "\p{Lu}" part handles uppercase characters even in Unicode chars, but Javascript has no equivalent, so I couldn't do client-side validation of that. Should be validating on both ends anyway, but it's still a pain. The real part I hated was having to keep track of users' last N passwords to make sure they didn't re-use them. Since everything's hashed and salted, I just kept a table of previous hashes by user. Seems simple, but MS didn't see fit to include a HashPassword(string plainTextPassword, byte[] userSalt) method in the membership provider, so I had to reverse engineer their password-hashing method to check when they change passwords if it's something that's been used before. Then I realized that they could just change their password N+1 times in about a minute, then re-use their expired password anyway, so we wound up having to set a minimum age of N weeks before a password could be reused as well. The whole problem is an exploding requirements nightmare that could easily be solved by saying "Must be >32 characters and don't write it down anywhere, idiot." The worst part is as much as I hate these types of requirements, I now perfectly understand why these systems are the way that they are.

bkoehler 12y ago
How did you handle password++ iteration? For example P@ssword01, P@ssword02, P@ssword03 hash differently.
- spydum 12y ago
  I would guess that it didn't.. just another example of the exploding requirements.
  - wernercd 12y ago
    How do you handle (Do you?): * not more than 2 identical characters in a row (e.g., 111 not allowed) * Name/Username in password (Name: Chuck Norris, username: ChuckNorris, Password: ChuckNorris#1) These are reasons why I don't look forward to doing this and also why I'm leaning towards G+/FB/twitter/etc authentication in an app I'm planning.

matthewmacleod 12y ago

I see your point, but given the number of 'test', 'password' and '12345' passwords we see whenever there's a leak, that could be an issue. Maybe just a minimum length? I too get annoyed when there are specific complexity requirements, like 'must include an uppercase letter' even though I've used a 20-character long password including numbers and punctuation.

mtviewdave 12y ago
If the problem is that people are using "password" as a password, why not just ban that example specifically? So you can't use "password", but you can use "djwipvbs". Assuming you're using bcrypt with an appropriate work factor, wouldn't "djwipvbs" be an acceptable password? More generally, you could ban the top X passwords from those "most frequently use password" lists.
coldpie 12y ago
Consider the sources of those leaks. They're usually from places like adobe.com, where my own password is 1234 because I just had to make an account to download some trial software or whatever.
tracker1 12y ago
The worst for me is when there is a strong complexity requirement, but some other stupid limitation, like only specific special characters can be used. I usually result to something like "ThisIsBullshit!1" or something similar (though I started using lastpass, also 2fa where available) I did come across a site that had a cuss word filter, then wouldn't let me change my password... lol. No mention of why it was an invalid password. If you must have certain complexity requirements, spell them out. Personally, if it's over 8-10 characters (with leading and trailing whitespace trimmed off), I'll take anything... convert to UTF8 bytes before 1-way hashing... As for using SCrypt, if it takes a modern CPU 1/2 second on a process to hash a password, then that's ripe for a DDOS against your authentication server, which is where failed attempt counts, and locking for X minutes comes in.

robert_tweed 12y ago

No link handy but I'm sure someone recently wrote an open source effective entropy calculator, which avoids either enforcing stupid entropy-reducing, complexity-increasing rule sets, while also preventing anyone using stupidly easy to guess passwords. Others do things like check against a normalised dictionary (i.e., I, 1 or L are all considered the same character). I really don't know why in this day and age of complex software with libraries for even trivial functionality, this practise isn't more widespread. People are still writing dumb complexity rules like it's 1980. This should really be the new "don't do your own crypto".

VLM 12y ago
"This should really be the new "don't do your own crypto"." oauth / openid for the win Unless your companies "secret sauce" is user authentication and management, you probably shouldn't be doing it.
- bradleyjg 12y ago
  You still almost certainly need to implement a backup system. It is rarely a good idea to force a new user to enter his facebook/google/ms credentials to use your service. Even if 99% of your potential userbase has such credentials they may not want to connect them to your service. That's even before getting into the question about whether or not such systems make it more likely that users will fall to phishing attacks by conditioning them to enter their credentials somewhere other than the website where they were issued that they went to directly.
- elithrar 12y ago
  Using OAuth also doesn't give you a free pass. Plenty of apps/sites/organizations mess up OAuth implementation, and OAuth doesn't solve things for corporate/enterprise users either. It's also not suitable for certain demographics, which puts you back at square one (rolling your own).
nothrabannosir 12y ago
This is a step in the right direction, but down a dead end. Like trying to reach the moon by climbing up a tree. Taking a step back, what we are doing is essentially: you may choose your own password! But, not really. We are going to tell you what not to. After you try it. And it's not a human, or equivalent AI: it's a (dumb) algorithm. If you are going to let someone choose a password, ask yourself: why? Is convenience that much more important than security? Putting, what many people will perceive as, onerous constraints on the passwords greatly reduces that convenience. But users will still try to make it as low entropy as possible, so security suffers, nonetheless. Or is security so important, to hell with convenience? Then why not just generate a PW for them? Here, print this out, since you were going to, anyway. Click "save this password", since you were going to, anyway. Cut out the middle man and save everyone time. Now, instead of forcing your users to do the try-to-cheat-the-entropy-algorithm dance, you can show them what a good password can look like. String four words together: happy (or less annoyed) users, good entropy, happy admins.

darkarmani 12y ago

Exactly. If my password is 20 characters, why is it more secure to have it be 10 characters with using upper, numbers, and symbols? (ie: 26^20 >> 95^10).

gnopgnip 12y ago
Dictionary attacks work very well on passwords like this.

simi_ 12y ago

At Lavaboom, we simply check against the 10k most used passwords (in memory), but we plan to move to 1 million soon (on disk – account creation is relatively infrequent for the slower access speed to not matter). Our problem is that we SHA the passwords on the client side, so each password is 256 bits long. The resulting hashtable (or bloom filter) is still a reasonable size for disk storage, though.

ddlatham 12y ago
With a bloom filter that's still just 2MB of memory for a 99.99% accuracy.
jamiesonbecker 12y ago
We SHA256 the passwords on the client side at Userify (SSH key management for EC2) as well (bcrypt is too slow in mobile browsers), and then bcrypt on the server side the resultant hash. (We don't cache it, though.) Even in the event of a TLS leakage, we still never see your original password, and the server doesn't end up doing any more work. It's not perfect, but I definitely agree it's a great step forward.
- simi_ 12y ago
  That's exactly what we do, too, except we've bravely switched to scrypt at some point.

stouset 12y ago

Why are you not already using a password manager? They have existed in fantastically-useful form for probably well over five years now. If a password is easy to remember, it is easy to guess, and if you reuse a password it's likelihood of being compromised increases dramatically. There is no simple solution for this problem. Password managers make the best of a crappy and likely unavoidable situation.

AndrewDucker 12y ago
Because I cannot install applications on my work PC. Which means that I have to sit there carefully copying long strings from my phone to my PC if I want to log into a site at work. Which is frankly more effort than I can be bothered with.

Spooky23 12y ago

If you answer to any kind of external or security compliance regime, that compliance is usually built around NIST guidance. They are big about strong passwords and MFA.

slavak 12y ago

A personal pet peeve of mine is websites that happily inform me my 20-character long, randomly generated by a secure algorithm with an extra heaping of entropy, password is not "strong enough." I just love generating 3 or 4 different COMPLETELY RANDOM passwords with KeePass because your stupid password rules were written by people who wouldn't know entropy if a dictionary open to 'en' hit them square in the jaw.