You are here

You are here

WebAuthn/CTAP: Final countdown for passwords? Don't count on it.

Richi Jennings Your humble blogwatcher, dba RJA

Passwords must die. On that we’re all agreed. Amirite?

FIDO and W3C want to set the standard for 21st-century authentication. They seek to do away with phishing, credential breaches, and MITM attacks. And the major browsers seem to be playing along.

But is anyone experiencing déjà vu here? In this week’s Security Blogwatch, we’ve heard it all before.

Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: ISO tea (yet again) 

Conspiring against the password 

What’s the craic? Ron Miller grinds out FIDO Alliance and W3C have a plan to kill the password:

By now it’s crystal clear to just about everyone that the password is a weak and frankly meaningless form of authentication. … It places a burden on the user, is easily stolen and mostly ineffective.

Today, two standards bodies — FIDO and W3C — announced a better way. … By switching to this method, not only will you eliminate the need for a password — or to come up with a 20-character one every few weeks to please the security gods — but the whole reason for that kind of security farce will disappear.

The WebAuthn specification offers several examples of how this could work. In one example, … instead of a user name and password, you get a prompt to check your phone. You tap the prompt on your phone and you are logged in without the need for entering anything.

WebAuthn is not quite ready for final release just yet, but … it’s being recommended to the standards bodies for final approval.

But why just one standard, when you could have two? Richard Chirgwin FTW—Two new standards aim to make logins an API experience:

A pair of authentication standards published this week have received endorsement from Mozilla, Microsoft and Google: the WebAuthn API, and the FIDO Alliance's Client-to-Authenticator Protocol … (CTAP).

In typically-opaque language, the W3C said WebAuthn is “an API enabling the creation and use of strong, attested, scoped, public key-based credentials by web applications, for the purpose of strongly authenticating users.” … Credential protection is the job of “compliant authenticators” such as a trusted applet, TPMs … SEs (secure elements) in the user's environment [or] external elements like USB, Bluetooth, and NFC devices.

FIDO's associated CTAP project sets down the detail of external authenticator behaviour (the Bluetooth, NFC and USB devices). … Web applications get a standard way to interact with biometric authentication in the same way as they would interact with a security key — and without passing the credentials upwards.

Can you guess what happened next? Howls of impotent rage from countless keyboard warriors, that’s what. Among the more articulate is Opportunist:

Could you run this by a security department? Or are you afraid of going deaf because of the volume of the "OH HELL NO!" … yelled at you?

Who is idiot enough to, after the past YEARS of identity theft and privacy abuse, even suggest something like this? … It's been shown time and again that it's trivially easy to bypass biometric scans. … And you want me to trust my banking to something like this?

Are you stupid? Or do you just think I am?

And this Anonymous Coward:

It's astonishing that this is still not understood. Biometrics are a unique identifier, but you also can't change them. When they're breached, that's it.

You can change a password; you can't change your fingerprints. And for whistleblowers or people in oppressive regimes, it's also much easier for a government to break into your accounts with biometrics than it is a password floating around in your head.

But hey, you probably have nine other fingers. Norman Nescio is more succinct:

Repeat after me: A biometric is not an authentication mechanism, it is merely an identifier.

People who use biometrics as passwords are basically of the opinion that with a sufficiently complicated username, you don't need a password.

Wait. Pause. Are we conflating authentication, identification, and authorization? Quoth TheRaven64:

The API is not about providing biometrics to the remote server, it is about generating keypairs and attestations. When you register a device with a site, you generate a key pair associated with the {authenticator, site, user} triple. The authenticator (U2F device, keychain, whatever) stores the private key, you upload the public key. When you want to log back in, the server provides you with some data, which you then sign with the private key and upload. The server can then check it with the public key and validate that you are the same person as last time.

This means that you never upload a password, biometrics, or anything else of this nature to the web site. You may use biometrics, a hardware security module, or a password locally to authorise the authenticator to provide the attestation.

At no point does your fingerprint data even leave the U2F device.

Just for fun, let’s don our TINFOIL hats for a moment, and HEED the bombast OF bombastic bob:

Tried before. Micro-shaft 'Passport'. Failed then, too.

And don't forget "Log in using Face-b****". NO tracking THERE, right??? Or 'log in via Google'. Same thing.

A centralized "single point of failure" logon for the ENTIRE intarwebs is likely … to TRACK YOU EVERYWHERE. … And their revenue model: slurp a few cents for every site that uses the API.

Okay, fun over. Back to some more intelligent criticism, such as this, from xorcist:

Welcome to twenty years ago and client SSL certificates.

I'm glad the future is catching up.

…and this, from CiPHPerCoder:

I'm not feeling great about these algorithm choices. Namely: RSA with PKCS1v1.5.

Also, elliptic curve digital signatures with a random nonce … instead of deterministic nonces makes me feel itchy.

See also: this, from blakesterz:

See also: that SQRL thing Steve Gibson has been working on for years?

To which Ajedi32 forces an opinion: [You’re fired—Ed.]

SQRL's biggest advantage over other proposals for a password replacement was that it didn't need buy-in from browser vendors to work.

At this point though it seems pretty likely that the Web Authentication Standard has successfully overcome that barrier. It's already partially implemented in multiple browsers (Chrome, Firefox) and backed by a W3C Candidate Recommendation. In the face of that, I don't believe SQRL can compete.

Meanwhile, here’s andy 103:

I was going to start this by saying "we all know why client side validation is a bad idea". But clearly, we don't.

Have we really become this stupid? Are there any competent developers left out there?

The moral of the story?

While previous attempts failed, this looks like one to watch. But be cautious of dancing on the bleeding edge, because this might not be the panacea it appears to be.

And finally (speaking of standards) …

Oh look! Yet another YouTuber “discovers” ISO 3103: The standard cup of tea

 Except, unlike others, Tom Scott actually got a copy of the standard (which costs a princely $40)

You have been reading Security Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or Ask your doctor before reading. Your mileage may vary. E&OE.


Keep learning

Read more articles about: SecurityData Security