Tags: known

6

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.

Sunday, November 8th, 2015

A short note about web standards from your friends at Known

Ben and Erin are shipping experimental support for AMP in the latest version of Known, but Ben has some concerns about the balance of power tilting towards one major player, in this case Google:

Unfortunately, AMP redefines the HTML standard with some custom tags. That’s not great. It also requires that we load JavaScript from a specific source, which radically centralizes website content.

But it’s Google’s whitelist of approved ad providers that’s most concerning:

We’ve shipped support for AMP because we see potential here, and recognize that something should be done to improve the experience of loading independently-published content on the web. But attempting to bake certain businesses into a web standard is a malformed idea that is doomed to fail. If this is not corrected in future versions of the specification, we will withdraw support.

Tuesday, June 30th, 2015

Thriving in Unpredictability - TimKadlec.com

This is the way to approach building for the web:

I want to make as few of those assumptions as possible. Because every assumption I make introduces fragility. Every assumption introduces another way that my site can break.

It’s progressive enhancement, but like Stuart, Tim is no longer planning to use that term.

Saturday, October 4th, 2014

Blogging Known Style

Companies go out of business, get bought and change policies, so what if you had one place to originate all of your content then publish it out to those great social services? And hey, why not pull comments from those services back to your original post?

That’s the idea behind Indie Web Camp: have your own website be the canonical source of what your publish. But right now, getting all of the moving parts up and running requires a fair dollop of tech-savviness. That’s where Known comes in:

It’s similar to the WordPress model: you can create a blog on their servers, or you can download the software and host it on your own.

This post is a good run-down of what’s working well with Known, and what needs more work.

Tuesday, May 27th, 2014

Known: taking a big bet on the #indieweb

When I’ve been banging on at conferences about digital preservation, personal publishing and the indie web, I’ve been at pains to point out that there are huge opportunities here for startups looking to build valet services to help people publish on their own domain.

Ben and Erin at Known are doing just that, with some backing from KQED, PRX and the Knight Foundation instead of the usual short-sighted Silicon Valley venture capitalism.

One of the jobs of a startup is to look at where the world is going, extrapolating from current trends and domain knowledge, and meet a future need with a product at exactly the right time. We think the time is right for an independent web that is owned by content creators and readers alike.

Monday, June 10th, 2013

Other flexible media: balloons and tattoos

Vasilis considers the inherent flexibility and unknowability of web design.

I tried to come up with other fields that need to design things for a flexible canvas, in the hope of finding inspiration there. The only media types I could come up with was the art of balloon printing and the art of tattooing.