Journal tags: password

Two-factor authentication is generally considered A Good Thing™️ when you’re logging in to some online service.

The word “factor” here basically means “kind” so you’re doing two kinds of authentication. Typical factors are:

• Something you know (like a password),
• Something you have (like a phone or a USB key),
• Something you are (biometric Black Mirror shit).

Asking for a password and an email address isn’t two-factor authentication. They’re two pieces of identification, but they’re the same kind (something you know). Same goes for supplying your fingerprint and your face: two pieces of information, but of the same kind (something you are).

None of these kinds of authentication are foolproof. All of them can change. All of them can be spoofed. But when you combine factors, it gets a lot harder for an attacker to breach both kinds of authentication.

The most common kind of authentication on the web is password-based (something you know). When a second factor is added, it’s often connected to your phone (something you have).

Every security bod I’ve talked to recommends using an authenticator app for this if that option is available. Otherwise there’s SMS—short message service, or text message to most folks—but SMS has a weakness. Because it’s tied to a phone number, technically you’re only proving that you have access to a SIM (subscriber identity module), not a specific phone. In the US in particular, it’s all too easy for an attacker to use social engineering to get a number transferred to a different SIM card.

Still, authenticating with SMS is an option as a second factor of authentication. When you first sign up to a service, as well as providing the first-factor details (a password and a username or email address), you also verify your phone number. Then when you subsequently attempt to log in, you input your password and on the next screen you’re told to input a string that’s been sent by text message to your phone number (I say “string” but it’s usually a string of numbers).

There’s an inevitable friction for the user here. But then, there’s a fundamental tension between security and user experience.

In the world of security, vigilance is the watchword. Users need to be aware of their surroundings. Is this web page being served from the right domain? Is this email coming from the right address? Friction is an ally.

But in the world of user experience, the opposite is true. “Don’t make me think” is the rallying cry. Friction is an enemy.

With SMS authentication, the user has to manually copy the numbers from the text message (received in a messaging app) into a form on a website (in a different app—a web browser). But if the messaging app and the browser are on the same device, it’s possible to improve the user experience without sacrificing security.

If you’re building a form that accepts a passcode sent via SMS, you can use the autocomplete attribute with a value of “one-time-code”. For a six-digit passcode, your input element might look something like this:

<input type="text" maxlength="6" inputmode="numeric" autocomplete="one-time-code">

With one small addition to one HTML element, you’ve saved users some tedious drudgery.

There’s one more thing you can do to improve security, but it’s not something you add to the HTML. It’s something you add to the text message itself.

Let’s say your website is example.com and the text message you send reads:

Your one-time passcode is 123456.

Add this to the end of the text message:

@example.com #123456

So the full message reads:

Your one-time passcode is 123456.

@example.com #123456

The first line is for humans. The second line is for machines. Using the @ symbol, you’re telling the device to only pre-fill the passcode for URLs on the domain example.com. Using the # symbol, you’re telling the device the value of the passcode. Combine this with autocomplete="one-time-code" in your form and the user shouldn’t have to lift a finger.

I’m fascinated by these kind of emergent conventions in text messages. Remember that the @ symbol and # symbol in Twitter messages weren’t ideas from Twitter—they were conventions that users started and the service then adopted.

It’s a bit different with the one-time code convention as there is a specification brewing from representatives of both Google and Apple.

Tess is leading from the Apple side and she’s got another iron in the fire to make security and user experience play nicely together using the convention of the /.well-known directory on web servers.

You can add a URL for /.well-known/change-password which redirects to the form a user would use to update their password. Browsers and password managers can then use this information if they need to prompt a user to update their password after a breach. I’ve added this to The Session.

Oh, and on that page where users can update their password, the autocomplete attribute is your friend again:

<input type="password" autocomplete="new-password">

If you want them to enter their current password first, use this:

<input type="password" autocomplete="current-password">

All of the things I’ve mentioned—the autocomplete attribute, origin-bound one-time codes in text messages, and a well-known URL for changing passwords—have good browser support. But even if they were only supported in one browser, they’d still be worth adding. These additions do absolutely no harm to browsers that don’t yet support them. That’s progressive enhancement.

Two months ago, I called Twitter out on their insistence that developers use OAuth when authorising with Twitter while they themselves continued to use the password anti-pattern when they wanted to peek into third-party address books.

I’m happy to report that Twitter have since fixed this. If you go to the Find Friends portion of the “Who To Follow” section, you’ll now be greeted with links that lead to correct authentication with LinkedIn, Gmail, Yahoo and Hotmail.

Thanks, Twitteroonies!

Meanwhile, Flickr recently launched their own “Who to Follow” functionality. There is nary a password request in sight: they’ve implemented correct authentication right out of the gate for Yahoo, Gmail, Hotmail and Facebook.

Thanks, Flickroonies!

See? I’m not always bitching’n’moaning.

The OAuthcalypse is upon us. Since August 31st, all third-party Twitter services must use OAuth to authenticate. This is a good thing; a very good thing. Before that date, services were allowed to use the password anti-pattern to log you in.

Twitter has put its foot down and declared that the password anti-pattern will no longer be tolerated. Hurrah!

What a shame then, that Twitter is being utterly hypocritical. On their Find Friends page, they encourage you to:

Scan your email address book or contacts to discover which of your friends are already using Twitter.

They do this using the password anti-pattern. You are asked for your Gmail password even though the Google Contacts API would allow Twitter to connect to Gmail using proper authentication …exactly what Twitter is insisting third-parties use when they want to access Twitter’s data.

Twitter asks for your Yahoo Mail password even though the Yahoo Contacts API would allow them access to your address book using OAuth.

Twitter asks for AOL passwords (now there’s an audience that we shouldn’t be teaching to give their passwords away) but even AOL has an API with proper authentication.

Twitter does connect to LinkedIn correctly. That’s one out of four.

There are two solutions to this state of affairs. Either Twitter decides to do the right thing and switch over to using APIs and authentication for Gmail, Yahoo and AOL …or else Gmail, Yahoo and AOL follow Twitter’s example and disallow the password anti-pattern for scraping address books.

Twitter should not be encouraging Gmail users, Yahoo users and AOL users to divulge their passwords but at the same time, Gmail, Yahoo and AOL should be taking steps to ensure that such profligate behaviour is not rewarded.

Twitter has done the right thing with third-party services wishing to access its data. Now let’s see if the third-party services currently being abused by Twitter will follow this example.

Update: There are some very encouraging responses from Twitter. Ryan Sarver says:

all good points and I think there are already plans to fix it

And Josh Elman concurs:

yes - great points and something we hope to migrate very soon

A few months ago, Jakob Nielsen wrote about passwords. Specifically, he wrote about the standard practice of the contents of password fields being masked by default. In his typical black/white, on/off, right/wrong Boolean worldview, Father Jakob called for this practice to be abolished completely.

Meanwhile, back in the real world, Apple take a more empathetic approach, acknowledging that there often very good reasons for masking passwords. But that doesn’t mean you can’t offer the user the option to disable password masking if they choose.

This pattern came up in a conversation at Clearleft recently. We were discussing a sign-up process, trying to avoid the nasty pattern of asking users to input the same value twice. We were all in agreement that Apple’s solution to password masking was pretty elegant.

I’d like to use this pattern on the sign up form for Huffduffer but I can’t see a way of easily integrating it with the Mad Libs approach. But I have implemented this option on the log-in form.

Here’s what’s happening under the hood:

• The “show password” checkbox is generated with JavaScript,
• A text input field is also generated with JavaScript but hidden,
• Toggling the “show password” checkbox toggles the display of the password and text fields,
• Entering a character into either field updates the value of the other field.

It would have been a lot simpler to just use JavaScript to toggle the type attribute of one field between “password” and “text”. But, in a certain browser that shall remain nameless, you can’t do that …for very sound security reasons, no doubt.

So the script isn’t as elegant as I’d wish but it gets the job done. Feel free to view source on the JavaScript.

Update: Jonathan Holst points me to a post by Jeff Atwood on this subject. It’s worth reading just to boggle at the insanity of Lotus Notes’ security features. From the comments there, I found a bookmarklet to reveal password characters.

Twply is a straightforward little Twitter app that sends @replies to email. It uses the password anti-pattern. Oh, but don’t worry. It states quite clearly on the site that Your password is safe with us. No worries!

Twply is up for sale . That means all those passwords are available to the highest bidder ($1200 in this case).

Sleep tight, Twply users. May you wake to a better day.

A new site called My Name Is E launched for beta testing today. Eager geeks rushed to sign up for the contact aggregation service. The second step of the process involved handing over your Twitter username and password. This request was dutifully obeyed by the eager geeks.

Muppets.

This is a classic example of the password anti-pattern. And this time it bit the willing victims on the ass. My Name Is E used the credentials to log in to Twitter as that person and post a spammy message from their account.

This is identity theft. It’s not as extreme as having your credit card used or having somebody get in to your email account but it’s still an unrequested violation of personal details. I’m very interested in hearing how the willing victims felt when they saw the message appear on Twitter with their own name and their own avatar next to it. I imagine adjectives like “outraged” and “shocked” would describe the initial reaction but I wonder if “embarrassed” would be far behind.

The “auto-tweeting feature[sic]” was removed within hours in response to the overwhelming negative reaction, as demonstrated on Get Satisfaction. What’s ironic, in the Alanis Morissette definition of the word, is that the Get Satisfaction page features a “share” tab that includes a link to “Twitter this.” Click it. Go on.

Needless to say, I disapprove of what My Name Is E did. But I don’t lay the blame entirely at their feet. Frankly, I’m really disappointed that so many people who really ought to know better were so quick to hand over their Twitter password to any site other than Twitter.

I blame Facebook.

I don’t mean that facetiously. I really do blame Facebook. I also blame Digg. And LinkedIn. And Plaxo. And Twitter.

All of those sites—and many others—actively, sometimes aggressively, use the password anti-pattern. Together they have created a pervasive atmosphere in which it is now completely acceptable for even seasoned geeks to throw their passwords ‘round like car keys at a dodgy ’70s party.

I’ve been banging on about the password anti-password for what feels like ages now. I keep saying that it’s teaching users how to be phished. After a particularly dispiriting discussion of OAuth on the iPhone, Simon went one further and put it in the past tense.

I fear that Simon may be right. But I’m not going to give up hope just yet. Now that Google, Yahoo and Hotmail all have OAuth-style contacts APIs, I think the tide could still be turned.

Mind you, Twitter’s continuing lack of an OAuth-based API is nothing short of shameful, as acknowledged by Blaine in his comment here:

OAuth came out of my worry that if the Twitter API became popular, we’d be spreading passwords all around the web. OAuth took longer to finish than it took for the Twitter API to become popular, and as a result many Twitter users��� passwords are scattered pretty carelessly around the web. This is a terrible situation, and one we as responsible web developers should work to prevent.

So while Twitter positively encourages the password anti-pattern (by example and by design), the situation is very different now for Google, Yahoo and Microsoft. Access to those web-based email services are used as justification for the majority of instances of the password anti-pattern. Now that they all offer alternatives, the only reason for abusers (like Digg and LinkedIn) not to switch from the password anti-pattern to using the official APIs is development time and priority.

Those are valid reasons for not immediately making the switch so I understand that not everybody scrambled to implement, say, the Google Contacts API in the week it came out. But it was released in March. It is now September. Surely that’s long enough for even a low priority task to get implemented?

I realise that I sound very negative in my finger-pointing here so I’d like to give credit where credit is due. Back in March, I listed a chart of web sites who were using the password anti-pattern but who I hoped would switch over. Shame on me for not including Flickr in the list because they were the first to follow Dopplr’s lead and scrap the anti-pattern in favour of a seamless import feature. Shame on me also for putting Last.fm at the bottom of the list. As part of their recent redesign, they too scrapped the anti-pattern. Good for them!

At the top of my list of sites I expected to ditch the anti-pattern was Pownce. Alas, they’re still not all the way there (Yahoo import is working correctly, GMail and AOL isn’t). But after some petulant grandstanding on my part, I have been assured that they are working on it.

I know I should care more about the big abusers like LinkedIn and Facebook than the little guys like Slideshare and Pownce. But it’s precisely because I love Pownce so, so much that it upsets me to see them get such an important thing so wrong when they get everything else so, so right.

Y’see, I’ve been thinking of putting my money where my mouth is. I should really plant a flag in the sand and set a date in the not-too-distant future (like maybe early next year) beyond which I will simply refuse to use any site that implements the password anti-pattern …and delete any existing accounts.

Now, I wouldn’t mind doing this for LinkedIn, Digg or Facebook (I’ve already done it for Plaxo). I wouldn’t miss those sites. I don’t have any strong attachment to those sites. But I have a very strong attachment to Pownce and I would miss it very, very much if I were to delete my account there.

I’d also have to delete my Twitter account, which would probably feel like losing a limb. It’s not that I feel a strong emotional attachment to Twitter—using Twitter often feels like being in an abusive relationship with a Fail Whale—but it’s so pervasive that it would be like swearing off using email, or chat, or the telephone.

Besides, what difference would this grandstanding of mine do? I’m just one measly account. But if other people were to join me …well, perhaps that might affect the speed and priority of abandoning the password anti-pattern.

I could set up a Wiki, or something similar; somewhere where others could add their voice to the call to remove the password anti-pattern. It needn’t be wholly negative either: it could double up as a place for listing useful resources for developers who want to implement OAuth-style APIs.

So I have a few questions for you:

1. Is this a good idea or am I tripping?
2. Would you abandon sites that refuse to ditch the password anti-pattern?
3. Do you know of any good, easy to implement Wiki software?

There are two problems with April fool’s day on the Web.

Firstly, there’s the curiously timeless nature of online publishing. Google has a habit of preserving everything we write in amber so that long after a joke has been published in the context of April 1st, it resurfaces in search results where it may the taken at face value.

Secondly, it becomes very difficult to separate “real” stories from the japes. Remember a few years back when Google launched their GMail service? Remember what day they launched it on? I recall quite a few people who refused to believe the veracity of the announcement.

With that in mind, here are some tidbits that are most definitely pranks:

• GMail adds time-travel support using an e-flux capacitor to resolve issues of causality.
• John Resig releases Class Query for developers who are sick and tired of brevity and simplicity. This one is only funny if you a total code nerd but if you are a total code nerd, it’s very funny indeed.
• The Web Standards Project follow up their bookmark campaign with hyper-localised social tagging.
• Moo announce the MightyCard.
• The latest World of Warcraft character is the bard with damage effects like “epic solo” and “shoegazer”.
• The BBC show flying penguins.
• And finally, every single featured video on YouTube is a winner today.

These bits of news, on the other hand, are for real:

• Joe launches Captioning Sucks in an attempt to bring sanity and standards to the worlds of film and television. Any garishness you may experience is intentional.
• The good people over at Flickr have resurrected Game Neverending—the game that many years ago served as the genesis for Flickr itself (that’s why you’ll still the .gne extension to this day). The message announcing the resurrection is, of course, very much a joke.

There was one other announcement from Flickr but they managed to get it out right before the dreaded day of foolishness. The site now has a flawless import feature that has completely scrapped the password anti-pattern. Instead they’re using authentication APIs from GMail, Hotmail and Yahoo Mail (that last one is actually a bit of a cheat as Yahoo do not offer any export API for external services).

Needless to say, I’m over the moon about this (although Lachlan is less pleased). First Dopplr, now Flickr. And I’m ashamed to say that I didn’t even put Flickr in the running in the race to do the right thing. Consider me suitably chastised.

Design patterns are useful. They enable us as developers to encapsulate recurring interactions and refine them. From simple pagination right up to Ajax requests, patterns allow us to codify common conventions.

Inevitably, conventions can lead to a cargo cult mentality. Clients start to request Web 2.0 standards. I have no idea what that means but it usually involves tagging, “friends” and gratuitous use of JavaScript. This kind of copycat development isn’t so bad if you’re ripping off a site like Flickr—the more sites like Flickr, the better. The problems start when web apps start replicating bad design patterns as if they were viruses. I want to call attention to the most egregious of these anti-patterns.

Allowing users to import contact lists from other services is a useful feature. But the means have to justify the ends. Empowering the user to import data through an authentication layer like OAuth is the correct way to export data. On the other hand, asking users to input their email address and password from a third-party site like GMail or Yahoo Mail is completely unacceptable. Here’s why:

It teaches people how to be phished.

This issue was raised by Tantek at Fundamentos Web. Rigo Wenning—privacy activity lead at the W3C—was quick to back Tantek’s position. While we can’t protect people from themselves, we have a duty not to deceive them into thinking that throwing passwords around like confetti is acceptable behaviour.

Oh, don’t worry… the terms of service for Google accounts puts the responsibility in the hands of the user:

• Your passwords and account security
  • 6.1 You agree and understand that you are responsible for maintaining the confidentiality of passwords associated with any account you use to access the Services.
  • 6.2 Accordingly, you agree that you will be solely responsible to Google for all activities that occur under your account.

…but this isn’t a question of legalities.

I was somewhat surprised, even shocked, to see 37 Signals highlight this anti-pattern on Facebook as a smart way to connect members of the site. Simon was quick to point out the problem:

The Facebook thing isn’t a smart way of connecting members, it’s a horrible precedent that teaches users to be phished. Unfortunately that kind of feature is so prevalent now that you’d be foolish to launch a new social network without it, but from an ethical point of view it’s distinctly unpleasant.

He’s right. The issue for us as developers is a moral question. Do we blindly follow the dictates of clients looking to “add value” to their applications even when we know that the long-term effect is corrosive? I don’t think we should. We can collectively make a choice not to erode the long-term stability of our users’ data. Sure, the particular site you’re working on might not have any nefarious plans and the next site might claim to be secure, but over time we’re creating a climate conducive to cultivating honeypots.

Morality (or ethics) is not something that’s usually discussed alongside Web development. But Jeff Veen pointed me towards this great quote from Jamais Cascio’s talk at the Singularity Summity that illustrates the underlying truth:

To put it bluntly, software, like all technologies, is inherently political. Even the most disruptive technologies, the innovations and ideas that can utterly transform society, carry with them the legacies of past decisions, the culture and history of the societies that spawned them. Code inevitably reflects the choices, biases and desires of its creators.

So here’s what I’m going to do: even if it costs me a contract in the short-term, I will refuse to implement any kind of interface that involves asking the user for a password from a third-party site. I urge you to do the same. And if you feel equally strongly about this, make your thoughts known: blog about it, talk about it… you might even want to make your position clear in your terms and conditions. As the Naked Yak blog so eloquently puts it:

With the endless possibilities of the social web it is easy to fall into the trap of going for broke, applying everything in life to a particular application or piece of software that seems to enhance it. From now, I will always ask the question “Will this have a positive effect on my world?” rather than “What could I pull into this new tool?”

Update: For all the people saying yeah, but no, but yeah, but we need access to users’ data, please read the post again and this time, pay attention to the part about OAuth. See also:

• The Flickr authentication API and
• Google’s AuthSub.

I don’t know how much clearer I can make this: the end result of exporting data is desirable; teaching users to hand over their passwords to any site that asks for them is not. There is no excuse for asking for a third-party password on your website. You’re doing it wrong. That authentication must happen on the third-party site.