6 ms·

WebAuthn – The Passwordless Future

69 points by miohtama 5y ago

er4hn 5y ago
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 :)
- Latty 5y ago
  I use a Yubikey for this (4C specifically), works well.
- killingtime74 5y ago
  Yubikey?
- rendaw 5y ago
  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.
- shoghicp 5y ago
  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)
- dwaite 5y ago
  Yubikeys are good for this, as the higher end models typically support extra functionality beyond FIDO/WebAuthn, like PIV modes.
catsarebetter 5y ago
I'm not an expert in with by any stretch of the imagination but I found this to be seriously cool software
jez 5y ago
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.
- dbbk 5y ago
  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-first-steps-to-a-password-less-future/ https://sixcolors.com/post/2021/06/wwdc-2021-apple-takes-the...
- toomuchtodo 5y ago
  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.
  - lazide 5y ago
    Ideally instead of a password it would be a decent sized shared secret generated for the site (1kb?)
- kingcharles 5y ago
  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-biometric-access-legal-under-4th-5th-amendments https://news.bloomberglaw.com/us-law-week/compelled-biometri...
camkego 5y ago
What's the general take on OAuth vs WebAuthn?
- postalrat 5y ago
  Why not both?
- jiveturkey 5y ago
  they are orthogonal
- dwaite 5y ago
  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.
jedberg 5y ago
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?
- aseipp 5y ago
  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.
  - MarkSweep 5y ago
    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 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.
    - dwaite 5y ago
      > 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.
ehutch79 5y ago
great, so now instead of forgetting their passwords, users can lose hardware
newscracker 5y ago
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.
- nly 5y ago
  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.
- southerntofu 5y ago
  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.
wly_cdgr 5y ago
No thanks
egberts1 5y ago
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
rolandog 5y ago
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 https://en.wikipedia.org/wiki/SQRL
- tialaramex 5y ago
  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.
  - tatersolid 5y ago
    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.
    - 5y ago
blitzar 5y ago
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?

69 points by miohtama 5y ago

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 :)

Latty 5y ago
I use a Yubikey for this (4C specifically), works well.
killingtime74 5y ago
Yubikey?
rendaw 5y ago
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.
shoghicp 5y ago
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)
dwaite 5y ago
Yubikeys are good for this, as the higher end models typically support extra functionality beyond FIDO/WebAuthn, like PIV modes.

catsarebetter 5y ago

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

jez 5y ago

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.

dbbk 5y ago
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-first-steps-to-a-password-less-future/ https://sixcolors.com/post/2021/06/wwdc-2021-apple-takes-the...
toomuchtodo 5y ago
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.
- lazide 5y ago
  Ideally instead of a password it would be a decent sized shared secret generated for the site (1kb?)
kingcharles 5y ago
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-biometric-access-legal-under-4th-5th-amendments https://news.bloomberglaw.com/us-law-week/compelled-biometri...

camkego 5y ago

What's the general take on OAuth vs WebAuthn?

postalrat 5y ago
Why not both?
jiveturkey 5y ago
they are orthogonal
dwaite 5y ago
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.

jedberg 5y ago

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?

aseipp 5y ago
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.
- MarkSweep 5y ago
  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 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.
  - dwaite 5y ago
    > 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.

ehutch79 5y ago

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

newscracker 5y ago

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.

nly 5y ago
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.
southerntofu 5y ago
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.

wly_cdgr 5y ago

No thanks

egberts1 5y ago

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

rolandog 5y ago

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 https://en.wikipedia.org/wiki/SQRL

tialaramex 5y ago
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.
- tatersolid 5y ago
  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.
  - 5y ago

blitzar 5y ago

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?