> - 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
> - 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
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.
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.
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.
> 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".
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.
err in that attack how do they know your original password to change it back? and if they know your password to change it back why bother changing it in the first place, why not just log in as you?
AFAIK the reason for password history is where periodic password change is enforced, to prevent a user from just alternating between two passwords.
Let's say a service does not require you to change the password. You are then "compromised once, compromised forever", at least until you change the password.
Let's say it requires you to change it every month. You are compromised at max for a month, right? If the attacker changes the password, you will notice, and make a different password, which will lock them out since they don't know the new one. So they won't change it, but they will lose access next month. This is good...
Except if you allow repetitions of old passwords. In this case, the attacker can change your original password to 'aaaaaaaa' for a moment and re-change it back to the original one, which will reset the "one month" timer, leaving them with access. Until you change it, but the platform won't bother you with it since the timer never expires.
I've done many password audits over the years and all monthly password changes does it make people use sequence passwords (e.g. MyPass1!, MyPass2!, MyPass3!) which are easily guessed by the attacker once they have one instance of the sequence, so really monthly changes add very little in exchange for the hassle they introduce.
The more sensible approach is not to force periodic change and only change where there is a suspicion of breach.
Although, a lot of accounts send immediately E-mail on changes (e.g. bank says “the password on your account was changed” so you would know if someone was changing it and changing it back). It actually seems pretty reasonable to send E-mails on every single account update, as some sites do.
Perhaps you would notice. The average user, however, would probably then try to log in to their bank (with their usual password), get in just fine, and then think something along the lines of "oh, the bank's system must be screwed up again" and forget about it.
WRT your note, some security policies (I don't remember which of them do it off the top of my head, but things like DoD STIG, PCI-DSS, NIST, CJIS, etc.), require a minimum time (e.g. 1 day) between password changes to prevent exactly this.
It doesn't seem that common in the corporate world or typical web apps, though.
There's a not-uncommon pattern where someone gets an account compromised and starts a password tug-of-war. The attacker gets entry, and possibly changes the password, but doesn't own the recovery account, so the user finds the problem and uses email reset to change the password again. In this case, it's good to block the old (compromised) password, and bad to set a lockout that gives the attacker more time.
Of course, a lot went wrong in that story. Forcing email confirmation of all password resets can help, mandating re-typing of the old password for a change can help (against session hijacking, mostly), and any corporate or user-focused solution should probably have a response scheme for reporting and locking compromised accounts anyway.
But for social media style sites where the recovery system is "use your email recovery to fight for control", the reset time does seem like a threat.
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.
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.
> 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.
Also that ß submitted by one browser is \xc3 \x9f in one browser and \xdf in another and \xe1 in yet another. Sure - if the client behaves correctly, you'd know what it arrives as, but some browsers don't and suddenly the password 'foobar' can be used to log-in, but 'foßbar' can't.
By not allowing non-ascii characters in the first place you remove a whole class of support issues.
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.
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.
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.
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.
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.
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.
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.
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).
Even without the social aspect, it would be nice to just have some common flags you can set like "uppercase required, special characters banned" when generating for a specific site.
It does let you configure a pattern and even save the pattern for reuse. It's the replicate socially that's not implemented. Might be a fun idea for a KeePass plugin.
What I think we need is a standard for documenting password requirements and restrictions on the password entry page itself, in a format that is easily parsed and understood by software.
Password managers that have browser integration could then use this to generate passwords acceptable to the site.
For password managers without browser integration, I bookmarklet could be developed that extracts the password format information and makes it available in a form that can be copy/pasted to the password manager, which could then remember it along with the other data for the site.
There are at least three ways that seem reasonable that could be used to convey the necessary information.
1. Make use of already defined attributes of the <input type="password"> field. In particular, there are three existing attributes that are very relevant:
• minlength: the minimum allowed length of input,
• maxlength: the maximum allowed length of input,
• pattern: a regular expression that the password must match.
By using lookahead matching in the regular expression, you can express rules like "must have at least one upper case English letter, one lower case English letter, one digit, and one special character chosen from @!#$%^&()". For example, pattern="(?=.[A-Z])(?=.[a-z])(?=.[0-9])(?=.[@!#$%^&()])".
A downside to this is that expressing the rules as a regular expression does not make it easy for a program like a password manager to understand it. It makes it easy for a password manager to apply it to a give password, but that isn't super helpful when it comes to generating a new password.
So that argues for some other way to convent this information, bringing us to...
2. Add a new attribute to some tag to convey this information. In HTML5, it is legal (as in doing so does not make the HTML invalid) to add custom tags if their name starts with "data-". A "data-format" tag could be added to the password input field, with its value being in some industry agreed upon format.
In prior versions of HTML, doing that would break HTML in the sense that it would not conform to the DTD. Not many programs actually care if what they are given as HTML conforms to the DTD, but those can be kept happy be a slight change to the DOCTYPE declaration.
Usually the DOCTYPE declaration just contains references to external documents that contain the definitions that actually make up the DTD for the document. You can also put DTD definitions right inside the DOCTYPE declaration. To make our new data-format attribute legal, all we need to do is append the appropriate definition in the DOCTYPE after the list of external references.
You think that sites that are unable to come up with sensible password rules will be able to get this right, on a large enough scale to make it useful?
In terms of the metadata, you've more or less covered it, but the only way it has a hope of being useful is if it's provided by some community-minded third party.
The person coding the webpage usually isn't the person who made the stupid password rules, so if putting in this metadata was considered industry best practice I think there is a decent chance it could become widespread.
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?
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.
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.
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"?
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.
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.
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.
When it comes to not allowing the usage of certain punctuation, I've always assumed it's because the person who wrote the code doesn't know how (or doesn't trust themselves) how to prevent injection so they just forbid the usage of characters that can be used for injection.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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)...
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”.
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. :)
85 comments
[ 4.6 ms ] story [ 166 ms ] threadThe 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.
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".
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.
AFAIK the reason for password history is where periodic password change is enforced, to prevent a user from just alternating between two passwords.
enforced periodic password change is (in the general case) not great for security, luckily we're starting to see official guidance which recognizes this https://www.ncsc.gov.uk/guidance/password-guidance-simplifyi...
Let's say it requires you to change it every month. You are compromised at max for a month, right? If the attacker changes the password, you will notice, and make a different password, which will lock them out since they don't know the new one. So they won't change it, but they will lose access next month. This is good...
Except if you allow repetitions of old passwords. In this case, the attacker can change your original password to 'aaaaaaaa' for a moment and re-change it back to the original one, which will reset the "one month" timer, leaving them with access. Until you change it, but the platform won't bother you with it since the timer never expires.
The more sensible approach is not to force periodic change and only change where there is a suspicion of breach.
It doesn't seem that common in the corporate world or typical web apps, though.
There's a not-uncommon pattern where someone gets an account compromised and starts a password tug-of-war. The attacker gets entry, and possibly changes the password, but doesn't own the recovery account, so the user finds the problem and uses email reset to change the password again. In this case, it's good to block the old (compromised) password, and bad to set a lockout that gives the attacker more time.
Of course, a lot went wrong in that story. Forcing email confirmation of all password resets can help, mandating re-typing of the old password for a change can help (against session hijacking, mostly), and any corporate or user-focused solution should probably have a response scheme for reporting and locking compromised accounts anyway.
But for social media style sites where the recovery system is "use your email recovery to fight for control", the reset time does seem like a threat.
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.
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.
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.
If they're creating a password with ß in it I'm assuming they know how to type ß, yes. I don't expect the average user to know how to type ß. :)
By not allowing non-ascii characters in the first place you remove a whole class of support issues.
Sabre Red is great: 7 or 8 characters, no Q, no Z.
Sites that don't cleanse the user input properly.
[1] https://www.xkcd.com/327/
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.
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.
Password managers that have browser integration could then use this to generate passwords acceptable to the site.
For password managers without browser integration, I bookmarklet could be developed that extracts the password format information and makes it available in a form that can be copy/pasted to the password manager, which could then remember it along with the other data for the site.
There are at least three ways that seem reasonable that could be used to convey the necessary information.
1. Make use of already defined attributes of the <input type="password"> field. In particular, there are three existing attributes that are very relevant:
• minlength: the minimum allowed length of input,
• maxlength: the maximum allowed length of input,
• pattern: a regular expression that the password must match.
By using lookahead matching in the regular expression, you can express rules like "must have at least one upper case English letter, one lower case English letter, one digit, and one special character chosen from @!#$%^&()". For example, pattern="(?=.[A-Z])(?=.[a-z])(?=.[0-9])(?=.[@!#$%^&()])".
A downside to this is that expressing the rules as a regular expression does not make it easy for a program like a password manager to understand it. It makes it easy for a password manager to apply it to a give password, but that isn't super helpful when it comes to generating a new password.
So that argues for some other way to convent this information, bringing us to...
2. Add a new attribute to some tag to convey this information. In HTML5, it is legal (as in doing so does not make the HTML invalid) to add custom tags if their name starts with "data-". A "data-format" tag could be added to the password input field, with its value being in some industry agreed upon format.
In prior versions of HTML, doing that would break HTML in the sense that it would not conform to the DTD. Not many programs actually care if what they are given as HTML conforms to the DTD, but those can be kept happy be a slight change to the DOCTYPE declaration.
Usually the DOCTYPE declaration just contains references to external documents that contain the definitions that actually make up the DTD for the document. You can also put DTD definitions right inside the DOCTYPE declaration. To make our new data-format attribute legal, all we need to do is append the appropriate definition in the DOCTYPE after the list of external references.
In terms of the metadata, you've more or less covered it, but the only way it has a hope of being useful is if it's provided by some community-minded third party.
In the end, what is more important: seeing the situation improved or just complaining?
Until someone gets ahold of a list of the hashed passwords and can brute force them at home without triggering the lockout.
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.
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.
[1] https://en.wikipedia.org/wiki/%C3%9F
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.
Feel free to submit a PR if you like.
I know Thomas Cook did this with their pre-paid forex mastercards which I happen to use while travelling abroad.
I think the idea is that they are worried that their customers will enter in their real, full password on something with a keylogger.
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.
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?
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. :)