Tags: password

43

sparkline

Wednesday, February 3rd, 2021

Authentication

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.

Monday, March 23rd, 2020

Inclusive Inputs « Texte | ovl – code & design

This is a great walkthough of making a common form pattern accessible. No complex code here: some HTML is all that’s needed.

Wednesday, January 16th, 2019

Security Checklist

Exactly what it sounds like: a checklist of measures you can take to protect yourself.

Most of these require a certain level of tech-savviness, which is a real shame. On the other hand, some of them are entirely about awareness.

Tuesday, August 7th, 2018

‘Never assume anything’: The golden rules for inclusive design

Inclusive design is also future-proofing technology for everyone. Swan noted that many more developers and designers are considering accessibility issues as they age and encounter poor eyesight or other impairments.

Tuesday, June 12th, 2018

Password Tips From a Pen Tester: Common Patterns Exposed

I’ve been wondering about this for quite a while: surely demanding specific patterns in a password (e.g. can’t be all lowercase, must include at least one number, etc.) makes it easier to crack them, right? I mean, you’re basically providing a ruleset for brute-forcing.

Turns out, yes. That’s exactly right.

When employees are faced with this requirement, they tend to:

  • Choose a dictionary word or a name
  • Make the first character uppercase
  • Add a number at the end, and/or an exclamation point

If we know that is a common pattern, then we know where to start…

Thursday, March 29th, 2018

UX In Contact Forms: Essentials To Turn Leads Into Conversions — Smashing Magazine

The answers to these questions about forms are useful for just about any website:

  1. Is It OK To Place A Form In Two Columns?
  2. Where Should Labels Be Placed?
  3. Can We Use Placeholder Text Instead Of A Label?
  4. How To Lessen The Cognitive Load Of A Form?
  5. Are Buttons Considered Part Of A Form’s UX?
  6. Is It Possible To Ease The Process Of Filling A Form?
  7. Does The User’s Location Influence A Form’s UX?

Friday, March 10th, 2017

Password Rules Are Bullshit

And here’s another reason why password rules are bullshit: you’re basically giving a list of instructions to hackers—the password rules help them narrow down the strings they need to brute force.

Thursday, January 19th, 2017

Let them paste passwords - NCSC Site

Ever been on one of those websites that doesn’t allow you to paste into the password field? Frustrating, isn’t it? (Especially if you use a password manager.)

It turns out that nobody knows how this ever started. It’s like a cargo cult without any cargo.

Wednesday, December 7th, 2016

DiceWARE

This is a wonderful service! Handcrafted artisanal passwords made with a tried and trusted technique:

You roll a die 5 times and write down each number. Then you look up the resulting five-digit number in the Diceware dictionary, which contains a numbered list of short words.

That’s the description from the site’s creator, Mira:

Please keep in mind when ordering that I am a full-time sixth grade student with a lot of homework.

She’s the daughter of Julia Angwin, author of Dragnet Nation.

Monday, March 2nd, 2015

Password Masking

A great investigation into the usability benefits of allowing users to fill in their passwords in plain text.

Major caveat: make sure you still offer the ability to mask passwords too.

Wednesday, January 28th, 2015

LukeW | Showing Passwords on Log-In Screens

Luke continues to tilt against the windmills of the security theatre inertia that still has us hiding passwords by default. As ever, he’s got the data to back up his findings.

Wednesday, December 3rd, 2014

The Secret Life of Passwords - NYTimes.com

A fascinating look at how the humble password gets imbued with incredible levels of meaning.

It reminds me of something I heard Ze Frank say last year: “People fill up the cracks with intimacy.”

Tuesday, August 6th, 2013

Chrome’s insane password security strategy by Elliott Kember

A description of the shockingly cavalier attitude that Chrome takes with saved passwords:

Today, go up to somebody non-technical. Ask to borrow their computer. Visit chrome://settings/passwords and click “show” on a few of the rows. See what they have to say.

Wednesday, November 7th, 2012

LukeW | Mobile Design Details: Hide/Show Passwords

I concur completely with Luke’s assessment here. Most password-masking on the web is just security theatre. Displaying password inputs by default (but with an option to hide) should be the norm.

Wednesday, September 26th, 2012

NoPassword

I like this passwordless log in pattern but only for specific use cases: when you know that the user has access to email, and when you don’t expect repeat “snacking” visits throughout the day.

Saturday, February 11th, 2012

The Perpetual, Invisible Window Into Your Gmail Inbox - Waxy.org

Andy sounds a cautionary note: the password anti-pattern may be dying, but OAuth permission-granting shouldn’t be blasé. This is why granular permissions are so important.

Thursday, September 22nd, 2011

Authentical: Random factoids I’ve encountered in authentication user research so far

Dana has put together an excellent grab-bag of data on people’s password habits.

Monday, December 20th, 2010

Requiring email and passwords for new accounts - Instapaper Blog

A fascinating explanation of why Instapaper is migrating away from its passwordless sign-up.

Sunday, November 21st, 2010

Pattern praise

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.

Thursday, September 9th, 2010

OAuthypocrisy and the Passwordpocalypse

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