Dumb Password Rules
github.com
github.com
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.
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.
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.
> - 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
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.
Sabre Red is great: 7 or 8 characters, no Q, no Z.
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.
Until someone gets ahold of a list of the hashed passwords and can brute force them at home without triggering the lockout.
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.
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.
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. :)
In the end, what is more important: seeing the situation improved or just complaining?
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?
Sites that don't cleanse the user input properly.