WebAuthn – The Passwordless Future | Hacker News Reader

WebAuthn – The Passwordless Future

webauthn.io

69 pointsmiohtama38 comments

I'm not deeply familiar with webauthn -- what happens when a user loses their device/private key? Can they still do an account recovery?

If it's a standard "lost password" flow, in which case it still suffers from the same weaknesses of the lost password flow?

Today, with WebAuthn, recovery works the exact same way. Which is normally by emailing the user a magical link to a (trusted) address that does some recovery flow. There's nothing different about this, and how much of a weak link it is depends on your risk assessment, I guess. WebAuthn makes other classes of "first-party" attacks like phishing and credential stuffing impossible to perform, however, which is a huge benefit. So on the whole I see it as an improvement, but there could still be a lot improved.

Honestly saying that part out loud, one of the annoying parts of it all now is that the credential store for WebAuthn is now effectively per-application, not per-user. So you need "number-of-browsers * number-of-devices" different registrations, which is basically annoying enough to mean I still use 1Password. In some fancy world, the actual credential store could be some kind of persistent, per-user system service provided to any application, and they would all share these credentials. Sort of like Apple Keychain on steroids, basically, but it needs to work everywhere, on all platforms, and be adopted consistently by applications.

Apple has a technical preview in iOS 15 and macOS Monterey that stores the WebAuthn credentials in iCloud. This lets you have passwordless WebAuthn login, without registering each device separately.

https://developer.apple.com/videos/play/wwdc2021/10106

It's only works in the Apple ecosystem currently and is only a technical preview, but it's a cool idea to reduce the number of registrations you have to do and reduce the chance of getting locked out of websites by losing your WebAuthn key.

> It's only works in the Apple ecosystem currently and is only a technical preview, but it's a cool idea to reduce the number of registrations you have to do and reduce the chance of getting locked out of websites by losing your WebAuthn key.

There is work being done to try to create a realistically usable cross-device (e.g. mobile phone as authenticator to my desktop) support leveraging Bluetooth LE. One could hope for a future where say an iPhone with these WebAuthn "PassKeys" (as Apple branded them) could be used to authenticate with a Windows laptop.

There are also draft features which would allow a site to detect you are going cross-platform, and offer to add an additional local Windows Hello mechanism to streamline the process in the future.

This is a matter for the relying party (typically a web site). WebAuthn doesn't define what should happen if you can't do WebAuthn.

Yes, if they've got a "lost device" flow that bad guys can easily defeat then, bad guys can easily defeat it.

You're encouraged to purchase multiple keys and register them. Keep one in a safe.

How am I supposed to register multiple keys if some of them are kept in a (possibly off-site) safe? Maybe for some high-value accounts doing that kind of "registering of the keys" ceremony might be worth the hassle, but for everyday usage frictionless this certainly ain't...

This doesn't solve the issue of somebody traveling and getting mugged. Then what? You're just locked out of everything? That seems very, very inconvenient.

There's a reason passwords haven't been usurped yet. It's because these fancy new ideas come with an entire new set of their own problems. These problems are worse than what we deal with for passwords.

Typically it falls to an account recovery flow, which would be expected to be as strong or stronger than the account creation flow. Obviously sites implement account recovery wrong all the time though.

Some systems like Google Advanced Protection Program specifically don't really have alternate means of authentication or a recovery flow.

If you register multiple authenticators, you can do a break-the-glass/open-the-safe recovery, but this assumes you remembered to register all authenticators to all sites.

There is a proposal to support backup keys via what might be referred to a cryptographic introduction. My primary key can include additional cryptographic data, and if I lose my primary key my backup key can prove that it was the key that was previously mentioned.

There is a tech preview by Apple for PassKeys, which is a WebAuthn authenticator which isn't represented by a single piece of hardware but across all the hardware on your Apple account. This reduces the need (or I suppose, increases the trauma) needed to get to an account recovery event.

On a related note, hasn't this been solved by SQRL [0]?

> SQRL (pronounced "squirrel") or Secure, Quick, Reliable Login (formerly Secure QR Login) is a draft open standard for secure website login and authentication. The software typically uses a link of the scheme sqrl:// or optionally a QR code, where a user identifies via a pseudonymous zero-knowledge proof rather than providing a user ID and password. This method is thought to be impervious to a brute force password attack or data breach. It shifts the burden of security away from the party requesting the authentication and closer to the operating system implementation of what is possible on the hardware, as well as to the user. SQRL was proposed by Steve Gibson of Gibson Research Corporation in October 2013 as a way to simplify the process of authentication without the risk of revelation of information about the transaction to a third party.

I think it's a shame that there has not been a more popular adoption of this authentication method.

[0]: https://en.wikipedia.org/wiki/SQRL

SQRL sorta-kinda solves most of the problems WebAuthn solves, but only if you chose to configure it that way and your users are holding it right.

For a security feature that's not good enough.

Phishing is the one that gets me, because we know it's a crucial threat and WebAuthn solves it. Done. Google just gave employees Security Keys and the problem went away.

SQRL ends up in most cases with the "phishing prevention" relying on the user, the person phishing intentionally exploits, to determine they are being phished. That's not a strategy for success. If Grandma didn't realise this isn't the real web site when her email linked it, she's also not going to realise when there's a typo in the name her SQRL client displays. And then it's game over.

In SQRL the target domain is used as part of the per-domain key derivation from the master key. It’s basically stateless per-domain identity from a single master secret. This provides strong phishing protection.

No.

The user has to know they are interacting _directly_ with the authentic site, vs a malicious party intermediating the QR-based login.

There is no way to solve this with mere QR codes; you want the communication channel itself to be authenticated, and that communication channel is abstracted completely away. So you can authenticate and create _a_ session, but you aren't sure it is actually going to be your session vs an attacker's.

WebAuthn has the code managing that channel (e.g. native code within the browser or underlying OS) craft an authentication request specifically for the site being accessed. It does this over a separate communication channel to the authenticator device, or internally to the underlying platform.

IMHO, the biggest risk to WebAuthn is arbitrary client software, as a 'fake' browser can misrepresent why you are tapping to create sessions into other websites. This is why several operating systems lock down the ability to talk to FIDO keys directly over USB/NFC/Bluetooth, and instead provide a native API requiring entitlements. Normal apps may get credentials only for their own sites, while a Browser may be vetted at a higher level of scrutiny to get credentials for any site.

Actually, no, the biggest risk remains script injection - XSS and WebExtensions.

SQRL has weak anti-phishing protections. Basically you can't tell if the QR code is being displayed by the legitimate site or another site which is proxying the legitimate site.

WebAuthn integrates with the browser itself, and both does per-site keys and identifies the site in its cryptographic response. You would need to compromise the site or infrastructural pieces like DNS and TLS to break WebAuthn's phishing protections.

FWIW, Mutual TLS and Kerberos are the other two widely known systems here, with slightly better phishing protections because they operate below the "XSS" layer of modern browsers. However, that also means they require infrastructure investment, and are generally impractical to deploy outside environments with device management.

Is the consensus that we're moving towards actually passwordless futures?

I've only seen WebAuthn and Touch ID replace a one-time code either sent via text or looked up in Google Authenticator. I have one Yubikey for each laptop I own, and also use Touch ID / Face ID on iOS with whatever site will allow, but it's always a second factor, not a password replacement.

The weird thing is that I also use a password manager on mobile (KeePassium), and I have it configured to unlock with Face ID to autofill my usernames and passwords. So on some sites I actually do have "passwordless" log in, but in a round about way.

Not sure whether I should be eager to drop passwords entirely, whether this WebAuthn + password manager flow is the end game, or whether I should go change the config to require my master password manager password for every log in.

WebAuthN + Biometrics on device (Touch/Face ID) + SSO (Sign in with Google/Apple) gets us most of the way there.

Passwords are necessary if there is no guaranteed identity provider of last resort to fall back to, as the email|username/password|secret credential pair is then the identity.

Ideally instead of a password it would be a decent sized shared secret generated for the site (1kb?)

Be careful of using biometrics if you are in the USA and don't want the government to force you to open up. I don't use biometrics for that reason as this is not a hypothetical for me, I've had these issues come up in a court proceeding.

https://news.bloomberglaw.com/us-law-week/compelled-biometri...

No, it's just marketing

Apple is moving towards this direction with iCloud Passkey. It's not ready yet but seems promising.

https://sixcolors.com/post/2021/06/wwdc-2021-apple-takes-the...

The key to the passwordless future is in the widespread use of devices that use biometrics for local authentication of the user and have a Secure Enclave or similar hardware that can provide better guarantees, along with built-in support for WebAuthn.

These devices will also become the ones responsible for setting up the same login on other devices. These would work in a way similar to, for example, how Apple or Okta handle two factor authentication by sending a push notification to existing devices registered to the account.

Since most people wouldn’t have a Yubikey (or multiple Yubikeys for backups) and since most people own one smartphone, the fallback for account recovery — when their smartphone breaks or is lost — would be the weakest link.

Biometrics on mobile are almost always a fast path to bypass a PIN/password screen, so I'm not convinced.

Yubikeys are a pita as well. I have an NFC one I use for authentication on my laptop, and a second in case I lose it. Registering both tokens on some websites is just not possible, and remembering to register both, at sites where it is, is easily forgotten.

The problem with biometrics is they're persistent where you don't want them to be (you can't change them) and not where you do (after you wipe your phone, or buy a new one)

I recently wiped and reinstalled my phone, and reinstalled about 10 bank/finance/credit card apps. Not one of them requires much more than some lame security questions, card details and SMS verification to get up and running. Fingerprint login is just a convenience.

Passwords will still be a thing in 50 years.

Biometrics are the worst passwords: easy to get without your consent, and hard to change.

Biometric identification is only an "improvement" for political police across the globe: it makes people ok to give their fingerprints away, and opens new (back)doors into people's devices. Fingerprint readers are Stalin's dreams come true.

Does a system like this create an ability to correlate accounts between services? My personal preference is unique usernames (and ideally addresses) for each seperate service.

If it is all tied back to a single private key / pubic verified identity, then does it become easy to cross reference every account someone holds a la keybase verificaiton?

When reviewing a new password-less mechanism, it pays to know the following and what you are getting out of it:

- how easily are they grouped together:

** by your devices

** by your account nameS

** by your end-apps

- How easily removed (a central management page that offers automatic revocation)

** by excess usage

** by excess financial amount

** by strange location

- How easily stolen

** Face ID imprints

** Fingerprint

** Something you know

- How easily blocked by something you have.

** Your PC machine ID

** key fobs (Yubikey)

** your IP address

great, so now instead of forgetting their passwords, users can lose hardware

Does anyone have any suggestions for a physical token that they can use for both WebAuthN and gpg signatures?

Would be great to hear stories from people who have put the equipment "through its paces" so to say :)

I use a Yubikey for this (4C specifically), works well.

Yubikey?

I use a Trezor, only for stuff like this. I use it for WebAuthN, gpg, ssh, (and via gpg) password management.

Unlike Yubikey you can import an externally generated seed so you can replace a Trezor if it gets lost/breaks without registering multiple devices.

I use a Ledger for U2F/WebAuthn/GPG/SSH. Works pretty well, you can have multiple entities from a single seed. You only have to backup that seed (which can have attached passwords), and it can be recreated across any compatible device (Ledger, or Trezor, or even decode them manually)

Yubikeys are good for this, as the higher end models typically support extra functionality beyond FIDO/WebAuthn, like PIV modes.

What's the general take on OAuth vs WebAuthn?

Why not both?

they are orthogonal

OAuth is typically used to delegate authorization, e.g. let some site or CLI read your GitHub repos.

To be able to delegate authorization in this scenario, you're first going to have to prove who you are to GitHub. Thats where you'd use WebAuthn.

They basically solve separate problems.

Now, when you are doing OpenID Connect (which adds Authentication), this becomes more of a question like - do I have users sign in with their Github account to my site, or do I just support all that directly via WebAuthn. Quite a bit more overlap. *

However, its not that uncommon for sites to support multiple ways to log in. Having a cloud-based login and a local login might prevent some random event causing the user to completely lose the ability to log in.

* Note I took some license here, since Github built their own thing rather than using OpenID Connect.

I'm not an expert in with by any stretch of the imagination but I found this to be seriously cool software

No thanks

Reply on news.ycombinator.com