Oh, those incorrigible password abusers. After all these years of being shamed (if they cared or were paying attention), they’re still using “123456” as a password. This year, according to SplashData’s annual worst password list, that stale cracker came in at No. 1.
Again.
“password” was the No. 2 dust bunny to roll out from under the bed.
Again.
“Donald” made it onto this year’s list, at No. 23, as either a feeble nod to POTUS No. 45 or to the Disney duck. Or both.
This is what we always say: For shame. Unleash the cybersecurity Harpies, we say; let fly the mocking winged monkeys, etc. etc., yadda yadda yadda. The security industry, and the media that covers it, keeps trying to get across the message that simple passwords like that are too easy to guess: we’re talking about fractions of microseconds for a brute-force attack. And so, every year around listicle time, we suggest the fix of password composition policies.
Those are sets of rules such as “your password should be at least eight characters long and contain at least one uppercase letter, one number and one special character”. They’re popular because the rules are easy to check, and they increase the entropy of your password (which can be important, but it’s not the same thing as password strength).
Well, the shtick is getting old. As we’ve said before, composition rules are annoying (to everyone, even to people choosing really strong passwords); they measure something that isn’t password strength; and they restrict the pool of possible passwords (the “password space”), which just makes it all the easier for password crackers.
More to the point, while it’s true that, as SplashData CEO Morgan Slain says, “using your name or any common name as a password is a dangerous decision,” blaming the user clearly isn’t working. If it were, the same passwords wouldn’t keep showing up, year after year.
For this year’s list, SplashData says it evaluated more than five million leaked passwords. But it shouldn’t be surprising that the enormous cache contained so many celebrity names, terms from pop culture and sports, and simple keyboard patterns. They’re easy to remember. Of course people are going to use them…
…if websites and services keep allowing them to be used.
How about websites stop allowing 123456?!
There is another option. It’s not going to relieve our carpal tunnel, because it still involves finger-wagging. The option is for websites and services to simply stop users from choosing a password that’s on the list of the worst passwords. Or, say, disallow creating any of the 10,000 worst passwords.
The lists of worst passwords are brought to us courtesy of all the websites and services that accept feeble passwords. Disallow it, and you’ll never contribute to a list like this again.
Were your website/service to use zxcvbn – a password strength meter made by Dropbox (also used by WordPress and available to us all, for free) that actually tries to measure password strength – your users would have been warned if they’d chosen one of those terrible passwords.
Then again, if your website/service makes two-factor authentication (2FA) mandatory, then users would have been well-protected even if they’d chosen one of the awful passwords.
If your website/service uses rate limiting, then even the weakest password gets a serious upgrade. Limiting the number of times a user can try a wrong password means that attacks take a long time. Attackers have to be far more circumspect about how many guesses they make: just ask the FBI about how inconvenient, or impossible, it can make the task of forcing your way in past an unknown login.
None of this means that users are off the hook when it comes to picking a strong password, though. There’s no way to know that their passwords are being securely stored, and they have no control over the measures that sites use to defeat online guessing – aside from adopting 2FA whenever it’s available.
This all means that the onus is still on users to make sure that every password they choose is unique and strong enough to withstand an offline guessing attack. And it means that yes, websites still have to promote a password composition rule: make each password a random collection of at least 14 letters, numbers and special characters.
And users, if you can’t remember all of your passwords – and how many of us can? – you can always rely on a password manager to keep them safe.
🇨🇦 SkepticalScott (@ScottDouJohnson)
I let Google Chrome create random passwords for me. The only passwords I know are my Google account, ATM pin and phone pin. Easy to remember 3.
Epic_Null
How do you get your password when you want to use something other then chrome though?
Damien J O'Brien
1Password. for Mobile. or PC, Max what ever. even an online version but it’s so secure it’s hard to log into even if you know the details.
speeddymon
I switched to unique passwords for each site and it wasn’t that difficult. Start with the top 5 sites you use (Facebook, Google/Gmail/Yahoo, Twitter, Instagram, etc) and make sure to enable 2 factor authentication.
One of the best things I’ve discovered about this is that you can actually keep your backup codes for your 2FA in your password manager, so you never have to worry about losing access to your accounts if your phone gets lost or stolen.
Anon
I’d be careful storing your 2FA backup codes or QR/seed in your password manager. If you do, and someone gets access to it, then they can access all of your accounts. It is much better than not using 2FA but it does potentially weaken it as you are storing both factors in the same place. I prefer to print out my backup codes and also the QR code/seed and store them in a safe place (fireproof safe/bank deposit box). With the QR code printed you can add a new device at a later date by just scanning it again. I also scan my important 2FA QR codes on a 2nd device (significant other’s phone works well for me).
Larry
Last week I registered with the pharmacy benefit manager of my medical insurance and their password rule dictated a MAXIMUM of 8 alphanumeric characters, which is not the first time I’ve run into that ridiculous restriction. I use a password manager and it’s quite common to have to constrain the password generator because of length restrictions or specifying only a small subset of allowed special characters (if any). A company that I contracted with many years ago had an internal application that stored passwords by XOR’ing them with the phrase “Mickey Mouse”. It seems appropriate for many of the public-facing login security methods being used today.
kbeck (@kbeck)
Note that as far back as 1985, it was a best practice (Green Book) to generate secure passwords for users so they couldn’t pick a weak password.
Christopher Bell
Why not in parallel to campaigning against rubbish passwords, also campaign against the number of sites one has to log into. Obviously logging into you bank account is vital. However do you really need to setup an account every time you buy a book or download a white paper
Chris
anarchduke
of course it is. if you don’t login to every website, how can they sell your personal information to advertisers?
Mark Stockley
With a 3rd party cookie! The advertisers don’t need to know your name, they’re interested in your demographics, habits and interests, and for that they only need to know that you’re user ID 0879e1a7aa59b639a609aaf3dc41bf39.
Matt Parkes
Shameless plug but organisations should consider integrating Troy Hunt’s pwned passwords API that will tell you if the password you are choosing is already in a well established data breach. Even better ditch the password for a FIDO certified key or maybe 2 like Google’s Advanced Protection scheme.
Fred Higgins
Spot on!
kimwyattsart
Maybe I’m being naive, but what if a password manager site gets hacked?
Mark Stockley
Password managers deal with this scenario by encrypting your data using a key that never leaves your computer. Maria covers it in her article “Cloud storage for password managers – are you for or against?”.
https://nakedsecurity.sophos.com/2017/11/24/cloud-password-managers-would-you-use-one/
Boone
Great article.
I think following NIST’s Special Publication 800-63B is a great way to handle this weak authentication problem we continually run into…
Gee
This article not structured at all, such a shame.
Cetin A.
I wonder what is the method to determine the actual passwords used in the wild so that you can come up with this statistics. Isn’t the server side “not” supposed the know/store clear text password, but only a hash of it?
Mark Stockley
Breaches.
Anon
In many cases the websites are not implementing the hashing algorithms properly, not using hashes designed to store passwords (bcrypt vs MD5), or just being lazy and not even bothering to hash them.
Paul Ducklin
The “data” here doesn’t offer any evidence that these passwords were revealed through unhashed or improperly hashed passwords. There’s no methodology given – no explanation at all – of how came up this list was constructed. For all you know, Splashdata might have picked a few thousand strongly-hashed passwords from various breaches and tested those hashes against a very short dictionary that ust happened to include the obviously-bad passwords in this list. (Amusingly, the “top 50” password list has only 49 entries, which doesn’t seem like the sort of precision you might expect from so specific a claim:&$45;). Or Splashdata could have relied entirely on hashes it knew it could crack from sites it knew had poor hashing policies, which says nothing about how prevalent that practice is. Or Splashdata could have run a pseudonymous “phishing” campaign to see what people were prepared to type in as passwords, thus sidesepping the issue of hashing and cracking entirely. Or the company could have stumbled across a stash of passwords acquired through keylogging, where the password is sniffed out before it’s even transmistted, let alone hashed and stored.
There’s nothing about this data that suggests these are the 50 most prevalent passwords – just that they’re what Splashdata considers the “50 [OK, 49] worst passwords.” The list could even be made up, populated with what Splashdata consider to be the worst passwords people could have chosen – IMO that would still be fine, given that the list isn’t pretending to be research about how passwords get chosen or stored. It’s more of a seasonal reminder that at least some people still pick rubbish passwords, and at least some of those passwords will make it easier for crooks to get into accounts.
I’m sure there are plenty of sites that are still awful at storing passwords, but to insist that this still happens “in many cases” probably needs some testable evidence. My own experience is that proper password salting-hashing-stretching is becoming much more common…
…though admittedly that’s based mostly on statements made in breach notifications (and breaches aren’t supposed to happen, whether you hash your passwords a lot or a little).
Anon
Very good points. I think you said it right here though: “proper password salting-hashing-stretching is becoming much more common”. It is becoming much more common but many of these password lists are from breaches where the data was not secured properly (maybe not SpalshData specifically but that’s how Have I Been Pwned gets much of its data). Due to the media coverage (Thanks Naked Security!) many companies are now using proper hashing and storage techniques.
Anon
Here is a link discussing the Under Armor MyFitnessPal breach. Passwords were poorly hashed for at least a portion of the data. Same with Ashley Madison. [URL removed]
rhiadratech
Worst password policy? A mmo which will not let you use a password any other user has.
Thanks for telling me someone else’s password…
Mark Stockley
It’s not a list of passwords already used on that service, it’s a list of passwords a password guessing algorithm will start with.
Mark Stockley
…known only the NSA ;)
Burnsie
is it me or are there only 49 passwords listed?
Just what is number 50?
Is it a secret password that unlocks every account?
Steve
Since the list started with #49 at the top, that would have been password #0 at the end of the list, the worst one of all, so it must have been a null byte, i.e. NO PASSWORD AT ALL!
Bob
1234567 didn’t make the list, I’m safe!