8 ms·

Passkeys – Under the Hood

158 points by paulgerhardt 3y ago

treesgrowslow 3y ago
Let me add an operations and service delivery perspective. Our company relies solely on Passkeys for sign-in. The experience is both insanely good yet annoying. A colleague summarized our latest Passkey issues showing the ecosystem remains fragile for enterprises: Fragile Passkey Ecosystem for Enterprises https://news.ycombinator.com/item?id=39742107 https://news.ycombinator.com/item?id=39742107
crote 3y ago
> With a security key, the private key is stored inside a secure element and an attacker with physical access to a security key would not be able to recover the private key value. This glances over one of the most powerful features of non-resident (not Passkey, regular U2F / Webauthn) keys: you don't actually need to store the private key on the client! Non-resident keys only use a single per-token secret key. On registration a random number is generated, which is used together with the secret key to derive a public/private keypair used for the whole authentication flow. This random number is sent to the server along with some check digits, forming a token ID. On authentication the server sends the ID back to the token, who uses it to again derive the same keypair which is for authentication. The biggest benefit is that a single cheap token can support an unlimited number of websites. It only needs to store a single secret, after all. If the user has multiple hardware tokens, just send all the numbers one-by-one and see which one is accepted by the token. This also provides essentially perfect privacy: the token doesn't store anything about the websites or accounts it is used with, so an attacker gaining control over a token cannot easily determine where it can be used and has to manually try each website one-by-one by actually visiting the site and trying potential usernames. With resident keys ("Passkeys") the website does not know which ID to return, because a username is not yet known so you'd have to try all registered IDs for all users to look for a match. That's impossible, so the token needs to store some per-user-account data which allows it to map from a domain name to one or more stored credentials and their IDs (which allow both authentication and a mapping to a specific user on login). This places a hard upper limit to the number of Passkey websites a security key can support, and in practice forces you to use a smartphone or computer instead if you want to register a nontrivial number of websites. There are also privacy risks here, as it must by definition be possible to query a token for the existence of an account at a website. Passkeys have been heavily pushed by major tech companies as a replacement for both a username, password, and 2FA method - but (assuming proper 2FA) it's a strict downgrade with serious drawbacks. It's really sad to see companies ditching proper Webauthn 2FA support when switching to Passkeys, because it's making security worse for the people who actually care about it.
- dyml 3y ago
  You make a valid point about “non-resident” WebAuthn 2FA being great 2FA. However, passkeys are also great, and they depend on your context…. Most people are in the passkey context. For people who are not knee-deep I think we can explain it a bit better, why passkeys replaces passwords: With non-resident (2FA keys) you need to identify your account first. Since you don’t want to have account enumeration, this means doing a primary authentication, e.g. passwords. With passkeys, the website can just ask your browser) to sign in with any of the accounts it has passkeys for; which result in a one click sign in. While hardware backed Security Keys for 2FA is great 2FA, there’s a tangible cost, both in UX and $ that leaves many users left out (not everyone can afford $20 for a security key) Source: I work at Bitwarden building our Passkey API for developers. We support both 2FA and passkeys, both in the API service and in our password manager. Feel free to ask my anything related.
  - ivlad 3y ago
    > Since you don’t want to have account enumeration, this means doing a primary authentication, e.g. passwords. Nothing prevents site from sending a blob of random data when real key is not found. > While hardware backed Security Keys for 2FA is great 2FA, there’s a tangible cost, both in UX and $ that leaves many users left out (not everyone can afford $20 for a security key) Both major desktop operating systems come with WebAuthn support - Windows via Windows Hello and macOS with Secure Enclave backed key store. That not a problem at all in corp environment. Buying a Yubikey (or two) for each employee in the company is minimal cost comparing to laptop, desk, chair, software licenses We use WebAuthn as the first factor, and we love it because it completely eliminated password brute force problem. Password attacks (brute force and stuffing) is a much bigger problem, than account enumeration, especially in corp environments where usernames follow a name-based pattern and everybody is on LinkedIn. BTW, we are paid Bitwarden customer, and our Helpdesk was not too happy when Bitwarden update resulted unexpected prompt interrupting WebAuthn authentication flow for users. )
  - Borealid 3y ago
    You don't need a password to prevent account enumeration; you can send people who choose a nonexistent account a bogus credential that the token won't accept. You have to display the password prompt for invalid accounts to avoid enumeration without webauthn too...
wkat4242 3y ago
I wish the support of real tokens would also benefit from the attention Passkeys receive though. They use the same protocol after all. On Firefox on Android I still get the message that physical tokens are not supported on mobile when I try to authenticate to e.g. PayPal. I don't really like Passkeys because I prefer the security of real tokens (yubikeys). And I don't want to register with big tech companies to be able to use passkeys - for example I don't even have a google account logged in on my android phone.
- stavros 3y ago
  I use all the same things as you, but PayPal doesn't use WebAuthn (that I can see). It's just 2FA hardware tokens, which should work fine (and I do get a prompt to use a USB key on Firefox).
  - lxgr 3y ago
    > PayPal doesn't use WebAuthn [...] It's just 2FA hardware tokens That's WebAuthN too (if you mean USB-connected FIDO tokens).
  - wkat4242 3y ago
    Yes they do now! And it was firefox on mobile. Desktop firefox didn't support CTAP2 mode either except on Windows but it was fixed a few versions back (finally!)
- microtonal 3y ago
  One issue is the limited support for resident keys on many hardware tokens. IIRC the limit on recent YubiKey 5 firmware versions is 25 resident keys. As Passkey adoption accelerates, people will hit that limit rather quickly. Also the UI around managing resident keys is not great and uncoupled from where they are typically used (the browser). Finally, only a tiny part of the population uses dedicated hardware tokens, whereas pretty much all popular password managers supports or will support Passkeys (Apple Keychain, 1Password, whatever the Chrome password manager is called, Samsung Pass, etc.). So, it’s not surprising that hardware tokens are tested less these days. (I don’t think that is a good, just trying to speculate on the reasons.)
snowstormsun 3y ago
I'd switch to passkeys immediately where possible, if Android/Google would allow third party password manager apps to provide and store them. Afaik they still want you to use the Google Password Manager, which is not an option for me.
- dyml 3y ago
  You can use any passkey provider app. I work at Bitwarden and we’re building mobile passkeys for android right now. We can do the e2e sync, but if you want you can always self host Bitwarden server and just use our clients app.
  - josteink 3y ago
    This is such a big small thing. Patiently waiting for passkey support on Bitwarden iOS to replace all my passwords everywhere. Do you guys have any rough idea how far away you are from launch? Is it weeks? Months? Quarters?
    - dyml 3y ago
      Very soon
      - josteink 3y ago
        Any testflight one can join to get in on a early beta? I'm eager to give it a try.
        dyml 3y ago
        Send an email to me at aaberg@bitwarden.com and I’ll look into it!
    - lxgr 3y ago
      I'm already seeing Bitwarden as an option for Passkey authentication on iOS! Apparently the app already exposes itself to iOS as a WebAuthN backend (or the API is the same as that used for password managers). Unfortunately that API doesn't seem to be wired to anything in the app yet, so selecting it inevitably fails.
rettichschnidi 3y ago
Meanwhile, Microsoft sabotages FIDO2/Firefox on office.com: https://news.ycombinator.com/item?id=38502340 https://news.ycombinator.com/item?id=38502340
cihuahuas 3y ago
[flagged]
jillesvangurp 3y ago
Passkeys so far look like a repeat of previous efforts to move away from passwords or make logins more secure (e.g. Openid, webauthn, 2FA). There are two problems: 1) this stuff is hard to explain to end users. This is the reason it's not widely used yet even on the handful of platforms that provide this option. 2) Big companies are being very proprietary and selfish about this stuff. So you have Google insisting on Chrome and Google password manager and insisting this all gets routed via your phone. And Apple does the same with Safari and their password manager. And of course MS is doing their own thing. Meanwhile, Firefox doesn't even support this stuff properly yet so it's impossible to roll out something that only supports passkeys and nothing else. The second one is the big problem because companies like Google and Microsoft get all starry eyed when they realize that all passkey approvals go via property they control. So, they have a natural tendency to prevent people from using anything else than that. The same happened with OpenID. Both MS and Google were all over it. But they couldn't bring themselves to federate each other's identities. I mean people signing into gmail with a hotmail address or vice versa. The thought alone was causing panics at executive levels in both companies. So, they crippled it and over complicated it. And then proceeded to waffle on the standards so they could have mutually incompatible implementations be standard.
- syhol 3y ago
  Not sure it's that hard to explain the basics. Passkeys are like very big passwords that password manages store for you, only with extra features. I don't think you need to touch on the public key encryption side of it. Big Tech don't insist on their solutions, they just default to it which I think is fair. Also WebAuthN is passkeys from what I understand. Not a previous effort.
  - jillesvangurp 3y ago
    > from what I understand That about summarizes the problem. It's definitely related to webauthn. But not the same thing. Which is why Firefox supports one but not the other (yet, I believe they are working on it). You could do webauthn without a hardware dongle but nobody seems to want to implement that until passkeys. Now your phone effectively becomes the hardware dongle. And if you then get rid of passwords, you are down to one factor. You had better not lose your phone, just saying. Big Tech insists on their version of the tech which makes them the center of your universe, at the cost of their competitors and their users. Which is why we still have password logins everywhere. The solutions to move away from that have been around for some time. But big companies can't agree with each other on how to do this such that they don't lose users to each other. So, MS pretends to be the center of your world. So does Google. And Meta. And of course Apple. And a few others. And when you setup 2FA you are guided to use the Google Authenticator. Which of course annoys the hell out of competitors who then do something else or only reluctantly support 2FA or come up with some wacky scheme to do something with SMS. Passkeys look like they are more of the same so far.
traceroute66 3y ago
My main beef with Passkeys is that there is no hardware attestation. With Yubikeys, the relying party has a cryptographic way to ensure that the key is generated on a Yubikey, and can even validate the specific Yubikey hardware version. AFAIK, with Passkeys you can't do that. You have to trust that it was generated and stored securely and not just some software emulation. The Passkey manufacturers argue this is because Passkeys are intended to be transferable between devices. But I can't believe there is no form of attestation possible just because you are transferring the keys around, afterall it should be possible to attest that "these bytes were signed by a key in a $this_device secure enclave and the key was securely imported to the device secure enclave via $manufacturer Passkey process" or something along those lines, no ?
- voxic11 3y ago
  It's funny because in the last post on this topic everyone was complaining that the problem with passkeys is that they can't be transferred between devices like passwords can.
  - lxgr 3y ago
    Sometimes different people have different objections to a single thing. There isn’t one generic “anti-Passkey” archetype.
- stavros 3y ago
  WebAuthn supports attestation, so passkeys must too. Usually I hear the opposite argument, that people don't want to use WebAuthn/passkeys because of attestation.
  - lxgr 3y ago
    > WebAuthn supports attestation, so passkeys must too. They can (it's optional, i.e. not a specification-"must"), but so far they don't. Apple explicitly unshipped attestation when they introduced keychain-synced Passkeys; I think Google also had attestation for a while on Android and did the same. Requiring attestation was actually a way to opt out of passkey synchronization on iOS for that very reason, but Apple frustratingly just removed the option rather than leaving the choice to relying parties (websites). This makes their passkeys unusable for some regulated/sensitive use cases that did depend on attestation. > Usually I hear the opposite argument Different people have different needs and priorities. Authentication is a large surface with multiple actors and sometimes conflicting goals.
jwally 3y ago
With SMS otp, it's possible to associate 2 phone numbers (or more) to a single account. That way if my wife and I can use her Amazon account. Can the same paradigm be grafted to pass-keys/webauthn? Maybe a useful flow could be You can log in with any of the following: a) passkey b) email and sms and password verification c) customer service Its not 100% air tight; but it seems better than the current state of affairs.
- lxgr 3y ago
  This is completely up to the relying party (i.e. website) and definitely possible. WebAuthN makes explicit accomodations for a user having multiple credentials registered on their device, and they can even be of different types (e.g. you can have one shared hardware authenticator, your iCloud Keychain passkey and your wife's Bitwarden-stored passkey all registered on the same account). I have multiple passkeys registered with some sites, e.g. Github (and conversely I use many sites that only allow me to associate a single phone number, which I better never lose access to...)
  - cchance 3y ago
    This seems like the standard to allow multiple passkeys, which makes sense... the passkeys are device specific, (not considering synced ones like bitwarden)... So if i login on my windows pc with a passkey i also want to be able to login on my iphone with a passkey, if they didn't support multiple passkeys per account this wouldn't be possible, even without taking into account different people in a family having a passkey.
    - lxgr 3y ago
      Passkeys are very much intended to be synced by various WebAuthN stakeholders, for better or worse. But yes, any site that e.g. wants to support roaming authenticators ("Yubikeys") needs to support multiple credentials, or recovery from a device loss gets very tricky.
Galanwe 3y ago
There are some things I don't quite understand with passkeys. People say it's meant to replace login/password, not act as 2FAs. Yet last I tried on Google having a login/password is mandatory, the passkey is just used as 2FA. So what's the point to convert my 2FA yubikey to a passkey? Also, my understanding is that passkeys are standalone keys. There doesn't seem to be any support for federation of various keys by having them signed by a master key, as in PGP, so that I can actually prove on service X that I'm also the same user on service Y, thus being able to link or verify accounts easily.
- kichik 3y ago
  I think for Google and Apple this is more of an agreed upon API to replace the multiple "login with X" buttons. Instead of having "Login with Google", "Login with Apple", "Login with Facebook", and "Login with GitHub", there is just one login button that uses your ecosystem of choice. That's the part that should make the process simple for users. Less choice. In other words, it's to help you easily login to everything else. But your main account would still be protected by a password. Otherwise you wouldn't be able to replace a lost device.
- lxgr 3y ago
  > People say it's meant to replace login/password, not act as 2FAs. They can, but they don't have to. It's up to the relying party (i.e. the website accepting them) to use them as a single-factor, two-factor, or just as yet another second-factor authentication solution. Some websites make single-factor use contingent on the passkey's capabilities (e.g. user verification, only physical authenticators, only trusted-vendor physical authenticators through attestation etc). I believe Google does that and allows some users, based on these properties I believe, to use them as a single factor (the option is called "skip password when possible" in the account settings). This is theoretically good for flexibility (one API allowing many use cases), but unfortunately quite confusing to users as the user experience can vary widely. One gripe I have with the API is that the default "user verification preference" is "preferred", which makes my hardware key prompt me for my PIN for every single authentication, even for second-factor usages that could just as well pick "discouraged" and use my as the other factor. > There doesn't seem to be any support for federation of various keys by having them signed by a master key, as in PGP, so that I can actually prove on service X that I'm also the same user on service Y, thus being able to link or verify accounts easily. That's correct – WebAuthN is intentionally a quite different model from GPG. That allows it to get by without key revocation, which would introduce a lot of complexity otherwise. The specification allows something practically similar, though: Individual authenticators can be implemented almost statelessly, holding only a single root key that then derives (or unwraps) the per-credential keys from the key handle. It's a bit different from the federation you mention (all authenticators share a key rather than delegating signature privileges). But it's not commonly implemented, as far as I can tell.
qudat 3y ago
At pico.sh we are developing a completely different type of passwordless authentication all leveraging what developers are already familiar with: SSH keys. No passwords, no JWTs, no bearer tokens, no complicated webauthn, and no passkeys. All we need is an SSH keypair. We have a demo if you are interested in learning more: https://pico.sh/tunnels https://pico.sh/tunnels
- megous 3y ago
  So what prevents any process from the developer machine connecting to 1337 port and being treated as authenticated?
  - josephcsible 3y ago
    Couldn't you use "-m owner" in ip{,6}tables to do that?

158 points by paulgerhardt 3y ago

Let me add an operations and service delivery perspective. Our company relies solely on Passkeys for sign-in. The experience is both insanely good yet annoying. A colleague summarized our latest Passkey issues showing the ecosystem remains fragile for enterprises: Fragile Passkey Ecosystem for Enterprises https://news.ycombinator.com/item?id=39742107 https://news.ycombinator.com/item?id=39742107

crote 3y ago

> With a security key, the private key is stored inside a secure element and an attacker with physical access to a security key would not be able to recover the private key value. This glances over one of the most powerful features of non-resident (not Passkey, regular U2F / Webauthn) keys: you don't actually need to store the private key on the client! Non-resident keys only use a single per-token secret key. On registration a random number is generated, which is used together with the secret key to derive a public/private keypair used for the whole authentication flow. This random number is sent to the server along with some check digits, forming a token ID. On authentication the server sends the ID back to the token, who uses it to again derive the same keypair which is for authentication. The biggest benefit is that a single cheap token can support an unlimited number of websites. It only needs to store a single secret, after all. If the user has multiple hardware tokens, just send all the numbers one-by-one and see which one is accepted by the token. This also provides essentially perfect privacy: the token doesn't store anything about the websites or accounts it is used with, so an attacker gaining control over a token cannot easily determine where it can be used and has to manually try each website one-by-one by actually visiting the site and trying potential usernames. With resident keys ("Passkeys") the website does not know which ID to return, because a username is not yet known so you'd have to try all registered IDs for all users to look for a match. That's impossible, so the token needs to store some per-user-account data which allows it to map from a domain name to one or more stored credentials and their IDs (which allow both authentication and a mapping to a specific user on login). This places a hard upper limit to the number of Passkey websites a security key can support, and in practice forces you to use a smartphone or computer instead if you want to register a nontrivial number of websites. There are also privacy risks here, as it must by definition be possible to query a token for the existence of an account at a website. Passkeys have been heavily pushed by major tech companies as a replacement for both a username, password, and 2FA method - but (assuming proper 2FA) it's a strict downgrade with serious drawbacks. It's really sad to see companies ditching proper Webauthn 2FA support when switching to Passkeys, because it's making security worse for the people who actually care about it.

dyml 3y ago
You make a valid point about “non-resident” WebAuthn 2FA being great 2FA. However, passkeys are also great, and they depend on your context…. Most people are in the passkey context. For people who are not knee-deep I think we can explain it a bit better, why passkeys replaces passwords: With non-resident (2FA keys) you need to identify your account first. Since you don’t want to have account enumeration, this means doing a primary authentication, e.g. passwords. With passkeys, the website can just ask your browser) to sign in with any of the accounts it has passkeys for; which result in a one click sign in. While hardware backed Security Keys for 2FA is great 2FA, there’s a tangible cost, both in UX and $ that leaves many users left out (not everyone can afford $20 for a security key) Source: I work at Bitwarden building our Passkey API for developers. We support both 2FA and passkeys, both in the API service and in our password manager. Feel free to ask my anything related.
- ivlad 3y ago
  > Since you don’t want to have account enumeration, this means doing a primary authentication, e.g. passwords. Nothing prevents site from sending a blob of random data when real key is not found. > While hardware backed Security Keys for 2FA is great 2FA, there’s a tangible cost, both in UX and $ that leaves many users left out (not everyone can afford $20 for a security key) Both major desktop operating systems come with WebAuthn support - Windows via Windows Hello and macOS with Secure Enclave backed key store. That not a problem at all in corp environment. Buying a Yubikey (or two) for each employee in the company is minimal cost comparing to laptop, desk, chair, software licenses We use WebAuthn as the first factor, and we love it because it completely eliminated password brute force problem. Password attacks (brute force and stuffing) is a much bigger problem, than account enumeration, especially in corp environments where usernames follow a name-based pattern and everybody is on LinkedIn. BTW, we are paid Bitwarden customer, and our Helpdesk was not too happy when Bitwarden update resulted unexpected prompt interrupting WebAuthn authentication flow for users. )
- Borealid 3y ago
  You don't need a password to prevent account enumeration; you can send people who choose a nonexistent account a bogus credential that the token won't accept. You have to display the password prompt for invalid accounts to avoid enumeration without webauthn too...

wkat4242 3y ago

I wish the support of real tokens would also benefit from the attention Passkeys receive though. They use the same protocol after all. On Firefox on Android I still get the message that physical tokens are not supported on mobile when I try to authenticate to e.g. PayPal. I don't really like Passkeys because I prefer the security of real tokens (yubikeys). And I don't want to register with big tech companies to be able to use passkeys - for example I don't even have a google account logged in on my android phone.

stavros 3y ago
I use all the same things as you, but PayPal doesn't use WebAuthn (that I can see). It's just 2FA hardware tokens, which should work fine (and I do get a prompt to use a USB key on Firefox).
- lxgr 3y ago
  > PayPal doesn't use WebAuthn [...] It's just 2FA hardware tokens That's WebAuthN too (if you mean USB-connected FIDO tokens).
- wkat4242 3y ago
  Yes they do now! And it was firefox on mobile. Desktop firefox didn't support CTAP2 mode either except on Windows but it was fixed a few versions back (finally!)
microtonal 3y ago
One issue is the limited support for resident keys on many hardware tokens. IIRC the limit on recent YubiKey 5 firmware versions is 25 resident keys. As Passkey adoption accelerates, people will hit that limit rather quickly. Also the UI around managing resident keys is not great and uncoupled from where they are typically used (the browser). Finally, only a tiny part of the population uses dedicated hardware tokens, whereas pretty much all popular password managers supports or will support Passkeys (Apple Keychain, 1Password, whatever the Chrome password manager is called, Samsung Pass, etc.). So, it’s not surprising that hardware tokens are tested less these days. (I don’t think that is a good, just trying to speculate on the reasons.)

snowstormsun 3y ago

I'd switch to passkeys immediately where possible, if Android/Google would allow third party password manager apps to provide and store them. Afaik they still want you to use the Google Password Manager, which is not an option for me.

dyml 3y ago
You can use any passkey provider app. I work at Bitwarden and we’re building mobile passkeys for android right now. We can do the e2e sync, but if you want you can always self host Bitwarden server and just use our clients app.
- josteink 3y ago
  This is such a big small thing. Patiently waiting for passkey support on Bitwarden iOS to replace all my passwords everywhere. Do you guys have any rough idea how far away you are from launch? Is it weeks? Months? Quarters?
  - dyml 3y ago
    Very soon
    - josteink 3y ago
      Any testflight one can join to get in on a early beta? I'm eager to give it a try.
      - dyml 3y ago
        Send an email to me at aaberg@bitwarden.com and I’ll look into it!
  - lxgr 3y ago
    I'm already seeing Bitwarden as an option for Passkey authentication on iOS! Apparently the app already exposes itself to iOS as a WebAuthN backend (or the API is the same as that used for password managers). Unfortunately that API doesn't seem to be wired to anything in the app yet, so selecting it inevitably fails.

rettichschnidi 3y ago

Meanwhile, Microsoft sabotages FIDO2/Firefox on office.com: https://news.ycombinator.com/item?id=38502340 https://news.ycombinator.com/item?id=38502340

cihuahuas 3y ago

[flagged]

jillesvangurp 3y ago

Passkeys so far look like a repeat of previous efforts to move away from passwords or make logins more secure (e.g. Openid, webauthn, 2FA). There are two problems: 1) this stuff is hard to explain to end users. This is the reason it's not widely used yet even on the handful of platforms that provide this option. 2) Big companies are being very proprietary and selfish about this stuff. So you have Google insisting on Chrome and Google password manager and insisting this all gets routed via your phone. And Apple does the same with Safari and their password manager. And of course MS is doing their own thing. Meanwhile, Firefox doesn't even support this stuff properly yet so it's impossible to roll out something that only supports passkeys and nothing else. The second one is the big problem because companies like Google and Microsoft get all starry eyed when they realize that all passkey approvals go via property they control. So, they have a natural tendency to prevent people from using anything else than that. The same happened with OpenID. Both MS and Google were all over it. But they couldn't bring themselves to federate each other's identities. I mean people signing into gmail with a hotmail address or vice versa. The thought alone was causing panics at executive levels in both companies. So, they crippled it and over complicated it. And then proceeded to waffle on the standards so they could have mutually incompatible implementations be standard.

syhol 3y ago
Not sure it's that hard to explain the basics. Passkeys are like very big passwords that password manages store for you, only with extra features. I don't think you need to touch on the public key encryption side of it. Big Tech don't insist on their solutions, they just default to it which I think is fair. Also WebAuthN is passkeys from what I understand. Not a previous effort.
- jillesvangurp 3y ago
  > from what I understand That about summarizes the problem. It's definitely related to webauthn. But not the same thing. Which is why Firefox supports one but not the other (yet, I believe they are working on it). You could do webauthn without a hardware dongle but nobody seems to want to implement that until passkeys. Now your phone effectively becomes the hardware dongle. And if you then get rid of passwords, you are down to one factor. You had better not lose your phone, just saying. Big Tech insists on their version of the tech which makes them the center of your universe, at the cost of their competitors and their users. Which is why we still have password logins everywhere. The solutions to move away from that have been around for some time. But big companies can't agree with each other on how to do this such that they don't lose users to each other. So, MS pretends to be the center of your world. So does Google. And Meta. And of course Apple. And a few others. And when you setup 2FA you are guided to use the Google Authenticator. Which of course annoys the hell out of competitors who then do something else or only reluctantly support 2FA or come up with some wacky scheme to do something with SMS. Passkeys look like they are more of the same so far.

traceroute66 3y ago

My main beef with Passkeys is that there is no hardware attestation. With Yubikeys, the relying party has a cryptographic way to ensure that the key is generated on a Yubikey, and can even validate the specific Yubikey hardware version. AFAIK, with Passkeys you can't do that. You have to trust that it was generated and stored securely and not just some software emulation. The Passkey manufacturers argue this is because Passkeys are intended to be transferable between devices. But I can't believe there is no form of attestation possible just because you are transferring the keys around, afterall it should be possible to attest that "these bytes were signed by a key in a $this_device secure enclave and the key was securely imported to the device secure enclave via $manufacturer Passkey process" or something along those lines, no ?

voxic11 3y ago
It's funny because in the last post on this topic everyone was complaining that the problem with passkeys is that they can't be transferred between devices like passwords can.
- lxgr 3y ago
  Sometimes different people have different objections to a single thing. There isn’t one generic “anti-Passkey” archetype.
stavros 3y ago
WebAuthn supports attestation, so passkeys must too. Usually I hear the opposite argument, that people don't want to use WebAuthn/passkeys because of attestation.
- lxgr 3y ago
  > WebAuthn supports attestation, so passkeys must too. They can (it's optional, i.e. not a specification-"must"), but so far they don't. Apple explicitly unshipped attestation when they introduced keychain-synced Passkeys; I think Google also had attestation for a while on Android and did the same. Requiring attestation was actually a way to opt out of passkey synchronization on iOS for that very reason, but Apple frustratingly just removed the option rather than leaving the choice to relying parties (websites). This makes their passkeys unusable for some regulated/sensitive use cases that did depend on attestation. > Usually I hear the opposite argument Different people have different needs and priorities. Authentication is a large surface with multiple actors and sometimes conflicting goals.

jwally 3y ago

With SMS otp, it's possible to associate 2 phone numbers (or more) to a single account. That way if my wife and I can use her Amazon account. Can the same paradigm be grafted to pass-keys/webauthn? Maybe a useful flow could be You can log in with any of the following: a) passkey b) email and sms and password verification c) customer service Its not 100% air tight; but it seems better than the current state of affairs.

lxgr 3y ago
This is completely up to the relying party (i.e. website) and definitely possible. WebAuthN makes explicit accomodations for a user having multiple credentials registered on their device, and they can even be of different types (e.g. you can have one shared hardware authenticator, your iCloud Keychain passkey and your wife's Bitwarden-stored passkey all registered on the same account). I have multiple passkeys registered with some sites, e.g. Github (and conversely I use many sites that only allow me to associate a single phone number, which I better never lose access to...)
- cchance 3y ago
  This seems like the standard to allow multiple passkeys, which makes sense... the passkeys are device specific, (not considering synced ones like bitwarden)... So if i login on my windows pc with a passkey i also want to be able to login on my iphone with a passkey, if they didn't support multiple passkeys per account this wouldn't be possible, even without taking into account different people in a family having a passkey.
  - lxgr 3y ago
    Passkeys are very much intended to be synced by various WebAuthN stakeholders, for better or worse. But yes, any site that e.g. wants to support roaming authenticators ("Yubikeys") needs to support multiple credentials, or recovery from a device loss gets very tricky.

Galanwe 3y ago

There are some things I don't quite understand with passkeys. People say it's meant to replace login/password, not act as 2FAs. Yet last I tried on Google having a login/password is mandatory, the passkey is just used as 2FA. So what's the point to convert my 2FA yubikey to a passkey? Also, my understanding is that passkeys are standalone keys. There doesn't seem to be any support for federation of various keys by having them signed by a master key, as in PGP, so that I can actually prove on service X that I'm also the same user on service Y, thus being able to link or verify accounts easily.

kichik 3y ago
I think for Google and Apple this is more of an agreed upon API to replace the multiple "login with X" buttons. Instead of having "Login with Google", "Login with Apple", "Login with Facebook", and "Login with GitHub", there is just one login button that uses your ecosystem of choice. That's the part that should make the process simple for users. Less choice. In other words, it's to help you easily login to everything else. But your main account would still be protected by a password. Otherwise you wouldn't be able to replace a lost device.
lxgr 3y ago
> People say it's meant to replace login/password, not act as 2FAs. They can, but they don't have to. It's up to the relying party (i.e. the website accepting them) to use them as a single-factor, two-factor, or just as yet another second-factor authentication solution. Some websites make single-factor use contingent on the passkey's capabilities (e.g. user verification, only physical authenticators, only trusted-vendor physical authenticators through attestation etc). I believe Google does that and allows some users, based on these properties I believe, to use them as a single factor (the option is called "skip password when possible" in the account settings). This is theoretically good for flexibility (one API allowing many use cases), but unfortunately quite confusing to users as the user experience can vary widely. One gripe I have with the API is that the default "user verification preference" is "preferred", which makes my hardware key prompt me for my PIN for every single authentication, even for second-factor usages that could just as well pick "discouraged" and use my as the other factor. > There doesn't seem to be any support for federation of various keys by having them signed by a master key, as in PGP, so that I can actually prove on service X that I'm also the same user on service Y, thus being able to link or verify accounts easily. That's correct – WebAuthN is intentionally a quite different model from GPG. That allows it to get by without key revocation, which would introduce a lot of complexity otherwise. The specification allows something practically similar, though: Individual authenticators can be implemented almost statelessly, holding only a single root key that then derives (or unwraps) the per-credential keys from the key handle. It's a bit different from the federation you mention (all authenticators share a key rather than delegating signature privileges). But it's not commonly implemented, as far as I can tell.

qudat 3y ago

At pico.sh we are developing a completely different type of passwordless authentication all leveraging what developers are already familiar with: SSH keys. No passwords, no JWTs, no bearer tokens, no complicated webauthn, and no passkeys. All we need is an SSH keypair. We have a demo if you are interested in learning more: https://pico.sh/tunnels https://pico.sh/tunnels

megous 3y ago
So what prevents any process from the developer machine connecting to 1337 port and being treated as authenticated?
- josephcsible 3y ago
  Couldn't you use "-m owner" in ip{,6}tables to do that?