Stop Blaming Users For Bad Passwords

Maybe it’s time to start blaming developers instead?

Alexander Anderson engraving from the 19th century (New York Public Library Digital Collection)

Another year, another vendor study about how users choose absurdly bad passwords to protect their precious online accounts. This year’s study came courtesy of Keeper, while prior years’ reports (for 2015, 2014, 2013, 2012, and 2011) came from SplashData, a password management service for small businesses. Spoiler alert, the most used password this year is the same as last year: ‘123456’.

Every time I see one of these “studies”, I die a little inside. It’s not because poor passwords aren’t a real problem, they are: proper authentication is critical to defending the mobile and desktop internet applications of today, and the Internet of Things applications of tomorrow. I hate these reports because they blame the victim, the user.

Oh sure, these articles might levy some small admonishment aimed at applications (“the bigger responsibility lies with website owners who fail to enforce the most basic password complexity policies”), but by and large the unspoken message is “look at how stupid users are for using one of these passwords.” These click-bait articles are designed to deliver a dose of Schadenfreude to the reader, and allow them to wallow in smug superiority while they giddily guffaw at gems like ‘123456789’.

“Oh look, some moron actually thought that was better than ‘123456’ — what a dolt!”

Everybody knows bad passwords are a problem. Everybody knows you shouldn’t re-use passwords across multiple sites. Everybody knows you should pick a password with a mixture of characters, but not a dictionary words (except, well, if you’re using a passphrase, in which case you should use dictionary words, but only the right way). Everybody knows all of this, and much more.

There’s just one problem: users just don’t care.

Just look at the stats over the last 5 years: some variant of ‘123456’ has appeared at or near the top of every one of these lists. Who’s the bigger idiot: the user for whom ‘123456’ keeps working and with little or no obvious adverse impact, or the apps and web sites that allow such bad passwords in the first place and ultimately suffer all the reputation damage or regulatory fallout?

These kinds of articles do little to advance awareness of a real solution to this problem, nor do they make much of an attempt to do so. It’s telling that such articles rarely mention the very real advances being made to address the problems posed by passwords, such as:

On that last item: there’s literally no reason to even ask the user for a password anymore. App developers can use both Touch ID and FingerprintManager to build password-less authentication schemes like FIDO (check out the video below). Right now. Today. Like, as I’m speaking to you. There’s even commercial SDKs that developers can just plug into their app to perform this function with minimal additional code.

FIDO Alliance’s protocols are one of the options to hasten the demise of passwords

Instead of blaming the user, how about apportioning some blame to the apps and their developers? How about calling out the applications that allow such ridiculously poor passwords? How about shaming sites that actively disable password managers? How about some link-love for sites like, which catalog which sites do and don’t support strong authentication options, and enable users to demand better?

But of course, that’s not the purpose of these articles. The articles aren’t about getting rid of passwords. They’re about positioning a vendor’s technology as a solution to this problem. Yes, a password manager when used properly is better than nothing. Yes, adding SMS two-factor authentication will reinforce poor passwords.

But passwords are an addiction, and these bolt-on half-measures are methadone. Heroine is bad, they say, but let’s not be too hasty about going cold turkey.

It’s time articles like this called out apps and developers to kick the password habit.

Originally published at on January 24, 2017.