Hacker News Reader

Comment by StavrosK | Hacker News Reader

The article is a bit misinformative, with the biometrics red herring. Unless I'm mistaken, this is Webauthn, the new standard that will allow devices to authenticate using cryptographic keys that they have generated and stored, it's kind of like supercharged U2F.

Basically, your phone and computer (or USB key) will be able to generate keys and authenticate to each website uniquely, without the possibility of someone stealing your password or phishing it/spoofing the site.

It's a fantastic improvement, imagine if you could log in to a site on any untrusted computer just by plugging your USB key in, and you would be totally secure again after you logged out of the site.

View on HN

> your phone and computer will be able to generate keys and authenticate to each website

Welcome to twenty years ago and client SSL certificates.

I'm glad the future is catching up.

Unfortunately OS and Browsers never made the installation of SSL certs user-friendly. Also the requirement for a private key to be accessible by the PC we'd be using doesn't really help, generating OTP/keys on a separate device seems to be the way to go.

There was never any requirement that the private key be accessible from the local computer. Netscape/NSS had pluggable security modules with full support for PKCS#11-style smart cards back in 1998, I believe, so the 20 years ago isn't even overstating things.

There was a real big industry push back then and many expected smartcards to take over, but it fizzled as hardware companies generally doesn't do software well and nobody really wanted the added complexity of extra hardware.

Maybe it will go better now as individual users have a use case, as things like gmail and coinbase supports it, and not just the usual enterprise platforms.

I don't see what you mean is misinformative. The protocol is designed in such a way that an authenticator (e.g., a smartphone or a USB dongle) can check a biometric factor (or a PIN or something else) locally before allowing use of the private key. The authenticator also provides the server with its attestation certificate when you register it, and using that attestation certificate the server can verify what kind of authenticator it is and trust that the authenticator can be used as multiple kinds of authentication factor.

It is true that I don't know of any currently existing authenticators that support biometric authentication, but what's nice about this spec is that the biometric/PIN/etc stuff is never exposed to the server. When new kinds of authenticators enter the market (like if Google adds the feature in an Android system update), they can immediately be used without having to change any code on the servers. And like you say, even without the multi-factor stuff it'll be a fantastic improvement over the current dumpster fire that is passwords.

Full disclosure: I work at Yubico and am one of the editors of the Web Authentication spec.

That would be a good use for a smart-watch.

Fitting keyboards with NFC devices could make it even better.

> Fitting keyboards with NFC devices could make it even better.

As long as the user must do something on the device to approve it, otherwise you can have proximity scanning attacks as with RFID.

Thankfully NFC can be two-way.

Or good old smart cards with smartcard reader in the keyboard again?

You cannot use an untrusted computer to reliably log out.

Especially when the norm for refresh tokens is like, 90 days.

If, as GP suggests, you have to plug a USB device in to auth the first time, why not just run the protocol through the device for every single HTTP request? Then, if the user unplugged the device, future requests would fail, right? I don't know if the protocol under discussion forbids that, but it seems like an easy change?

A USB device would only be one of many options - relying on it would be pretty backward looking.

Other things would have other options. You might have a bluetooth or nfc device that has a "momentary" button, that e.g. you have to press less than five seconds before any particular web request.

That's a straight path to frustration on today's web

Might as well just boot linux from a USB at that point.

sadly just being able to boot your OS is not enough to trust the resulting hardware+OS combo

maybe, a better solution might be just doing a serverside 'authenticity ping' every x seconds, and if that fails then you get kicked out.

This would leave a window of x seconds after logging out in which attacks could occur but that could be mitigated by requiring a failed request on logout (perhaps require the usb key to be removed upon logout, send an auth-ping, and only give a successful logout message if the auth-ping fails. (Even without this mitigation I'm not sure what kind of attack would work for the inbetween X seconds, but might as well mitigate it in case someone else could think of something)

> You cannot use an untrusted computer to reliably log out.

You could conceivably have a login sessions page and access it from a trusted computer to force logout of a session from an untrusted computer.

But it seems the bigger problem with login from a malicious computer is that the computer could do whatever it wants with your session while you're logged in, regardless of how securely you can logout later.

Yes. As soon as you use an untrusted computer, there is no telling what you are vulnerable to. But:

(1) people frequently (and rightly) do that anyway, so we might as well make it less bad.

(2) Building a trustworthy computer is largely about isolating different components in a way that hurts malware more than it does the user-experience. Sticking keys on a USB key is one instance of such isolation.

If login becomes quicker and less disruptive it might make sense for websites to default to expiring sessions a lot faster. If all you need to do is scan your watch or press a button on your USB token it doesn't matter if you have to do it 10 times every day. If that's still not enough websites could ask for confirmation for every potentially sensitive action.

Of course there's only so much you can do if your hardware is compromised, you can just try to mitigate the issue as much as possible and hope for the best.

Nor you can today - a completely untrusted computer could fake the logout experience and keep a valid access token.

All signed access token, when logged out or revoked, should be marked so on the server side. Of course the untrusted computer should at the very least send the logout request.

Typically, a service should also let you see all your active sessions and let you revoke them.

> It's a fantastic improvement, imagine if you could log in to a site on any untrusted computer just by plugging your USB key in

You're describing plugging a USB key containing your identity into an "untrusted computer".

It's hard to call that a "fantastic improvement" or really anything other than a "terrible idea".

> "terrible idea"

Tell that to Yubico et al, who have based their businesses exactly on this "terrible idea", making secure USB devices that can be plugged in to insecure computers.

For the record, I have never plugged either of my Yubikeys into an "untrusted" computer.

Well, no machines more untrusted than the ones I do work or internet banking on.

I hope people don't think of Yubikey-type devices and "magic security pixie dust" that somehow makes it OK to do sensitive things on an internet cafe pc??? (Fully prepared to be told anecdotes of people doing stuff I'd consider crazy in response to this...)

In theory a yubikey is safer than simply logging into a website using passwords when the device is untrusted.

A USB device like a yubikey could provide an untrusted (or even trusted) devices with only a temporary access token. The untrusted device can only manipulate a user session with the user present, once the user has left, the session expires and the computer has no access token.

WebAuth makes it impossible to continue or begin a session without being authorized to do so if a USB device is used.

TOTP is one implementation of a "trusted device authorizes untrusted device" protocol that Yubikey/WebAuth/others enable.

Compare with password logins: Once you enter your password you trust the device you entered it on to not compromise it.

How so? The private key never leaves the device, the certificates are site-based, preventing phishing, and they require actual physical interaction to authenticate.

This is miles better than password-based login.

It's still only one or two of the three authentication factors.

A phone provides a fingerprint scanner (something you are), and holds the keypair (something you have) and when combined with a password (something you know) you have all three.

But we still need the phones to support U2F.

U2F is actually the older standard, Webauthn can work with U2F, but it adds some things like user identifiers that make it more useful to authenticate with.

You're right, my bad. But I still do wish phones even supported emulating the existing FIDO U2F standard.

Me too :/ It would be great against phishing.

Agreed. I adore U2F, and even have it running under Safari because I love it that much; but without phone support for it, my cute Yubikey really only helps for desktop usage currently.

As it stands, my pass phrase and fingerprint are the weak links, as phone logins rely on TOTP. One day I’ll be able to tap my phone against my Yubikey along with my pass phrase, and/or my fingerprint. That would be lovely.

I was thinking about soft U2F tokens and came to the conclusion that they wouldn't be that much different from a cookie that just always bypassed the second factor for that specific browser. Of course, it could be stolen from the browser, but so could the U2F key.

The browser never sees the key with U2F; everything is computed on the USB device.

I'm talking about soft U2F tokens, i.e. software-based.

> One day I’ll be able to tap my phone against my Yubikey along with my pass phrase, and/or my fingerprint. That would be lovely.

That works fine for me on Android.

a fingerprint scanner (something you are), and holds the keypair (something you have)

What segregation between these is there within the phone? Doesn't it mean the fingerprint gets you the keypair for free?

If you also have the physical phone in your hands, yes.

You now have a severed finger. Where's the phone? You'll still need both items.

the point is, it relies on JavaScript feature, right?

Reply on news.ycombinator.com