Slashdot Mirror
Slashdot Asks: Are Password Rules Bullshit? (codinghorror.com)
Here's what Jeff Atwood, a founder of Stack Overflow thinks: Password rules are bullshit. They don't work.
They heavily penalize your ideal audience, people that use real random password generators. Hey, guess what, that password randomly didn't have a number or symbol in it. I just double checked my math textbook, and yep, it's possible. I'm pretty sure.
They frustrate average users, who then become uncooperative and use "creative" workarounds that make their passwords less secure.
Are often wrong, in the sense that they are grossly incomplete and/or insane.
Seriously, for the love of God, stop with this arbitrary password rule nonsense already. If you won't take my word for it, read this 2016 NIST password rules recommendation. It's right there, "no composition rules". However, I do see one error, it should have said "no bullshit composition rules". What do you think?
They heavily penalize your ideal audience, people that use real random password generators. Hey, guess what, that password randomly didn't have a number or symbol in it. I just double checked my math textbook, and yep, it's possible. I'm pretty sure.
They frustrate average users, who then become uncooperative and use "creative" workarounds that make their passwords less secure.
Are often wrong, in the sense that they are grossly incomplete and/or insane.
Seriously, for the love of God, stop with this arbitrary password rule nonsense already. If you won't take my word for it, read this 2016 NIST password rules recommendation. It's right there, "no composition rules". However, I do see one error, it should have said "no bullshit composition rules". What do you think?
Yes.
"Slashdot Asks: Are Password Rules Bullshit?"
I don't know. But headlines with "Bullshit" and "?" are.
Coder's Stone: The programming language quick ref for iPad
The problem is now that the bullshit rules are now expected by customers. When we did our last major UX review, we didn't have those rules in place. Adding them made our customers overall feel more confident in our platform.
It's "cargo cult" requirements. People are so used to the security theatre of the password rules that when they come to specify what their system should do they put in all of this stupidity, They don't actually read NIST guidelines. Maybe we should lobby for some kind of certification mark - and the people who assess it would have some clues.
Also, please for god's sake let me see what I type. I have 99% of my passwords in a password manager, but not all of them, and sometimes i'm on a different device where I don't feel like logging into it if i actually know the password. Sometimes its the login of the machine itself, so unless I'm using a dongle for loging in, I'll have to type the password.
if I can't see it, and god forbid we're on mobile, I'll have to make it significantly simpler to ensure I don't fat finger shit 19 times.
That's especially true with devices. I already mentionned mobile, but game consoles, smart thermostat, and all the IoT bullshit (some are actually useful). They force me to type my password blindfolded on unfamiliar input devices. If my password is 25 characters, I'm going to make mistakes. Let me see them please.
https://www.xkcd.com/936/
I don't mind too much the simple ones like must have a symbol, one uppercase, and a number and a minimum of x characters. Those are fine because I can click those buttons in Keepass to generate a password with or without those options.
The ones that piss me off are ones that only allow/require a very small set of symbols, so I have to generate it and tweak it.
The other big thing that makes me angry is when their password requirements are hidden. You just have to keep typing in passwords until their validator stops bitching at you. Why are these requirements not up front?!!
The idea of a password rule, as in some set of checks to make sure it meets a certain level of security, is a good one. However it needs to be something complex like entropy calculation. A password can have lots of entropy, and thus be strong (meaning hard to guess/crack) in a number of ways. A truly random set of characters has lots of entropy per character, but a phrase can have plenty, even though it has much less per character and can be easier to remember.
It shouldn't be some hardass thing of "you have to have 3 of 4 groups, no repeating characters, etc, etc". If you want an all numeric password, that's fine, it'll just need to be longer. Test based on actual entropy, not arbitrary bullshit.
Or, if you really care about security, start doing two factor. It always amuses me when some place has ultra-bitchy password rules but has no options to use even weak two factor auth. They care about security, apparently, but not enough to do anything that might be really useful.
Just say no to most of the things that require a password. Most of them are worthless anyway.
Only post anonymously to /..
Quit forums and registration-only websites. You'll find you're getting more free time and less Internet-induced anxiety.
Scuttle your StackOverflow account. It's taken over by H1Bs.
For professional work, use other means of authentication such as crypto keys. Manage professional accounts with password manager and 2fa.
Use long passphrases and 2fa for local logins. Scrap stuff like "cloud" storage because they're there to TRACK YOU.
Get a dumb phone and set up Sim card PIN lock and screen PIN lock.
The password rules wouldn't be quite so annoying if they could agree on a common set of rules. Website A wants caps, numbers and no special characters. Website B wants special characters, caps and numbers. This means more passwords, more permutations of passwords and the end result is worse security because of all the problems with forgetting passwords. I don't know that there is an easy solution but a start would be to have the same password rules everywhere whenever possible and they should follow whatever the currently acknowledged evidence based best practices are. (balancing usability with security of course)
Making the problem worse is every f***ing website wanting you to make an account with them even when doing so is of no benefit to me. Guest checkout should ALWAYS be an option. I'm not going to become a repeat customer because you make me create an account. I'll become a repeat customer because your service and prices rock and you provide something I need.
I've always thought password rules probably made it easier to crack passwords. Password has to be between 6 and 10 characters? Great, that cuts out a huge range of potential passwords. Password has to have a symbol? That pretty much guarantees 'a' will be '@' and 'i' will be '!'.
How about this reason: I don't care for the account in the first place.
Simple scenario: I want to use a website once, but it requires me to "register an account". Why? No idea. I have absolutely no need for one and don't care if it's "hacked". For all I want, you can throw it away immediately. So I'm going to register the following account.
Username: johndoe123
email: johndoe@mailinator.com
password: 123456
Go ahead, "hack" my password, reuse my account, whatever. I don't care.
Once the site gets breached, I'm another data point for "people still use the world's worst password?!"
It's right there, "no composition rules". However, I do see one error, it should have said "no bullshit composition rules".
But you repeat yourself....
Also in there:
Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically) and SHOULD only require a change if the subscriber requests a change or there is evidence of compromise of the authenticator.
Holy crap, sanity!
Also need to scrap the minimum change interval some things impose (you *can't* change your password, even if you know you exposed it to someone accidently).
I'd also want to be very careful about account lockout policies. Yes, they are a tool to rate limit an attacker, but they are *also* a vector to DoS an account by locking it out on purpose.
XML is like violence. If it doesn't solve the problem, use more.
. . . .that don't tell you their password rules, only that your password doesn't fit them. This is especially irritating for the sites that require complex passwords and have short (i.e. 3 fails) lockouts. . . .
Even aside of the obligatory xkcd comic that will certainly still surface, password rules are at best useless. At worst they lead to behaviour that is detrimental to security.
So how long do they now have to be? 12 characters at least, no words from a dictionary, containing all sorts of numbers, special characters, upper/lower case, no semblance to any passwords used within the last 60 years... resulting in such great passwords as f$nUkw1dfvM(qkI and so on.
How to remember that? Not at all. What do people do? They write it down. If you're a lucky CISO, they put the post-it into their wallet. If you're not, you find it under their keyboard.
Sure, you can demand that they don't write it down. Then be prepared to drown your support in calls from users that have to get their passwords reset twice a day. Once when they come in, once when they return from their lunch break.
And all that because we are lazy. Yes, we. The company security. We brush off our business, i.e. securing access, onto the user. And why the fuck do we get away with that? Please tell me. It's OUR job to make machines secure, not the user's.
Security is best when you achieve total security without the user even noticing you're there. Perfect security means that little, better even no, user interaction is required. The less the user could possibly fuck up, the better for your security. And yes, that is possible. Replace a "what you know" security model with a "what you have" one, i.e. hand key cards to your personnel. If you really feel like it, augment it with a 4 digit pin they can set. That's already enough.
But brushing off security onto your user and putting insane demands on him is unacceptable.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
What confuses me the most about common practices is the small number of attempts many platforms allow before they lock your account. How did three tries become standard? I could understand if the password was an atm code, with 10k possibilities, but many of these platforms require fairly strong password to begin with. I often enter one or two incorrect passwords if I am not paying attention - caps lock, typo, num lock, etc. Is allowing 10 attempts really that much more of a vulnerability?
When my passwords get pwned, at least I can change them. When my biometrics get hacked? I'm SOL.
Slow down, cowboy! It has been 4 hours since you last posted. You must wait another few hours.
The bullshit is not in the passwords, the bullshit is in the people. Or rather, demanding that people remember that character salad.
Yes, those passwords are great. Especially "&2lkjf(82ld0*@#jmG73". Awesome, strong and secure. And now have a person remember this. No chance. None. Zero. Zip. Maybe there's some dedicated aspies that can, but most of the people you have in your office will look at you like you asked them to do a multidimensional integral in their head. Or they'll question your sanity.
What will people do when you require such passwords from them? They will write them down. Turning a "what you know" access situation into a "what you have" one. That by itself is no problem yet. The problem is that you don't know where they'll keep that post-it. If you're lucky, they take it with them in their wallet. If you're not, they stick it under their keyboard or put it into their drawer.
And that is where demanding such a password actually reduces security.
And this is why they're bullshit.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
I have been annoyed by this for a long, long time. Put in a 100bit+ entropy password and the moron that implemented this has his software claim that your password is "insecure". Seriously, all lowercase letters and digits at random is about 5.2 bit/character in entropy. Lowercase letters, digits and a special symbol (and who does not just append a "!") and an uppercase letter (and who does not simply make that the first) is, *ta-da* 5.2bit/charabter entropy! Of course, making random places uppercase or a random symbol would be a bit better, but even that would only be 6.1bit/character in entropy (with 10 possible special symbols), i.e. it does not really matter.
Password rules are complete and utter nonsense perpetrated by people that value rituals over understanding and that, in addition, have none of the latter. Of course, many things in IT today are done by ritual and not by understanding, but this is one of the most stupid ones.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
The problem isn't password rules. The problem is the idea of security levels.
For a site like /. or soylentnews.org, just about any password should be allowable. This is a password you will likely use on lots of different sites. Also, the password should never expire. Account should be locked if a thousand bad passwords in a row are tried. The password reset should go to your email, and you should not have the ability to change your email address (but you can add a secondary email address) for a month after a password change. That way if someone breaks into your account you can get back in afterwards.
For your home computer, it should also allow any password. Passwords should never expire. The account should never be locked but you have the option of added security (ie: encrypted home directory).
For work, a more complex password that changes every six months to a year.
For your banking, a complex password that changes every year or two. Account lockout if 10 tries in a row fail.
For your email account, two factor authentication all the time and a password that needs to be changed every 3-6 months (since your email is used as a lockout to all the other possible accounts).
Help! I'm a slashdot refugee.
Make sure the creases in your aluminum hat are sharp and at a 60 degree angle.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
Depends on the security questions. For example, a few of them that I use:
"What is the surname of your last parole officer?"
"What was the judge that signed your last peace bond?"
"What items were in the property room the last time you made bail?"
"What street was it that you were arrested on?"
"How many inches deep a grave did you did for the bodies?"
"When you were arrested for DWI, how many feet did you make it with the sobriety test before falling down?"
"Was was the badge ID of your last arresting officer?"
Those tend to be fairly hard to find, as opposed to someone's dog name.
Think of the big breaches, which I tracked until about five years ago... In the Zappos breach, hackers broke into their system and stole their database. They didnt guess passwords, just stole them.
In May 2005, GMail was hacked... via JavaScript, exposing contacts, personal data without cracking (or exposing) passwords.
When CardSystems Solutions (a payment processor) was hacked and 40 million credit card numbers stolen, it was by SQL Injection. Fust full names, addresses and passwords exposed without any password guessing.
TJX (TJ Maxx, a retailer) lost 45 million credit card records in a hack... by unprotected WiFi and unencrypted records.
Google's AdWords system by surrupticious files being installed. User passwords were stolen.
About ten years ago, Internet Explorer (yeah, I know...) facilitated look-alike sites to steal Hotmail (Microsoft), GMail and Yahoo passwords... but complexity or guessing were not the issue.
When Epsilon Data Management was hacked, it wasn't via guessed passwords, but they were stolen, compromisingcustomer accounts on Citibank, Chase, Target, Walgreen and Best Buy.
LinkedIn, the professional networking site, had six million passwords cracked-and-leaked in June 2012. The process was an attack on the server storage encryption, not on password strength.
The stupid thing was, when Zappos was hacked (again, not via password theft), they then decided to impose stringent password requirements. Amazon doesn't have such stringent requirements, so just for ease I've switched most of the purchases (about four a year) I used to do from Zappos over to Amazon.
Indeed. I have a password that I use for all of the diverse sites that I don't give a rat's arse about. What's someone going to do if they compromise it, make fake posts as me? Ooh, shudder.
The big brain am winning again! I am the greetist! Now I am leaving for no particular raisin!
My first act upon entering my last workplace:
- Remove enforced 30-day password resets that could only be done via IT (500+ users means two tickets a day, at least, were just password resets - and imagine what that does to remote workers who then can't get into remote desktop or email to request a password change anyway!)
- Remove "password history" requirements that were onerous and made people invent - and therefore forget/lose - passwords all the damn time or just use numbers tacked on the end.
- Remove all complexity requirements from passwords, except minimum length.
- Encourage people to choose a small set of GOOD passwords, which I promise I will not invalidate every month, and use them well (e.g. if one system requires another to work but gives NO MORE access to data than the first, they may as well use the same password!).
- Stand up once or twice a year in all-staff meetings and gently remind them to change their password, oh and by the way, I was the guy who stopped you having to change it every single month so you might want to pay me the courtesy of actually doing so.
- Demonstrate, as a mathematician, the thing that the XKCD cartoon does - LENGTH MATTERS, ALPHABET COMPLEXITY DOES NOT (*).
The staff loved me for it, it's totally compliant (passed through security audits, DPA audits, etc.), backed up by official NIST, GCHQ, etc. advice and all kinds of computer security experts and it works.
Number of account compromises: 0 in 3 years.
Number of account password resets required - ONE THOUSANDTH of what it used to be.
(*):
Adding a single character to the alphabet available increases brute force times by a factor of 1/(size of previous alphabet), e.g. one-twenty-sixth more.
Adding another character - using the same alphabet - to the length of a password increases brute force times by a factor of (size of previous alphabet), e.g. TWENTY SIX TIMES MORE.
A 10-character, only A-Z, a-z password takes TWICE AS LONG to brute-force as an 8-character, every-ASCII-character password.
they could extract various 4-character permutations, and store a salted hash of those characters along with their positions within the password.
The organisation I work for used to do exactly this. Then one day they decided that they would use a hardware password vault, with the ability to verify the password combinations. The problem was that to move to the vault we would either have to get access to the full password or get everyone to re-register. The business said to me "is there anyway you can get the original password". My initial reaction was "no - it's hashes the password isn't stored", but after a litte thought I realised that the first 4 character combination was basically a 4-character password. A naive brute force could crack it in about 45 seconds. Optimizing simply so that it would try the most common letter combinations first reduced that to under 20.
Having obtained the first four characters XXXX---- finding the subsequent ones XXX-X---, XXX--X-- and so on is sub-second, you only have to find one character each time using the appropriate hash. Cracking the whole customer list took just over 2 days
The current solution uses multiple passwords each of which are known to only one role of person, something in the hardware unit, a value put in the database by the DBAs, and a value set in a file by devops. We know that encrypting the password is not the most secure method but the reason that we use the "4 from n" is we see the risk as asymetric; there is a much larger chance that the customer's PC will be compromised than our systems. Also over a certain limit we require two-factor authentication.
It's not a password policy that makes you more secure, it's enforcement. You need to perform standard dictionary checks to prevent "password1234", detect crap QWERTY strings, ensure the password has a reasonable length, and allow _all_ special characters (space, tab, &, *, etc..). That latter is a problem with many banks, who disallow most special characters if they allow any at all.
If you force people to use stronger passwords you will not be susceptible to brute force attacks unless you don't monitor or throttle login attempts. What you may have is people using sticky notes and plain text files stashed on their PCs, but pointing them to a good password manager (keepass/keepassx) fixes most users who find those more convenient than rooting around for files and papers.
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
Ok.. It depends.... Password rules, like anything, when used within reason CAN increase security.
There has been some research which arrive at the conclusion that yes, indeed, password rules are actually bullshit for security.
As mentioned in the summary, enforcing password rules will actually block provably safe passwords :
- a base32 encoded 128bit pure random number. It's mathematically provable to be secure (if done by a cryptography-grade true random number generated, it's a 2^128 security, which is pretty good enough). But it's a 25 character long string of alaphanumeric. So it's not mixed case, and doesn't contain punctuation so it will be rejected by most stupid rules (also some rules have size specified as a range [9 to 16 characters], not a minimum [more than 8]. This will also reject a 25-long password).
As shown in presentations at numerous presentation in conferences such as CCC :
- even a complex rule set (Mixed case, must contain numbers and punctiation, at least 9 characters long) will usually give results such as "Denver17!"
Which are a lot less secure because they follow a general pattern (The first letter is the single capitalized, number come at the end, punctuation is the last and 9 out 10 times it's a '!' ). Most of these "rule abiding password" follow one of very few such patterns, and patterns are alarmingly easy to crack.
As such, no matter what, rules are a bad idea.
On the other hand, password managers with a generation function (like the above 128-bits equivalent password) are definitely a good idea.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
storing them in their wallet or purse
When I was on a corporate security we actually used to suggest this! You could gbe disciplined if you were caught with a password on a sticky note attached to monitor or under a keyboard but we told people it was okay to write them down if they must provided they keep it in their wallet or purse. This was our official policy.
Why?
Most people notice a wallet or purse missing almost immediately! Certainly within hours. Which is still on the pretty good end of compromised password detection. We simply told them if you choose to do this you need to add corporate security to the top of your list of who to contact when your wallet goes missing, the same way you'd call your CC company. Someone on the CIRT team would change your password or simply lock your account if you are unable to participate in the change process at that time.
The reality is unless you allow weak passwords they are going to get written down, so best enable people to do that as safely as possible. I know people still hate mandatory password rotation here but honestly its a good control if done properly. Lets say like not more often than every six weeks, and at least every 12. Its still a good detective control, will cause a compromised account to be noticed eventually or the attacker will lose access. It will still ensure unused accounts are eventually locked out (admittedly a last login audit could do this one too).
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
Ditto those stupid 'KBA' (knowledge-based authentication) questions, which are even worse:
1. Who on God's earth thinks asking "What was the make of your first car?" is remotely secure? Ford, Honda and Toyota together make up over 30% of all the cars on the roads!
2. once a database on these is cracked/leaked/left-in-a-public-restroom I can never change "the first concert I went to" making that answer insecure for the rest of my life, but I'll probably never know that.
3. I find myself looking down the options going: well, none of these apply. I don't have a favorite baseball team. I didn't have a nickname when I was a kid. I don't want to give you gobs of biographical information. I guess I'll have to make something up, and then forget it.
None of the security of biometrics, with all the irrevocability. I can't figure out why these were ever thought to be a good idea.
'This writing business. Pencils and what-not. Over-rated if you ask me. Silly stuff. Nothing in it' - Eeyore
Just to add insult to injury, those fuckers started adding third party web sites for services like project planning and some employee incentives. And those third party web sites also had their unique password requirements. I eventually arrived at the conclusion that most of their employees were so busy maintaining their passwords that no other work was getting done inside the company.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
And now ponder needing this password once a week. Still memorable?
Also let's not forget that we are dealing with people here who have anything but security on their mind. They want to get their work done. Security is for them, at best, a nuisance. At worst something that stands between them and doing their work.
Take a security door that swings closed after someone went through. Now imagine someone who has to carry heavy boxes through this door. This would mean that he carries the box to the door, opens the door, carries the box through and closes the door again. And that repeatedly. How long do you think it would take until he finds a wedge to keep the door open? And without any remorse because that way he can do his work more efficiently.
Security MUST NOT weigh down the worker. If it does, the worker will treat it as a defect and find a way to work around it.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
For those types of security questions, I pick a favorite character from a radio program, or tv show. Tada!
What was the model of your first car? Marty McFly -> Delorean.
What study?
I'm kind of lazy to google all the sources by my self.
The general approach is *pattern-based*.
I pointed to a presentation on youtube but there are other independent research all arriving at the same conclusion.
They are mostly done by applying pattern-based cracking either to leaked hashes databases or to hashes databases volunteered by organisations.
so it's not theoretical works, it's mostly noticing what is happening in the wild when your try enforcing password rules.
doesn't mean they are totally BS. {...} But OBVIOUSLY password rules force the user to avoid the common pitfalls in password selection and will more likely cause your users to have passwords that are not easily cracked.
The problem, as discovered among other on the presentation in my previous post, is that by trying to avoid common pitfalls in password selection:
- not enough variations if password are all lower-case only caracters (It's only 26 symbols per position)
you do not actually avoid the pitfalls
- if applied accurately that would give 26 lower + 26 upper + 10 digit + even more punctuation per position
but push the people into a different set of pitfalls.
- people are lazy. most of the time, it was discovered, they'll just upper-case the first letter and slap the required extra digits at the end. And add '!' afterthat if they can't get around punctuations. That's still 26 possibility per position, with a few more things (nearly negligiable) at the end.
So... what's easier to guess "password" or "Denver17!" ? I know what I'm going to bet gets broken first..
Both are in the "basically worthless" category.
the first one is straight out of a word list.
The second follows one of the most common patterns: "Llllll##?".
In theory, if a user used all possible characters at any position, you'd be getting "26 lower + 26 upper + 10 digit + 10punctuations" = ~approx 74 symbols per position. A 9 character long password would in theory get 74 ^ 9 or approximately 56bits of security. Not much, but still something.
In practice, most password abiding the rule will be one of the few common pattern such as above.
Without taking dictionary into account, only the symbols at each position of the pattern, the above is 26 ^ 6 * 100 * 10 or only 38bits of security.
You lost about 18bits of theoretical security, just because your users are lazy as shit.
There is about a dozen of such overwhelmingly common patterns (so you're looking at best at 41bits security. If you only use salted hashes in you password database and it gets leaked, the vast majority of your user passwords will get cracked appallingly fast).
And that's without factoring in dictionaries. (Look at all the 6 letter words that you can fill in the first part of the pattern, first use a few common combination for the numbers (current year, '13', '69', etc.) and you can basically go for '!' and leave the rest of the punctuation later). At that point, in case of a database leak, tons of password will get insta-cracked and the attackers can already start probing for password reuse even before the end users has had enough time to be alerted about the leak.
You want to stack the deck in your favor where you can, so if that means forcing your users to follow some rules in password selections gets you 50% more secure passwords.... Do it..
In practice , you only get marginally better security, because the users will resort to simple schemes just to get around the rules.
People are lazy and will resort to the simplest pattern possible just to get around the rules.
In this case, I'm not inclined to believe password complexity rules are just bad,
Their are bad in that they push non-security-minded end users to do things which are nearly entirely predictable for the password cracker.
i.e.: they are actually not adding any significant amount of securit
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
I use 999999999 for all my passwords because it will take an attacker nine hundred and ninety nine million guesses before they get it.
HA! I just wasted some of your bandwidth with a frivolous sig!
None of this is magic. We have known that this is required of IT security since the mainframe days. Defense in depth with different security layers is not just a good idea. It is central to all effective defense planning for thousands of years. However, instead of doing good IT security, we attempted to push the burden and failings of IT onto the users via complex password rules.
Of course, there should be some password rules. They should look more like:
WINDOWS: Please enter your new password.
USER: cabbage
WINDOWS: Sorry, the password must be more than 8 characters.
USER: boiledcabbage
WINDOWS: Sorry, the password must contain 1 numerical character.
USER: 1 boiledcabbage
WINDOWS: Sorry, the password cannot have blank spaces.
USER: 50fuckingboiledcabbages
WINDOWS: Sorry, the password must contain at least one upper case character.
USER: 50FUCKINGboiledcabbages
WINDOWS: Sorry, the password cannot use more than one upper case character consecutively.
USER: 50FuckingBoiledCabbages ShovedUpYourAssIfYouDon'tGiveMeAccessNow!
WINDOWS: Sorry, the password cannot contain punctuation.
USER: ReallyPissedOff50FuckingBoiledCabbages ShovedUpYourAssIfYouDontGiveMeAccessNow
WINDOWS: Sorry, that password is already used.
The problem was that to move to the vault we would either have to get access to the full password or get everyone to re-register.
There are two ways to do that. One is to require all users to go through password recovery, as you mentioned. The other is to prompt the user for the full password next time he logs in, and then once it matches the hash, transition that user to the vault for subsequent sessions. Users who do not log in at all during the month of transition to the vault would have to recover.
Worse than that are the systems which silently truncate at a set length, or at the first unacceptable special character. Or which truncate at password creation, and handle logins with a different parser...
I do not deploy Linux. Ever.