Stop Blaming Users For Bad Passwords

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.

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 TwoFactorAuth.org, 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.

Three Features That Spotify Needs

Spotify Logo

For Christmas, Ashley gave me a Premium subscription to Spotify (the “all you can eat” music subscription service). I’ve been really impressed with the quality of the music, the selection, and the mobile application’s capabilities. It’s a whole different world when you can access the majority of humankind’s music at the touch of a button. Finally, someone has figured out how to make people stop pirating material: publish it all, publish it now, and publish it at a reasonable price that nullifies most people’s reasons for pirating music online.

That said, there are still a few features I would like to see added to the product to really make it shine. While Spotify does have capabilities for developers to build applications on top of Spotify, the current selection of applications are a bit weak. In many cases, they’re almost purely marketing ploys for various brands. Here’s some suggestions for apps that Spotify should either build themselves or encourage others to build.

Shazam Integration: Audio Discovery + “Bookmarking”

Shazam was a savior for me for a long time – nothing like being able to have a definitive answer to the question “what song is that they’re playing in this movie/theatre/coffee shop right now?”. However, using Shazam with Spotify is currently a multi-step process: open Shazam, tag the song to determine the song and artist, then switch to Spotify, search for the same song/artist, and add to a playlist for future listening.

Instead, as a user I want to be able to pull out my phone, start Spotify, and hit a button to determine the song and add it to a list for future listening. Think of it as the equivalent of Instapaper or Pocket, but for music instead of articles on the web. I should be able to use Spotify as a way of collecting interesting songs, wherever I hear them, and then queuing them for future listening.

Nike+ Integration: The Perfect Running Playlist Generator

When I go running, the music being played has a noticeable impact on my pacing. I regularly use the Nike+ running application my iPhone to play a running playlist, but the only music playback options are to play a pre-existing playlist in either a linear or “shuffled” order. My options to are either to spend a bunch of time building playlists, or to have a sub-par performance when a cool-down song comes on when I’m right in the middle of my run.

As a user, what I want is a way to have Spotify automatically generate a running playlist, based on the artists I follow or a radio station I’ve created. As an input to the process, the application should ask me about how far I intend to run or for what period of time. These inputs could be used to drive the selection of songs whose tempo match my target running pace, resulting in a subconscious signal to me to speed up or slow down my running pace. This playlist should be linked to the Nike+ running application, so that I can trigger this feature as the playlist for my run.

Life Soundtrack: Location/Context-Aware Radio

Often when I travel, I create a playlist to match the destination. Whether it’s a roadtrip where I’ll be driving to a destination or wandering around a strange city, I like to have music that I associate with a place. For example, nothing beats bursting through the doors of Healthrow Airport with The Clash’s “London Calling” at eleven, or strolling past the British Houses of Parliament with The Beatles’ “Tax Man” reminding you of one of life’s unavoidable certainties.

What I’d like to be able to do is have Spotify generate a playlist for me on the fly, based on my location. This playlist would select songs and artists that have a connection to my current context, including inputs like my physical location, the time of year, and my speed of travel. Combining that information with data about artists (where they were born, lived, performed) and songs (lyrical context, references to the current location, place where the song was written) would allow Spotify to construct a nuanced playlist that reflected my current surroundings, and provided a perfect backdrop to life.

Page 1 of 8612345...102030...Last »