9 ms·

Dumb Password Rules

61 points by Liriel 10y ago

laurent123456 10y ago
> - Must be at least 8 characters long > - Include at least 1 number > - Include at least 1 uppercase letter > - Include at least 1 lowercase letter > - May use special character "Password1"
- nobodyshere 10y ago
  Could be shorter.
  - jjawssd 10y ago
    Passw0rd
    - nobodyshere 10y ago
      Now that's what I call security.
- kps 10y ago
  From a past job: > - Must be at least 8 characters long > - Include at least 1 number > - Include at least 1 uppercase letter > - Include at least 1 lowercase letter > - Include at least 1 non-alphanumeric character > - Must not reuse a previous password > - Expires every month "December, 2016"
huphtur 10y ago
Joel Califa's "Patronizing Passwords" has some great examples: http://joelcalifa.com/blog/patronizing-passwords/ http://joelcalifa.com/blog/patronizing-passwords/
- hood_syntax 10y ago
  Thanks for the article, I enjoyed the read
  - design 10y ago
    You're welcome, thanks for reading :)
ManlyBread 10y ago
You can add Voat to the list, it has one of the most frustrating sign-up processes known to man. Most of the rules are hidden until you solve the captcha and press submit.
dvcc 10y ago
In the same spirit, can we please do away with the idea of expiring passwords -- and then enforcing that we can't even re-use our last X number of passwords. It just causes locked out accounts, written down passwords or adding on one more of whatever character was at the end.
- teaearlgraycold 10y ago
  Sites with such strict rules should be enforcing 2FA instead.
- laurencei 10y ago
  There is a specific reason for having "cant reuse last X number of passwords" combined with having an "expiring password" rule. The idea is that if someone was silently in your account, and doing a "stealth" attack - then they could change your password, then change it back to your original password, thus "resetting" your expiring password timer, giving them more time in the system - and you would not know that the password was reset. Preventing old passwords prevents this. Note: The only flaw I never understand with the above is cant the attacker just change the password like 10-15 times in 5mins, and thus "flush" out the old password? Note 2: I dont personally agree with expiring passwords - but it helps understand the reason why it exists.
  - tetrep 10y ago
    > The only flaw I never understand with the above is cant the attacker just change the password like 10-15 times in 5mins, and thus "flush" out the old password? In systems where you have the "can't use previous N passwords" when changing it, you also pair that with a "can't change password more than X times a time increment".
  - dvcc 10y ago
    That thought requires the users to actually use new and unique passwords on every reset. If the attacker knows that your password is "Password1!!!!", it's pretty easy to guess that the next time it asks you for a password it will be "Password1!!!!!". We're all computationally lazy after all. I feel like the notifications that X device was recently used to login from Y IP/location solve that problem in a much easier way.
pilif 10y ago
Some of the restrictions of special characters I can somewhat understand: Depending on the keyboard layout, many of these often disallowed characters require proper right-alt support to be set up in order to be typed. People tend to get these wrong or to be unaware of the currently set keyboard layout which will cause support issues. Same goes for non-ASCII characters where this also depends on the browser configuration and version as they still get the encodings wrong at times. Yes. For us advanced users using password managers this is a non-issue as we're pasting anyways, but for people typing the passwords manually, this can be a problem. Case in point is me setting up new linux boxes and always using a safe initial password (long but pure ASCII) knowing that I'can't be absolutely sure I've configured the keyboard layout correctly. I've started this practice after having been forced to force-reset my password via the `init=/bin/sh` boot argument as the first step after the install :-) What I absolutely don't get though is maximum lengths on passwords. You should be hashing them anyways, so setting a maximum length is completely pointless.
- Nadya 10y ago
  What? If a person is using a password that contains such a character, they'll know how to type it or at least find it to copy/paste... QWERTY isn't the only keyboard layout. Nor do you need right-alt support to type things like é or ç, you just need to enable the US-International Keyboard layout (on Windows, I'm sure equivalents exist for other operating systems). >Case in point is me setting up new linux boxes and always using a safe initial password (long but pure ASCII) knowing that I'can't be absolutely sure I've configured the keyboard layout correctly. That is smart for an initial password that you change once you know your keyboard is configured properly. A temporary password while spinning up a new machine isn't too big of a security deal if you're going to be changing it within a few hours anyways.
  - pilif 10y ago
    > What? If a person is using a password that contains such a character, they'll know how to type it or at least find it to copy/paste... I have had to deal with people not being able to type their passwords because a character wasn't on their current keyboard of choice (some people use iPads and don't know how to type a # for example) > you just need to enable the US-International Keyboard layout (on Windows, I'm sure equivalents exist for other operating systems) you're giving way too much credit to the knowledge of the average computer user.
choward 10y ago
My favorites are the ones where you can't use more than a certain number of characters or where you can't use special characters.
- adrr 10y ago
  Amex website had their max password length of 8 characters. Not sure if they changed it. Even if you do have a system constraint, you could just lop off the extra characters and the user wouldn't probably never notice.
  - jlgaddis 10y ago
    Mine is way more than eight characters (randomly generated w/ KeePassX), although I haven't tried truncating it to eight and seeing what happens.
  - duffn 10y ago
    According to the screen shot in the repo, it's not even case sensitive either.
- masklinn 10y ago
  http://kottke.org/12/06/the-worlds-worst-password-requirements-list http://kottke.org/12/06/the-worlds-worst-password-requiremen... Sabre Red is great: 7 or 8 characters, no Q, no Z.
- drey08 10y ago
  Like Microsoft account passwords (at least for office 365). I don't understand why they do this.
  - USANEEDSHELP 10y ago
    They do this because it makes it easier for the 3 letter US agency to guess the password.
- yeukhon 10y ago
  Or they say cannot accept repeating characters. Like "2j4lwroiw4lkf9wwjsofserow111" is still bad because of 111.
fdim 10y ago
How about allowing special characters and not just a-zA-Z0-9.
- blowski 10y ago
  Usually, there is some legacy system behind the scenes that can't be updated because reasons. Not an excuse, but it isn't always that easy.
  - morganvachon 10y ago
    I wonder if another reason may be the differences between traditional PCs and mobile devices with virtual keyboards. I've seen special characters that are two taps away on my phone that I'd have to look up an Alt code for on my PC.
    - deleted 10y ago
      [deleted]
- dwe3000 10y ago
  I think the usual lazy reason is to defend against Bobby Tables[1]. Sites that don't cleanse the user input properly. [1] https://www.xkcd.com/327/ https://www.xkcd.com/327/
lucideer 10y ago
Stack Overflow is the offender that's affected (and surprised) me most in terms of arbitrary requirements. though It's a while since I've tried changing my password there so not sure if it's changed.
libeclipse 10y ago
A university that I'm applying to has a particularly stupid requirement on their login portal, but since I'm a prospective student, I don't think it'd be wise for me to name and shame.
- Dragonai 10y ago
  Come back and contribute to this once they've made a decision. :)
deleted 10y ago
[deleted]
tacostakohashi 10y ago
I use KeePass to store all of my (randomly generated) passwords. One ongoing annoyance is that it's increasingly difficult to generate a random string will be meet a given site's Dumb Password Rules, because so many sites have them, and there's surprisingly little overlap in the rules. I would really like to see a database of sites and their corresponding Dumb Password Rules, so that I can tell KeePass (or any other app using the database) to generate me a new Mindware password, or a new Williams-Sonoma password, and get a random string that conforms to all the relevant DPRs.
- jjnoakes 10y ago
  KeePass should let users configure a pattern for passwords, like "8-25 letters or numbers or these symbols, must have 1 uppercase letter", and just replicate that socially (the pair of web site and pattern) across all KeePass users.
  - scrapcode 10y ago
    Sounds like a good idea at first, but could also be a huge attack point.
    - Bartweiss 10y ago
      The "replicate" bit sounds deeply alarming - a password manager using social or learned rules just screams vulnerability. If you made me guess an attack, I'd picture someone paying for a server cluster or botnet to repeatedly assert super-restrictive rules, and then use their knowledge of those rules to guess the generated passwords. Allowing some basic rule-setting, though, sounds quite nice. Arbitrary restrictions will probably leave people setting bad passwords, but there are some very common flags like "must have a special character" or "can't have a special character" that it'd be convenient to access for these sites.
  - tacostakohashi 10y ago
    Sure, but there are other password managers with this same problem. I'm suggesting something more like the tz database - a common, authoritative source of truth for any password generator / database app to use. Just like the tz database, it would require some maintenance, but I think it would be worthwhile (yes, I would volunteer to maintain it, if others were to volunteer to add support for same in the various keepass implementations I use).
makecheck 10y ago
I think that if you intend to “shame” something, you should at least start out with proper channels (e.g. send an E-mail, file a bug, whatever). Also, it’s not really going to shame them unless you point them to the place they’re being shamed. In the end, what is more important: seeing the situation improved or just complaining?
lorenzhs 10y ago
My bank limits passwords to at most 5 alphanumerical characters. Yup. Five. There are over ten times more possible customer IDs (10 digits) than passwords.
- vinay427 10y ago
  Out of curiosity, what bank is this?
  - lorenzhs 10y ago
    The Sparkassen in Germany do this, but they're not alone in doing so. They lock you out after a couple of attempts, so brute-force is out, but it's still dumb.
    - clarkcox3 10y ago
      > so brute-force is out Until someone gets ahold of a list of the hashed passwords and can brute force them at home without triggering the lockout.
ryandrake 10y ago
Something I've always disliked about password rules is the "special" treatment of special characters. What makes one character special and not another? Is % special? Why? Can I use ½ in my password and have it count as a special character? How about 特别? What about Ѕ, Κ, and о? Does "special" mean non-ASCII, non-alphanumeric, not-on-the-keyboard or something else? Why is it that sometimes some "special" characters are allowed and others are not, even if they're right next to each other on the keyboard? Why require one? Is "P@ssword" really better than "correct horse battery staple"?
- Bartweiss 10y ago
  My experience is that "special" almost always means "non-alphanumeric ASCII". Anything beyond that is banned pretty much everywhere, unless you get really unlucky and it's stripped into nearest-equivalent ASCII, giving you a result fundamentally different from what you typed in.
- curun1r 10y ago
  The thing I've always found concerning about sites disallowing certain special characters is that it makes you worry that they're doing something other than immediately feeding the raw password bits into a password hashing algorithm. It's not that disallowing those characters will lead to more insecure passwords that worries me, it's that it indicates that the site is more likely to be making other mistakes that will allow my account to be compromised in some way that doesn't attack the strength of the password. The only reason I can fathom for disallowing certain characters is if they expect a use case where someone will be entering their password on equipment incapable of entering those characters. For example, let's say TSA's Global Entry program required people to authenticate as they're passing through customs. In that case, it would be perfectly reasonable to limit valid password characters to those that can be entered on the available keyboards. But those kinds of use cases are few and far between.
- x1798DE 10y ago
  I think generally people stick to ASCII printable characters because of the support cost, since the benefit of allowing non-ASCII passwords is not generally worth the headache of dealing with customers who find themselves trying to log in to their account a terminal that isn't configured for the character set their password is in. As for other special characters, a properly implemented password storage system would just dump these directly into a key-derivation function before it ever touches a database, but I think you get those rules from a mix of: 1. people who are storing their passwords in plaintext and are worried about SQL injection attacks and 2. people who know to pass them to a KDF before storing them in the database and either have inherited some old rule about "no special characters" or who are not convinced that someone in the future won't make changes to the system such that special characters would become a problem, and are trying to make it more robust to potential reversions. Not saying it's a good idea, but at least some people "doing things right" will still have somewhat reasonable concerns about special characters.
0XAFFE 10y ago
Popular German bank „Sparkasse“ has this great online banking system that allows you only 5 characters (Small and large, numbers, umlauts and eszet[1]). They call it a PIN (Personal identification /number/), but IMO its terribly insecure. [1] https://en.wikipedia.org/wiki/%C3%9F https://en.wikipedia.org/wiki/%C3%9F
- Bartweiss 10y ago
  The entire 'pin' scheme frustrates me. I've started to see it in a growing number of places as full authentication - either no password or pin accepted without the password. 5 characters with those options obviously isn't enough, but it's still better than "four digit numeric", which is also out there. That's such a small space that you can try it by hand, for god's sake.
- duffn 10y ago
  This is the second time I've now heard of this since starting the repo. I cannot believe an online financial institution allows this. Feel free to submit a PR if you like.
  - 0XAFFE 10y ago
    @duffn is ok if its in german?
    - duffn 10y ago
      Sure. If you could also provide a description in English as well I think that would be helpful. Here's a non-English example: https://github.com/duffn/dumb-password-rules#movistar https://github.com/duffn/dumb-password-rules#movistar
a_c 10y ago
Related. One local bank I've used forbid typing out password on keyboard. They provide a virtual keyboard and you have to click your keys one by one.
dawnerd 10y ago
I created an issue for this, but one really dumb thing is inconsistent password verification. Bestbuy will let you use anything for a password but on login really long passwords will trip it up. Been able to reproduce it a few times with 64 character passwords generated from 1pass.
- aggie 10y ago
  Why use a 64-character password? This post suggests more than ~21 random characters (128 bits) doesn't get you extra (practical) security: https://security.stackexchange.com/questions/33196/is-there-a-length-beyond-which-increasing-password-length-provides-no-additional https://security.stackexchange.com/questions/33196/is-there-...
  - dawnerd 10y ago
    No good reason other than they let me. My thinking is, if you're going to let me put anything in then your system should work with that. If it's going to break at n characters then cap the length.
prashnts 10y ago
While we're at it, can we also shame the banks which ask you "third", "fourth" and "ninth" character of your password + date of birth to login? Clearly they're storing the password in Plaintext (otherwise the "random" characters can't be matched). I know Thomas Cook did this with their pre-paid forex mastercards which I happen to use while travelling abroad.
- x1798DE 10y ago
  It's a horrible practice that reduces the entropy of your password a huge amount, but it's possible to generate these things without storing them in plain text. Like if you know you're going to ask for 6 of the 9 characters every time, you'd just pre-hash whatever subset of 6-character passwords you plan on using. Of course, this turns a 9-character password into at most 84 six-character passwords, so assuming they allow all printable ASCII characters, you go from 1e18 possible combinations to 84 passwords of 1e12 possible combinations - of which you have to crack two, with the second one being 100000x easier than the first, so overall the password is ~1,000,000 easier to crack from the hash. I imagine in most cases it's actually a signficantly greater reduction in security than that, so it might as well be plain text. I think the idea is that they are worried that their customers will enter in their real, full password on something with a keylogger.
bertr4nd 10y ago
Honest question: does password strength actually matter that much in practice? Do people using "horse" get hacked more often than using "zjh5?&Dp"? Is there a point of diminishing returns where "horse23" is basically good enough? Has anybody studied this in a systematic way?
- Cursuviam 10y ago
  Yes, if an attacker gets a dump of hashed passwords, horse will be tried much sooner than the other example.
- Bartweiss 10y ago
  I believe the studied answers are yes, yes, and yes. Ars Technica has some good articles on this. Generally, individual accounts don't get compromised at all unless they're a high-profile target, at which point guessable passwords become an issue. If you're a diplomat, CEO, or celebrity, you might get hit if you use "Password" or "123456". Otherwise, lockout rules and a general lack of interest will probably save you. The real risk comes when hashed password sets get dumped. At that point, people start attacking the entire set to see how much they can crack (this is what the Ars articles were about), and this is where password security becomes a big deal. As I remember, the common attack workflow is something like: 1. Throw a top-200 password list at the dataset. (Lulzsec did this then named-and-shamed exclusively people with bad passwords.) 2. Dictionary attack on one-word passwords. 3. Dictionary attack on two-word passwords and one-word passwords with common tweaks (i.e. first-letter capital, trailing numbers). (I consider the XKCD somewhat misleading, since an alteration to bar pure-dictionary attacks remains a useful addition.) 4. Expansive dictionary work: common but nontrivial adjustments like o/0, l/1, or scattered capitals. 5. Brute force all short passwords. <6 character is easy to break outright, and "smart" force (e.g. all 2 character combinations after common words) will get you many longer passwords. For unpredictable passwords, 8-10 characters is the inflection point on attack length. All of this goes basically unchanged with salting, it's just harder (and often, gets easier as you compromise a few salted passwords). So yes, this stuff matters in predictable ways. Pretty much all of it is defense against password dumps, in which context it definitely matters. And in that context, password managers remain king - they'll block even dedicated attacks on a single user.
petarb 10y ago
The Covered California website suffers from the dumb password problem. It took me 6 tries with Last pass before I could generate a random password that "matched" their hidden rules.
jlgaddis 10y ago
I think the reason that many banks still have "stupid" requirements (as seen in this thread) is because many of them still offer "banking by phone" -- i.e. calling into an automated system and using DTMF tones to enter your password/PIN/etc.
cr0sh 10y ago
What is HN's opinion on XKCD-936? Is it valid, or complete rubbish - or somewhere in-between? The last time I researched this, I found a number of different opinions, but they ultimately trended toward it being a "good idea", with the caveat that the words need to be chosen by a truly random process, and not by the user (as then bias would creep in). I'm not a cryptographer, though - maybe someone(s) here is and can give some further insight? Also - if such a password is a good thing, it would probably be best to use it for a password manager, and let the manager generate long random passwords for individual logins. If XKCD-936 is considered ok, then in theory, as long as the password field allows for reasonably long passwords (25+ characters), and simple letters and numbers - it should be ok. The problem would then be education (for the users and developers - plus convincing IT/security/management) - we've all been conditioned that passwords need to appear complex (not that they actually are for a computer). Then of course, there's the problem that this is baked into financial/banking security rules passed by Congress (so if XKCD-936 is correct, it basically means we've legislated an insecure practice in place, based on faulty knowledge at the time, for the one area where we need the most security possible)... Thoughts?
TimWolla 10y ago
This is the reason I opt for alphanumeric passwords without special characters, unless a service requires otherwise. A single extra character in length more than makes up for the missing special characters and past a certain point a password simply is “strong enough”.
sashk 10y ago
CPanel -- https://features.cpanel.net/topic/better-password-strength-checker https://features.cpanel.net/topic/better-password-strength-c... Will say that "correct horse battery staple" isn't secure password and will give it a score of 0/100. While "123!" will get 66/100 and will get accepted. And this is control panel used by many hosting companies. :)

61 points by Liriel 10y ago

> - Must be at least 8 characters long > - Include at least 1 number > - Include at least 1 uppercase letter > - Include at least 1 lowercase letter > - May use special character "Password1"

nobodyshere 10y ago
Could be shorter.
- jjawssd 10y ago
  Passw0rd
  - nobodyshere 10y ago
    Now that's what I call security.
kps 10y ago
From a past job: > - Must be at least 8 characters long > - Include at least 1 number > - Include at least 1 uppercase letter > - Include at least 1 lowercase letter > - Include at least 1 non-alphanumeric character > - Must not reuse a previous password > - Expires every month "December, 2016"

huphtur 10y ago

Joel Califa's "Patronizing Passwords" has some great examples: http://joelcalifa.com/blog/patronizing-passwords/ http://joelcalifa.com/blog/patronizing-passwords/

hood_syntax 10y ago
Thanks for the article, I enjoyed the read
- design 10y ago
  You're welcome, thanks for reading :)

ManlyBread 10y ago

You can add Voat to the list, it has one of the most frustrating sign-up processes known to man. Most of the rules are hidden until you solve the captcha and press submit.

dvcc 10y ago

In the same spirit, can we please do away with the idea of expiring passwords -- and then enforcing that we can't even re-use our last X number of passwords. It just causes locked out accounts, written down passwords or adding on one more of whatever character was at the end.

teaearlgraycold 10y ago
Sites with such strict rules should be enforcing 2FA instead.
laurencei 10y ago
There is a specific reason for having "cant reuse last X number of passwords" combined with having an "expiring password" rule. The idea is that if someone was silently in your account, and doing a "stealth" attack - then they could change your password, then change it back to your original password, thus "resetting" your expiring password timer, giving them more time in the system - and you would not know that the password was reset. Preventing old passwords prevents this. Note: The only flaw I never understand with the above is cant the attacker just change the password like 10-15 times in 5mins, and thus "flush" out the old password? Note 2: I dont personally agree with expiring passwords - but it helps understand the reason why it exists.
- tetrep 10y ago
  > The only flaw I never understand with the above is cant the attacker just change the password like 10-15 times in 5mins, and thus "flush" out the old password? In systems where you have the "can't use previous N passwords" when changing it, you also pair that with a "can't change password more than X times a time increment".
- dvcc 10y ago
  That thought requires the users to actually use new and unique passwords on every reset. If the attacker knows that your password is "Password1!!!!", it's pretty easy to guess that the next time it asks you for a password it will be "Password1!!!!!". We're all computationally lazy after all. I feel like the notifications that X device was recently used to login from Y IP/location solve that problem in a much easier way.

pilif 10y ago

Some of the restrictions of special characters I can somewhat understand: Depending on the keyboard layout, many of these often disallowed characters require proper right-alt support to be set up in order to be typed. People tend to get these wrong or to be unaware of the currently set keyboard layout which will cause support issues. Same goes for non-ASCII characters where this also depends on the browser configuration and version as they still get the encodings wrong at times. Yes. For us advanced users using password managers this is a non-issue as we're pasting anyways, but for people typing the passwords manually, this can be a problem. Case in point is me setting up new linux boxes and always using a safe initial password (long but pure ASCII) knowing that I'can't be absolutely sure I've configured the keyboard layout correctly. I've started this practice after having been forced to force-reset my password via the `init=/bin/sh` boot argument as the first step after the install :-) What I absolutely don't get though is maximum lengths on passwords. You should be hashing them anyways, so setting a maximum length is completely pointless.

Nadya 10y ago
What? If a person is using a password that contains such a character, they'll know how to type it or at least find it to copy/paste... QWERTY isn't the only keyboard layout. Nor do you need right-alt support to type things like é or ç, you just need to enable the US-International Keyboard layout (on Windows, I'm sure equivalents exist for other operating systems). >Case in point is me setting up new linux boxes and always using a safe initial password (long but pure ASCII) knowing that I'can't be absolutely sure I've configured the keyboard layout correctly. That is smart for an initial password that you change once you know your keyboard is configured properly. A temporary password while spinning up a new machine isn't too big of a security deal if you're going to be changing it within a few hours anyways.
- pilif 10y ago
  > What? If a person is using a password that contains such a character, they'll know how to type it or at least find it to copy/paste... I have had to deal with people not being able to type their passwords because a character wasn't on their current keyboard of choice (some people use iPads and don't know how to type a # for example) > you just need to enable the US-International Keyboard layout (on Windows, I'm sure equivalents exist for other operating systems) you're giving way too much credit to the knowledge of the average computer user.

choward 10y ago

My favorites are the ones where you can't use more than a certain number of characters or where you can't use special characters.

adrr 10y ago
Amex website had their max password length of 8 characters. Not sure if they changed it. Even if you do have a system constraint, you could just lop off the extra characters and the user wouldn't probably never notice.
- jlgaddis 10y ago
  Mine is way more than eight characters (randomly generated w/ KeePassX), although I haven't tried truncating it to eight and seeing what happens.
- duffn 10y ago
  According to the screen shot in the repo, it's not even case sensitive either.
masklinn 10y ago
http://kottke.org/12/06/the-worlds-worst-password-requirements-list http://kottke.org/12/06/the-worlds-worst-password-requiremen... Sabre Red is great: 7 or 8 characters, no Q, no Z.
drey08 10y ago
Like Microsoft account passwords (at least for office 365). I don't understand why they do this.
- USANEEDSHELP 10y ago
  They do this because it makes it easier for the 3 letter US agency to guess the password.
yeukhon 10y ago
Or they say cannot accept repeating characters. Like "2j4lwroiw4lkf9wwjsofserow111" is still bad because of 111.

fdim 10y ago

How about allowing special characters and not just a-zA-Z0-9.

blowski 10y ago
Usually, there is some legacy system behind the scenes that can't be updated because reasons. Not an excuse, but it isn't always that easy.
- morganvachon 10y ago
  I wonder if another reason may be the differences between traditional PCs and mobile devices with virtual keyboards. I've seen special characters that are two taps away on my phone that I'd have to look up an Alt code for on my PC.
  - deleted 10y ago
    [deleted]
dwe3000 10y ago
I think the usual lazy reason is to defend against Bobby Tables[1]. Sites that don't cleanse the user input properly. [1] https://www.xkcd.com/327/ https://www.xkcd.com/327/

lucideer 10y ago

Stack Overflow is the offender that's affected (and surprised) me most in terms of arbitrary requirements. though It's a while since I've tried changing my password there so not sure if it's changed.

libeclipse 10y ago

A university that I'm applying to has a particularly stupid requirement on their login portal, but since I'm a prospective student, I don't think it'd be wise for me to name and shame.

Dragonai 10y ago
Come back and contribute to this once they've made a decision. :)

deleted 10y ago

[deleted]

tacostakohashi 10y ago

I use KeePass to store all of my (randomly generated) passwords. One ongoing annoyance is that it's increasingly difficult to generate a random string will be meet a given site's Dumb Password Rules, because so many sites have them, and there's surprisingly little overlap in the rules. I would really like to see a database of sites and their corresponding Dumb Password Rules, so that I can tell KeePass (or any other app using the database) to generate me a new Mindware password, or a new Williams-Sonoma password, and get a random string that conforms to all the relevant DPRs.

jjnoakes 10y ago
KeePass should let users configure a pattern for passwords, like "8-25 letters or numbers or these symbols, must have 1 uppercase letter", and just replicate that socially (the pair of web site and pattern) across all KeePass users.
- scrapcode 10y ago
  Sounds like a good idea at first, but could also be a huge attack point.
  - Bartweiss 10y ago
    The "replicate" bit sounds deeply alarming - a password manager using social or learned rules just screams vulnerability. If you made me guess an attack, I'd picture someone paying for a server cluster or botnet to repeatedly assert super-restrictive rules, and then use their knowledge of those rules to guess the generated passwords. Allowing some basic rule-setting, though, sounds quite nice. Arbitrary restrictions will probably leave people setting bad passwords, but there are some very common flags like "must have a special character" or "can't have a special character" that it'd be convenient to access for these sites.
- tacostakohashi 10y ago
  Sure, but there are other password managers with this same problem. I'm suggesting something more like the tz database - a common, authoritative source of truth for any password generator / database app to use. Just like the tz database, it would require some maintenance, but I think it would be worthwhile (yes, I would volunteer to maintain it, if others were to volunteer to add support for same in the various keepass implementations I use).

makecheck 10y ago

I think that if you intend to “shame” something, you should at least start out with proper channels (e.g. send an E-mail, file a bug, whatever). Also, it’s not really going to shame them unless you point them to the place they’re being shamed. In the end, what is more important: seeing the situation improved or just complaining?

lorenzhs 10y ago

My bank limits passwords to at most 5 alphanumerical characters. Yup. Five. There are over ten times more possible customer IDs (10 digits) than passwords.

vinay427 10y ago
Out of curiosity, what bank is this?
- lorenzhs 10y ago
  The Sparkassen in Germany do this, but they're not alone in doing so. They lock you out after a couple of attempts, so brute-force is out, but it's still dumb.
  - clarkcox3 10y ago
    > so brute-force is out Until someone gets ahold of a list of the hashed passwords and can brute force them at home without triggering the lockout.

ryandrake 10y ago

Something I've always disliked about password rules is the "special" treatment of special characters. What makes one character special and not another? Is % special? Why? Can I use ½ in my password and have it count as a special character? How about 特别? What about Ѕ, Κ, and о? Does "special" mean non-ASCII, non-alphanumeric, not-on-the-keyboard or something else? Why is it that sometimes some "special" characters are allowed and others are not, even if they're right next to each other on the keyboard? Why require one? Is "P@ssword" really better than "correct horse battery staple"?

Bartweiss 10y ago
My experience is that "special" almost always means "non-alphanumeric ASCII". Anything beyond that is banned pretty much everywhere, unless you get really unlucky and it's stripped into nearest-equivalent ASCII, giving you a result fundamentally different from what you typed in.
curun1r 10y ago
The thing I've always found concerning about sites disallowing certain special characters is that it makes you worry that they're doing something other than immediately feeding the raw password bits into a password hashing algorithm. It's not that disallowing those characters will lead to more insecure passwords that worries me, it's that it indicates that the site is more likely to be making other mistakes that will allow my account to be compromised in some way that doesn't attack the strength of the password. The only reason I can fathom for disallowing certain characters is if they expect a use case where someone will be entering their password on equipment incapable of entering those characters. For example, let's say TSA's Global Entry program required people to authenticate as they're passing through customs. In that case, it would be perfectly reasonable to limit valid password characters to those that can be entered on the available keyboards. But those kinds of use cases are few and far between.
x1798DE 10y ago
I think generally people stick to ASCII printable characters because of the support cost, since the benefit of allowing non-ASCII passwords is not generally worth the headache of dealing with customers who find themselves trying to log in to their account a terminal that isn't configured for the character set their password is in. As for other special characters, a properly implemented password storage system would just dump these directly into a key-derivation function before it ever touches a database, but I think you get those rules from a mix of: 1. people who are storing their passwords in plaintext and are worried about SQL injection attacks and 2. people who know to pass them to a KDF before storing them in the database and either have inherited some old rule about "no special characters" or who are not convinced that someone in the future won't make changes to the system such that special characters would become a problem, and are trying to make it more robust to potential reversions. Not saying it's a good idea, but at least some people "doing things right" will still have somewhat reasonable concerns about special characters.

0XAFFE 10y ago

Popular German bank „Sparkasse“ has this great online banking system that allows you only 5 characters (Small and large, numbers, umlauts and eszet[1]). They call it a PIN (Personal identification /number/), but IMO its terribly insecure. [1] https://en.wikipedia.org/wiki/%C3%9F https://en.wikipedia.org/wiki/%C3%9F

Bartweiss 10y ago
The entire 'pin' scheme frustrates me. I've started to see it in a growing number of places as full authentication - either no password or pin accepted without the password. 5 characters with those options obviously isn't enough, but it's still better than "four digit numeric", which is also out there. That's such a small space that you can try it by hand, for god's sake.
duffn 10y ago
This is the second time I've now heard of this since starting the repo. I cannot believe an online financial institution allows this. Feel free to submit a PR if you like.
- 0XAFFE 10y ago
  @duffn is ok if its in german?
  - duffn 10y ago
    Sure. If you could also provide a description in English as well I think that would be helpful. Here's a non-English example: https://github.com/duffn/dumb-password-rules#movistar https://github.com/duffn/dumb-password-rules#movistar

a_c 10y ago

Related. One local bank I've used forbid typing out password on keyboard. They provide a virtual keyboard and you have to click your keys one by one.

dawnerd 10y ago

I created an issue for this, but one really dumb thing is inconsistent password verification. Bestbuy will let you use anything for a password but on login really long passwords will trip it up. Been able to reproduce it a few times with 64 character passwords generated from 1pass.

aggie 10y ago
Why use a 64-character password? This post suggests more than ~21 random characters (128 bits) doesn't get you extra (practical) security: https://security.stackexchange.com/questions/33196/is-there-a-length-beyond-which-increasing-password-length-provides-no-additional https://security.stackexchange.com/questions/33196/is-there-...
- dawnerd 10y ago
  No good reason other than they let me. My thinking is, if you're going to let me put anything in then your system should work with that. If it's going to break at n characters then cap the length.

prashnts 10y ago

While we're at it, can we also shame the banks which ask you "third", "fourth" and "ninth" character of your password + date of birth to login? Clearly they're storing the password in Plaintext (otherwise the "random" characters can't be matched). I know Thomas Cook did this with their pre-paid forex mastercards which I happen to use while travelling abroad.

x1798DE 10y ago
It's a horrible practice that reduces the entropy of your password a huge amount, but it's possible to generate these things without storing them in plain text. Like if you know you're going to ask for 6 of the 9 characters every time, you'd just pre-hash whatever subset of 6-character passwords you plan on using. Of course, this turns a 9-character password into at most 84 six-character passwords, so assuming they allow all printable ASCII characters, you go from 1e18 possible combinations to 84 passwords of 1e12 possible combinations - of which you have to crack two, with the second one being 100000x easier than the first, so overall the password is ~1,000,000 easier to crack from the hash. I imagine in most cases it's actually a signficantly greater reduction in security than that, so it might as well be plain text. I think the idea is that they are worried that their customers will enter in their real, full password on something with a keylogger.

bertr4nd 10y ago

Honest question: does password strength actually matter that much in practice? Do people using "horse" get hacked more often than using "zjh5?&Dp"? Is there a point of diminishing returns where "horse23" is basically good enough? Has anybody studied this in a systematic way?

Cursuviam 10y ago
Yes, if an attacker gets a dump of hashed passwords, horse will be tried much sooner than the other example.
Bartweiss 10y ago
I believe the studied answers are yes, yes, and yes. Ars Technica has some good articles on this. Generally, individual accounts don't get compromised at all unless they're a high-profile target, at which point guessable passwords become an issue. If you're a diplomat, CEO, or celebrity, you might get hit if you use "Password" or "123456". Otherwise, lockout rules and a general lack of interest will probably save you. The real risk comes when hashed password sets get dumped. At that point, people start attacking the entire set to see how much they can crack (this is what the Ars articles were about), and this is where password security becomes a big deal. As I remember, the common attack workflow is something like: 1. Throw a top-200 password list at the dataset. (Lulzsec did this then named-and-shamed exclusively people with bad passwords.) 2. Dictionary attack on one-word passwords. 3. Dictionary attack on two-word passwords and one-word passwords with common tweaks (i.e. first-letter capital, trailing numbers). (I consider the XKCD somewhat misleading, since an alteration to bar pure-dictionary attacks remains a useful addition.) 4. Expansive dictionary work: common but nontrivial adjustments like o/0, l/1, or scattered capitals. 5. Brute force all short passwords. <6 character is easy to break outright, and "smart" force (e.g. all 2 character combinations after common words) will get you many longer passwords. For unpredictable passwords, 8-10 characters is the inflection point on attack length. All of this goes basically unchanged with salting, it's just harder (and often, gets easier as you compromise a few salted passwords). So yes, this stuff matters in predictable ways. Pretty much all of it is defense against password dumps, in which context it definitely matters. And in that context, password managers remain king - they'll block even dedicated attacks on a single user.

petarb 10y ago

The Covered California website suffers from the dumb password problem. It took me 6 tries with Last pass before I could generate a random password that "matched" their hidden rules.

jlgaddis 10y ago

I think the reason that many banks still have "stupid" requirements (as seen in this thread) is because many of them still offer "banking by phone" -- i.e. calling into an automated system and using DTMF tones to enter your password/PIN/etc.

cr0sh 10y ago

What is HN's opinion on XKCD-936? Is it valid, or complete rubbish - or somewhere in-between? The last time I researched this, I found a number of different opinions, but they ultimately trended toward it being a "good idea", with the caveat that the words need to be chosen by a truly random process, and not by the user (as then bias would creep in). I'm not a cryptographer, though - maybe someone(s) here is and can give some further insight? Also - if such a password is a good thing, it would probably be best to use it for a password manager, and let the manager generate long random passwords for individual logins. If XKCD-936 is considered ok, then in theory, as long as the password field allows for reasonably long passwords (25+ characters), and simple letters and numbers - it should be ok. The problem would then be education (for the users and developers - plus convincing IT/security/management) - we've all been conditioned that passwords need to appear complex (not that they actually are for a computer). Then of course, there's the problem that this is baked into financial/banking security rules passed by Congress (so if XKCD-936 is correct, it basically means we've legislated an insecure practice in place, based on faulty knowledge at the time, for the one area where we need the most security possible)... Thoughts?

TimWolla 10y ago

This is the reason I opt for alphanumeric passwords without special characters, unless a service requires otherwise. A single extra character in length more than makes up for the missing special characters and past a certain point a password simply is “strong enough”.

sashk 10y ago

CPanel -- https://features.cpanel.net/topic/better-password-strength-checker https://features.cpanel.net/topic/better-password-strength-c... Will say that "correct horse battery staple" isn't secure password and will give it a score of 0/100. While "123!" will get 66/100 and will get accepted. And this is control panel used by many hosting companies. :)