8 ms·

Passkeys for Infrastructure

62 points by carride 4y ago

willio58 4y ago
This is exciting, I love that we're moving toward passkeys. When I tell non-devs that passwords will be going away in the years to come they almost can't understand what I'm saying. Like we've all lived this life of passwords for as long as we can remember so the idea of not getting having to click "Forgot my password" once a day is foreign to us. It's sort of like we've been gaslighted into thinking this is how it has to be for years and it's crumbling away now. Meanwhile I'm sure a decade from now we'll all look back and say "Remember when we had to type _secret characters_ into a little box to log in to an app/site?"
- candiddevmike 4y ago
  The problem with passkeys IMO is they typically aren't portable between devices, and if they are, they will have some of the same problems as passwords. A long passphrase will probably have the same threat profile as a portable passkey, but with an easier implementation.
  - toomuchtodo 4y ago
    For the vast majority of your layman use cases, passkeys are perfect because the switch rate between ecosystems is low. My mid 90s grandmother is not able to use a password manager, she's just not capable. Same for my mid 60s in laws. Passkeys fix this for them. If your use case requires heterogenous ecosystem support, it might make sense to wait for your preferred password manager to have passkey support (to have an independent sync fabric). Worst case scenario, you have multiple passkeys per service identity/web property, one in each sync ecosystem (if the relying party supports it). Still better than passwords! If your SSO provider does't support passwordless/passkeys, loudly complain to them :) Azure Active Directory supports it, I have worked with a team to implement it. (great post btw to the Teleport folks, both content and visual appeal)
    - candiddevmike 4y ago
      Hopefully someday some smart person invents a standard, secure way of handling enrollment/forgot my pass(key|word), as that will always be the weakest link. As much as it freaks some people out, a cryptographic national ID would be really helpful for this, IMO.
      - toomuchtodo 4y ago
        https://stripe.com/identity https://stripe.com/identity Agreed about a cryptographic national ID. One day! Login.gov is already prototyping using USPS for in person identity verification, we'll get there. https://news.ycombinator.com/item?id=34735448 https://news.ycombinator.com/item?id=34735448
  - ryukafalz 4y ago
    Passkeys (in the sense the article is referring to, which is to say FIDO2 passkeys) are explicitly portable between devices. And the difference is they're always unique per-site in a way that passwords are not necessarily. It's possible to approach the security of passkeys if you always use unique passwords per-site (with e.g. a password manager) but you're still then vulnerable to phishing unlike with passkeys.
    - deleted 4y ago
      [deleted]
    - Groxx 4y ago
      Most password managers check the urls before filling.
      - vlovich123 4y ago
        That doesn't prevent phishing attacks where the user goes "uggh. my password manager isn't working again. I'm going to copy-paste the password in by hand".
        danShumway 4y ago
        Similarly, passkeys don't necessarily block the phishing attack where the user goes, "ugh, this dongle/phone isn't working, I guess I need to put in one of these one-time recovery codes." Account recovery is still going to be a weak point here, and it's a kind of double-edged sword. If you're really strict about passkeys getting shared between devices or manually accessed, then users are going to lose access to accounts a lot, and recovery methods are going to get easier to accommodate those situations, which will in turn re-open phishing vulnerabilities. On the other hand, if services don't implement those recovery options, then the first time a user gets burned with losing access to an account for a week, they're going to stop using passkeys, and broader adoption will be halted.
    - danShumway 4y ago
      > are explicitly portable between devices Yes and no. Passkeys are portable in the sense that Apple/Google have already compromised on the "keys should never leave your device" standard and have set up backup/restore options for if you lose your phone within their ecosystem. This is portability, but extremely limited portability. It's not portability in the sense of allowing you to migrate between ecosystems. There is also some promise that passkeys will be portable between Google/Apple ecosystems in the future. The fact that the FIDO alliance refuses to build a client-independent way of moving between ecosystems and instead seems to be suggesting that migration should be handled with environment-dependent implementations severely limits how useful that portability will be. Passkeys are also "portable" in the sense that you can register multiple keys with a single site. But this is not actual portability, it's just backup/replication. When you get a new device outside of the ecosystem, you can't port your passkeys anywhere. What you can do is register that device with every single site you have an account with. This should obviously be seen as a barrier to the goal of replacing passwords entirely, but for some reason it's not seen that way. To understand the problem, we have to stop thinking of the current world where there are like 4 or 5 sites that have passkeys attached to them; you have to instead think of a world where passkeys won and a user has hundreds of sites with passkeys attached to them, many of which they might not have visited in nearly a decade. And when they buy a new device, they have to migrate all of them. That's not portability, that is not something that a non-techie user wants to go through. > you're still then vulnerable to phishing unlike with passkeys. Extremely important to mention in these discussions, passkeys are phishing-resistant, not phishing-proof. We gave up on phishing-proof when Google and Apple started doing backup and restore within their own ecosystems. Your iCloud credentials can be phished, at which point your passkeys can also be phished by setting up a new iPhone. Arguably, the Yubikey/dedicated-token approach was phishing-proof (for at least a somewhat narrow definition of phishing), but that's not the approach that mainstream platforms are going for. If you're using an iPhone, your passkeys already get backed up. That ship has sailed, the only fight remaining is whether or not you should be able to import them to something that's not an Apple device.
arianvanp 4y ago
I wish SSO providers were able to hook into this Passkey mechanism. Instead of storing Passkeys in iCloud for sync instead we could store them at the SSO provider
- jaywalk 4y ago
  What? Why? How would this improve anything?
- convolvatron 4y ago
  you get a system where you can finally own your own identity and the first thought you have is to how to reaquire that dependency on a for-profit entity
  - arianvanp 4y ago
    The opposite. Now there is just one hardcoded SSO provider: Apple iCloud. Which means you're stuck to one provider. I'd like this to be opened up. Open spec for being able to sync passkeys
    - acdha 4y ago
      It’s Apple, Google, or Microsoft now and soon to be 1Password and others. None of those are hard-coded on the sites using it - the concern is that you can’t port keys between, say, iOS Safari and Windows Edge but you can already register keys from both because it’s not SSO but rather a different PKI scheme.
- sebk 4y ago
  I'm with you here and have been parroting this in just about every Webauthn thread on HN, except maybe with the exception that I think it's password manager vendors who are more interested -- several of them have joined the FIDO alliance in the past year. I think having an open sync fabric that is vendor agnostic will be important going forwards. Users have a multitude of devices, usually not from the same vendor, and hybrid transport is not enough to mitigate the fact that sync fabrics are not interoperable. The risk is that password manager vendors will end up implementing virtual authenticators backed by software instead of a secure element like a Yubikey, Secure Enclave or TPM. I'd be interested in the the FIDO Alliance helping bring OS APIs to leverage secure elements to import and export key material that belongs to a particular third-party fabric. It's clearly a sensitive issue because establishing trust between devices, and thus a sync fabric, is a strong phishing target. I also speculate that password manager vendors (e.g. 1Password) and authenticator vendors (e.g. YubiCo) could mutually benefit from agreeing on some APIs to establish trust between authenticators and allow import/export, bypassing the OS vendors.
candiddevmike 4y ago
> I predict that 2023 will be the year of Passkeys. I remain unconvinced that Regular Users will find passkeys as necessary/useful as the rest of the industry does, especially older users. Will be interesting to see how pervasive passkeys become.
- vdelitz 4y ago
  Pretty good point you address here. I've been working on passkeys for a while and from our experience most users find it pretty useful, as long as it's not named passkey. Most of them just think they've used Face ID to login to a website - but yes overall adoption will be interesting to see.
- deleted 4y ago
  [deleted]
sneak 4y ago
You can't use Passkeys on iOS without iCloud, and you can't get an Apple ID without a phone number, which frequently maps to real-world ID. This means that soon your logins will be tied to your ID.
- Freak_NL 4y ago
  If it's just WebAuthn under the hood, wouldn't discrete WebAuthn devices work as well? That is, separate security keys (USB or NFC), or WebAuthn directly in the browser of a smartphone using on-device cryptography. Or did Apple manage to helpfully extend this standard into something requiring iWhatever accounts?
  - ratorx 4y ago
    I use a YubiKey as well as iOS everywhere I use WebAuthn (currently only for 2FA). The only sites I don’t are the ones which don’t support more than 1 key. I haven’t come across any websites that restrict it to just iOS. I’m not even sure it would be easy (without fingerprinting), because the browser usually handles verification (and gives options for security key and iOS).
- echeese 4y ago
  Passkeys are just built on top of WebAuthn, which can also use generic platform authenticators such as touchid or windows hello, or fido authenticators like a yubikey.
- ezfe 4y ago
  Your assumptions are all true, but your conclusion is not any more true because of the iCloud requirement.
root5 4y ago
Companies that write „WebAuthN“ deserve no respect.
vdelitz 4y ago
I think passkeys adoption will accelerate once bigger consumer-oriented players (e.g. AirBnb) introduce them to a wider audience. PayPal, eBay and Kayak made the right, slow steps, but once more of these larger players offer passkeys as login, we'll probably see them a lot more around smaller companies, too.
benarent 4y ago
OP here, thanks for posting! Happy to Answer any questions. I have to give our a shoutout to Alan at Teleport for all his work on Passwordless and his work to make Passwordless / TouchID work with MacOS CLI https://github.com/gravitational/teleport/blob/master/rfd/0054-passwordless-macos.md https://github.com/gravitational/teleport/blob/master/rfd/00...
tjoff 4y ago
Is there any writeup about passkeys privacy? Tie everything to apple/whoever is pretty darn dystopian. And the "second factor" as described in this article doesn't exactly sound enticing.
- arianvanp 4y ago
  There is a large section on privacy in the spec. https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations https://www.w3.org/TR/webauthn-2/#sctn-privacy-consideration... However Passkeys puts apple in a position of the Authenticator which is the riskiest part in terms of privacy.
  - tjoff 4y ago
    Thank you, seems quite approachable. A different authenticator is paramount but the question is how secure and private a self-hosted solution can be, with reasonable effort.
- sebk 4y ago
  Apple has pretty good security whitepapers about how it does end-to-end encryption for Keychain items like this. If you're more broadly concerned about Apple not honoring those, having (un)intentional vulnerabilities, or them having the ability to shut you off from your account, then you can always fall back to non-synced FIDO2 devices, like a Yubikey. The underlying technology in both is the same: WebAuthn. I'd imagine local-only is also how MacOS and iOS behave if you're not logged in to iCloud. If you're more interested in WebAuthn privacy more generally, there's quite a bit of it in the WebAuthn specification itself, since it was an important goal of the design.
  - tjoff 4y ago
    > then you can always fall back to non-synced FIDO2 devices No, you can not. Because they are completely broken for a lot of use-cases, especially when you can only add one or two of them makes them worse than even passwords in many situations.
zacharyvoase 4y ago
I see a few obstacles with Passkeys as-implemented: * They effectively entrust the keys to your entire digital life to (right now) either Google or Apple. Account compromise, or a ToS-related suspension, becomes catastrophic. * Domain changes happen (acquisitions, rebrands, etc.), and there is no way to share or migrate passkeys between domains. Right now the best you can do is a highly manual process involving the user authenticating on the old domain, registering a new credential on the new domain, and somehow linking them. This process itself could be highly vulnerable to interception, since every site would likely have to build a bespoke way of doing it. * There's no way to migrate your passkeys between ecosystems. So if you're an iPhone user, and all your logins are iCloud Passkeys, it becomes really hard to switch to Android. * Password-sharing is regrettably used a lot right now, but it's the simplest thing that works. For example, I and my husband have a shared 1Password vault for things like utility and streaming account logins. Right now none of the Passkey syncing providers support anything like that (and I feel like they won't, because it'd be a huge vector for scams). I think the password is going to stick around until these issues are addressed.
- goalieca 4y ago
  1Password does have passkeys in the works. https://www.future.1password.com/passkeys/ https://www.future.1password.com/passkeys/
  - danShumway 4y ago
    Does 1Password have a solution planned for migrating to other password managers? Can I migrate my "logins" from Android to 1Password in a single action (as opposed to going account-by-account and adding a new key)? Being tied to 1Password is better than being tied to iOS, but it's a far cry from real portability.
    - goalieca 4y ago
      https://support.1password.com/export/ https://support.1password.com/export/
noahtallen 4y ago
A lot of comments in this thread are discussing vendor lock-in with Apple or Google. 1Password is working on passkey support already (https://www.future.1password.com/passkeys/ https://www.future.1password.com/passkeys/) and I imagine others will follow suit. Vendor lock-in isn’t part of the spec, it just happens that in these early days, the OS-level authenticators are the main ones implemented (as are other hardware authenticators). In the mid to long term (e.g. by the time websites start supporting this), I don’t think vendor lock-in will be a problem. It’s no worse currently than chrome or iCloud Keychain being your password manager, which has been part of the landscape for a very long time. Like password managers, there will be other options. The benefit is that unlike passwords, there is a standard API for “autofill credentials” rather than using an extension to update the DOM.
- sebk 4y ago
  1Password's and Dashlane's implementation keeps the key material and does crypto in software, meaning it's less isolated from the operating system than hardware-backed implementations. That might be an acceptable tradeoff for some, but definitely not for all, and I doubt that was the original intention of FIDO2 when it was designed -- the spec only mentions virtual authenticators in the context of testing. I hope the FIDO alliance members come up with a solution that has both hardware backing and third-party vendors. I'd love to have 1Password syncing passkeys to Yubikeys or secure element that can be used independently of the 1Password app and subscription itself.
  - jmcnulty 4y ago
    My biggest anxiety with hardware-backed security is what happens if someone breaks into my house and steals my laptop and phone. Today I would buy a new laptop, login to Bitwarden using my strong memorised master password and carry on. If everything about me is linked to hardware-backed passkeys then my digital life walks out the door with the thief.
    - sebk 4y ago
      This is a totally valid concern. A mitigation is to have some other device or mechanism to generate a device that's part of sync fabric in escrow somewhere else. Of course, this introduces two new problems: Where do you keep it in escrow, and how do you authenticate to that escrow service given that your authenticators are gone. Safe deposit boxes are one alternative: They're authenticated by your presence and government-issued ID. Apple uses a 24-character key and keeps the encrypted record in its HSMs. Crypto wallets tend to use a 24-word recovery phrase to derive a key. These last two options you could also escrow with a third party or maybe even memorize. For what it's worth, it's not an inherent problem with hardware backed security, at least not in the context that I was talking about. If you were using pure software implementations of WebAuthn, you could also authenticate to that sync fabric only using WebAuthn and you'd have that exact same problem you're describing.
account-5 4y ago
Nope. I still can't see me using passkeys. Unless someone can explain how I use them without a Google/Apple/Microsoft account, or without being reliant on some third party and a hardware device then it's useless for me. I would only ever use this if like my password manager the authenticator was software based (hardware independent), platform and vendor independent, open source, and offline.
- pat2man 4y ago
  Any password manager can support them. 1Password has announced a beta already.
  - account-5 4y ago
    If/when keepassxc supports them I'll likely start using them. As it stands I'm not putting all my eggs(keys) in a third-party basket, one that might decide to shut my account with them for no reason or recourse (Google). Or to a device that can be lost, stolen, or broken. Having multiple devices and third party services to "fix" this is not the answer.
vouaobrasil 4y ago
Personally, I both love and hate the idea of passkeys. In terms of security, passkeys definitely have some real advantages, not to mention the convenience of never having to type a password or remember one again. Still, they have a serious flaw: practically, you need a hardware device with you, and practically it will be a phone. I hate having to rely on having my phone handy to log into anything. What if I lose it? With a password I can log in from anywhere. I feel like passkeys are a double-edged sword, like all of technology. On the one hand, they introduce new convenience and security, but on the other hand they make us even more tied to systems and devices. It's a lot of infrastructure that someone else has to maintain, and it's a single-point of failure in case you want to keep all your passkeys in iCloud, so you can migrate them to other iDevices. We are crafting increasing complex systems with tighter and tighter integration into our lives and I think we need to be cautious of passkeys before accepting them so readily. In short, there is no such thing as free convenience. There is always a cost, but we usually ignore that.
- pat2man 4y ago
  Ultimately, passkeys are just certificate based authentication. Certificates are generally more secure because they contain more entropy (and because they contain metadata). But nothing is stopping you from using something like a mnemonic phrase that you remember to generate a certificate. It would be trivial to create a browser extension that allowed you to use a "password" on a passkey enabled site. If thats the experience you want I am sure someone will provide it.
  - vouaobrasil 4y ago
    Your proposed solution isn't a very good one. Actual password systems use server-side things like salts and other mechanisms like hashing. Having "trivial" client-side extension to generate a certificate would make brute-force a lot easier. So, if passkeys are the only way of logging in, then no, a browser-based certificate generator would not work to emulate passwords.
- PassageNick 4y ago
  >> I hate having to rely on having my phone handy to log into anything.<< This isn't the case. Nothing about passkeys says you need your phone to login on a website with your laptop, for instance.
tomjen3 4y ago
To any startups here: don't get fancy. Your primary offering is not the login feature, so just go with a standard key/pass/login with a b c Stackoverflow was cool enough that they could get away with trying something new, even if it made it much more difficult to get new users, but even they transitioned to the standard. When you are trying to grow your company, don't make me think about the login, don't waste effort teaching me something pointless, let me focus using your product.
danShumway 4y ago
My same response as always: https://news.ycombinator.com/item?id=34853404 https://news.ycombinator.com/item?id=34853404 I don't think the Passkey ecosystem is mature enough to be used as is, and I don't think it's good for us to naively accept that passkeys will get more portable in the future; there are multiple parts of the ecosystem that do not look like they're set up to move in that direction. Prove that they'll be portable, make them portable first. Make an implementation that works on my Linux devices and that won't immediately get blocked for failing attestation requests. Make a client that is Open Source where I can modify the code myself and use it in the real world without losing access to my keys. Then I'll pay attention. The overall discussion and debate about passkeys also gives me a lot of doubt about them. There are comments in this comment section saying that FIDO keys and Passkeys are portable because you can use them with other devices. No, that's not what portable means. The fact that you can use your phone or hardware token to log into a website doesn't mean the credentials you have on that hardware token or phone are portable. You can't recompile the firmware on those devices and keep access to your passkeys. You can't move those passkeys between devices easily (you can one-by-one create new passkeys on other devices if they're supported, but come on, that is not real portability). I don't have a lot of confidence about passkeys because I don't really see that passkey proponents understand the problems people have with them, and they're often extremely dismissive of those concerns. Yes, I understand that passkeys are on some level designed to be hard to port. Yubikeys don't have a backup/export option on purpose. But what I'm saying is that those design goals are incompatible with building a general replacement for passwords for ordinary people. There's some really cool stuff with FIDO that I would love to love, but I just don't have confidence that the people involved in the standard understand what the criticisms are, and I don't see how it becomes a generally accessible standard when those concerns aren't addressed -- and in fact, when we start talking about stuff like hardware attestation, when we start getting into parts of the spec where migration between platforms is explicitly supposed to be platform-dependent -- those are actively harmful parts of the spec that should be rejected. They're not just "we haven't gotten to building it yet", they're bad decisions. But I'm happy to change my mind. Give me a version of this that works on my Linux computers and give me a version of this that works on my Android phone running a custom De-Googled ROM. Give me a version where I can log into a computer that doesn't have bluetooth running, that doesn't require me to buy multiple 3rd-party hardware devices to handle log-in and backup, and that doesn't require me to manually update multiple keys for every single login. Show me that working on real sites and I'll happily change my mind about it. There's parts of FIDO that I do really like. It's just that those good parts are not worth naively playing into a process that's going to end with making it practically impossible for people to exercise control over their own data and their own devices.

62 points by carride 4y ago

This is exciting, I love that we're moving toward passkeys. When I tell non-devs that passwords will be going away in the years to come they almost can't understand what I'm saying. Like we've all lived this life of passwords for as long as we can remember so the idea of not getting having to click "Forgot my password" once a day is foreign to us. It's sort of like we've been gaslighted into thinking this is how it has to be for years and it's crumbling away now. Meanwhile I'm sure a decade from now we'll all look back and say "Remember when we had to type _secret characters_ into a little box to log in to an app/site?"

candiddevmike 4y ago
The problem with passkeys IMO is they typically aren't portable between devices, and if they are, they will have some of the same problems as passwords. A long passphrase will probably have the same threat profile as a portable passkey, but with an easier implementation.
- toomuchtodo 4y ago
  For the vast majority of your layman use cases, passkeys are perfect because the switch rate between ecosystems is low. My mid 90s grandmother is not able to use a password manager, she's just not capable. Same for my mid 60s in laws. Passkeys fix this for them. If your use case requires heterogenous ecosystem support, it might make sense to wait for your preferred password manager to have passkey support (to have an independent sync fabric). Worst case scenario, you have multiple passkeys per service identity/web property, one in each sync ecosystem (if the relying party supports it). Still better than passwords! If your SSO provider does't support passwordless/passkeys, loudly complain to them :) Azure Active Directory supports it, I have worked with a team to implement it. (great post btw to the Teleport folks, both content and visual appeal)
  - candiddevmike 4y ago
    Hopefully someday some smart person invents a standard, secure way of handling enrollment/forgot my pass(key|word), as that will always be the weakest link. As much as it freaks some people out, a cryptographic national ID would be really helpful for this, IMO.
    - toomuchtodo 4y ago
      https://stripe.com/identity https://stripe.com/identity Agreed about a cryptographic national ID. One day! Login.gov is already prototyping using USPS for in person identity verification, we'll get there. https://news.ycombinator.com/item?id=34735448 https://news.ycombinator.com/item?id=34735448
- ryukafalz 4y ago
  Passkeys (in the sense the article is referring to, which is to say FIDO2 passkeys) are explicitly portable between devices. And the difference is they're always unique per-site in a way that passwords are not necessarily. It's possible to approach the security of passkeys if you always use unique passwords per-site (with e.g. a password manager) but you're still then vulnerable to phishing unlike with passkeys.
  - deleted 4y ago
    [deleted]
  - Groxx 4y ago
    Most password managers check the urls before filling.
    - vlovich123 4y ago
      That doesn't prevent phishing attacks where the user goes "uggh. my password manager isn't working again. I'm going to copy-paste the password in by hand".
      - danShumway 4y ago
        Similarly, passkeys don't necessarily block the phishing attack where the user goes, "ugh, this dongle/phone isn't working, I guess I need to put in one of these one-time recovery codes." Account recovery is still going to be a weak point here, and it's a kind of double-edged sword. If you're really strict about passkeys getting shared between devices or manually accessed, then users are going to lose access to accounts a lot, and recovery methods are going to get easier to accommodate those situations, which will in turn re-open phishing vulnerabilities. On the other hand, if services don't implement those recovery options, then the first time a user gets burned with losing access to an account for a week, they're going to stop using passkeys, and broader adoption will be halted.
  - danShumway 4y ago
    > are explicitly portable between devices Yes and no. Passkeys are portable in the sense that Apple/Google have already compromised on the "keys should never leave your device" standard and have set up backup/restore options for if you lose your phone within their ecosystem. This is portability, but extremely limited portability. It's not portability in the sense of allowing you to migrate between ecosystems. There is also some promise that passkeys will be portable between Google/Apple ecosystems in the future. The fact that the FIDO alliance refuses to build a client-independent way of moving between ecosystems and instead seems to be suggesting that migration should be handled with environment-dependent implementations severely limits how useful that portability will be. Passkeys are also "portable" in the sense that you can register multiple keys with a single site. But this is not actual portability, it's just backup/replication. When you get a new device outside of the ecosystem, you can't port your passkeys anywhere. What you can do is register that device with every single site you have an account with. This should obviously be seen as a barrier to the goal of replacing passwords entirely, but for some reason it's not seen that way. To understand the problem, we have to stop thinking of the current world where there are like 4 or 5 sites that have passkeys attached to them; you have to instead think of a world where passkeys won and a user has hundreds of sites with passkeys attached to them, many of which they might not have visited in nearly a decade. And when they buy a new device, they have to migrate all of them. That's not portability, that is not something that a non-techie user wants to go through. > you're still then vulnerable to phishing unlike with passkeys. Extremely important to mention in these discussions, passkeys are phishing-resistant, not phishing-proof. We gave up on phishing-proof when Google and Apple started doing backup and restore within their own ecosystems. Your iCloud credentials can be phished, at which point your passkeys can also be phished by setting up a new iPhone. Arguably, the Yubikey/dedicated-token approach was phishing-proof (for at least a somewhat narrow definition of phishing), but that's not the approach that mainstream platforms are going for. If you're using an iPhone, your passkeys already get backed up. That ship has sailed, the only fight remaining is whether or not you should be able to import them to something that's not an Apple device.

arianvanp 4y ago

I wish SSO providers were able to hook into this Passkey mechanism. Instead of storing Passkeys in iCloud for sync instead we could store them at the SSO provider

jaywalk 4y ago
What? Why? How would this improve anything?
convolvatron 4y ago
you get a system where you can finally own your own identity and the first thought you have is to how to reaquire that dependency on a for-profit entity
- arianvanp 4y ago
  The opposite. Now there is just one hardcoded SSO provider: Apple iCloud. Which means you're stuck to one provider. I'd like this to be opened up. Open spec for being able to sync passkeys
  - acdha 4y ago
    It’s Apple, Google, or Microsoft now and soon to be 1Password and others. None of those are hard-coded on the sites using it - the concern is that you can’t port keys between, say, iOS Safari and Windows Edge but you can already register keys from both because it’s not SSO but rather a different PKI scheme.
sebk 4y ago
I'm with you here and have been parroting this in just about every Webauthn thread on HN, except maybe with the exception that I think it's password manager vendors who are more interested -- several of them have joined the FIDO alliance in the past year. I think having an open sync fabric that is vendor agnostic will be important going forwards. Users have a multitude of devices, usually not from the same vendor, and hybrid transport is not enough to mitigate the fact that sync fabrics are not interoperable. The risk is that password manager vendors will end up implementing virtual authenticators backed by software instead of a secure element like a Yubikey, Secure Enclave or TPM. I'd be interested in the the FIDO Alliance helping bring OS APIs to leverage secure elements to import and export key material that belongs to a particular third-party fabric. It's clearly a sensitive issue because establishing trust between devices, and thus a sync fabric, is a strong phishing target. I also speculate that password manager vendors (e.g. 1Password) and authenticator vendors (e.g. YubiCo) could mutually benefit from agreeing on some APIs to establish trust between authenticators and allow import/export, bypassing the OS vendors.

candiddevmike 4y ago

> I predict that 2023 will be the year of Passkeys. I remain unconvinced that Regular Users will find passkeys as necessary/useful as the rest of the industry does, especially older users. Will be interesting to see how pervasive passkeys become.

vdelitz 4y ago
Pretty good point you address here. I've been working on passkeys for a while and from our experience most users find it pretty useful, as long as it's not named passkey. Most of them just think they've used Face ID to login to a website - but yes overall adoption will be interesting to see.
deleted 4y ago
[deleted]

sneak 4y ago

You can't use Passkeys on iOS without iCloud, and you can't get an Apple ID without a phone number, which frequently maps to real-world ID. This means that soon your logins will be tied to your ID.

Freak_NL 4y ago
If it's just WebAuthn under the hood, wouldn't discrete WebAuthn devices work as well? That is, separate security keys (USB or NFC), or WebAuthn directly in the browser of a smartphone using on-device cryptography. Or did Apple manage to helpfully extend this standard into something requiring iWhatever accounts?
- ratorx 4y ago
  I use a YubiKey as well as iOS everywhere I use WebAuthn (currently only for 2FA). The only sites I don’t are the ones which don’t support more than 1 key. I haven’t come across any websites that restrict it to just iOS. I’m not even sure it would be easy (without fingerprinting), because the browser usually handles verification (and gives options for security key and iOS).
echeese 4y ago
Passkeys are just built on top of WebAuthn, which can also use generic platform authenticators such as touchid or windows hello, or fido authenticators like a yubikey.
ezfe 4y ago
Your assumptions are all true, but your conclusion is not any more true because of the iCloud requirement.

root5 4y ago

Companies that write „WebAuthN“ deserve no respect.

vdelitz 4y ago

I think passkeys adoption will accelerate once bigger consumer-oriented players (e.g. AirBnb) introduce them to a wider audience. PayPal, eBay and Kayak made the right, slow steps, but once more of these larger players offer passkeys as login, we'll probably see them a lot more around smaller companies, too.

benarent 4y ago

OP here, thanks for posting! Happy to Answer any questions. I have to give our a shoutout to Alan at Teleport for all his work on Passwordless and his work to make Passwordless / TouchID work with MacOS CLI https://github.com/gravitational/teleport/blob/master/rfd/0054-passwordless-macos.md https://github.com/gravitational/teleport/blob/master/rfd/00...

tjoff 4y ago

Is there any writeup about passkeys privacy? Tie everything to apple/whoever is pretty darn dystopian. And the "second factor" as described in this article doesn't exactly sound enticing.

arianvanp 4y ago
There is a large section on privacy in the spec. https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations https://www.w3.org/TR/webauthn-2/#sctn-privacy-consideration... However Passkeys puts apple in a position of the Authenticator which is the riskiest part in terms of privacy.
- tjoff 4y ago
  Thank you, seems quite approachable. A different authenticator is paramount but the question is how secure and private a self-hosted solution can be, with reasonable effort.
sebk 4y ago
Apple has pretty good security whitepapers about how it does end-to-end encryption for Keychain items like this. If you're more broadly concerned about Apple not honoring those, having (un)intentional vulnerabilities, or them having the ability to shut you off from your account, then you can always fall back to non-synced FIDO2 devices, like a Yubikey. The underlying technology in both is the same: WebAuthn. I'd imagine local-only is also how MacOS and iOS behave if you're not logged in to iCloud. If you're more interested in WebAuthn privacy more generally, there's quite a bit of it in the WebAuthn specification itself, since it was an important goal of the design.
- tjoff 4y ago
  > then you can always fall back to non-synced FIDO2 devices No, you can not. Because they are completely broken for a lot of use-cases, especially when you can only add one or two of them makes them worse than even passwords in many situations.

zacharyvoase 4y ago

I see a few obstacles with Passkeys as-implemented: * They effectively entrust the keys to your entire digital life to (right now) either Google or Apple. Account compromise, or a ToS-related suspension, becomes catastrophic. * Domain changes happen (acquisitions, rebrands, etc.), and there is no way to share or migrate passkeys between domains. Right now the best you can do is a highly manual process involving the user authenticating on the old domain, registering a new credential on the new domain, and somehow linking them. This process itself could be highly vulnerable to interception, since every site would likely have to build a bespoke way of doing it. * There's no way to migrate your passkeys between ecosystems. So if you're an iPhone user, and all your logins are iCloud Passkeys, it becomes really hard to switch to Android. * Password-sharing is regrettably used a lot right now, but it's the simplest thing that works. For example, I and my husband have a shared 1Password vault for things like utility and streaming account logins. Right now none of the Passkey syncing providers support anything like that (and I feel like they won't, because it'd be a huge vector for scams). I think the password is going to stick around until these issues are addressed.

goalieca 4y ago
1Password does have passkeys in the works. https://www.future.1password.com/passkeys/ https://www.future.1password.com/passkeys/
- danShumway 4y ago
  Does 1Password have a solution planned for migrating to other password managers? Can I migrate my "logins" from Android to 1Password in a single action (as opposed to going account-by-account and adding a new key)? Being tied to 1Password is better than being tied to iOS, but it's a far cry from real portability.
  - goalieca 4y ago
    https://support.1password.com/export/ https://support.1password.com/export/

noahtallen 4y ago

A lot of comments in this thread are discussing vendor lock-in with Apple or Google. 1Password is working on passkey support already (https://www.future.1password.com/passkeys/ https://www.future.1password.com/passkeys/) and I imagine others will follow suit. Vendor lock-in isn’t part of the spec, it just happens that in these early days, the OS-level authenticators are the main ones implemented (as are other hardware authenticators). In the mid to long term (e.g. by the time websites start supporting this), I don’t think vendor lock-in will be a problem. It’s no worse currently than chrome or iCloud Keychain being your password manager, which has been part of the landscape for a very long time. Like password managers, there will be other options. The benefit is that unlike passwords, there is a standard API for “autofill credentials” rather than using an extension to update the DOM.

sebk 4y ago
1Password's and Dashlane's implementation keeps the key material and does crypto in software, meaning it's less isolated from the operating system than hardware-backed implementations. That might be an acceptable tradeoff for some, but definitely not for all, and I doubt that was the original intention of FIDO2 when it was designed -- the spec only mentions virtual authenticators in the context of testing. I hope the FIDO alliance members come up with a solution that has both hardware backing and third-party vendors. I'd love to have 1Password syncing passkeys to Yubikeys or secure element that can be used independently of the 1Password app and subscription itself.
- jmcnulty 4y ago
  My biggest anxiety with hardware-backed security is what happens if someone breaks into my house and steals my laptop and phone. Today I would buy a new laptop, login to Bitwarden using my strong memorised master password and carry on. If everything about me is linked to hardware-backed passkeys then my digital life walks out the door with the thief.
  - sebk 4y ago
    This is a totally valid concern. A mitigation is to have some other device or mechanism to generate a device that's part of sync fabric in escrow somewhere else. Of course, this introduces two new problems: Where do you keep it in escrow, and how do you authenticate to that escrow service given that your authenticators are gone. Safe deposit boxes are one alternative: They're authenticated by your presence and government-issued ID. Apple uses a 24-character key and keeps the encrypted record in its HSMs. Crypto wallets tend to use a 24-word recovery phrase to derive a key. These last two options you could also escrow with a third party or maybe even memorize. For what it's worth, it's not an inherent problem with hardware backed security, at least not in the context that I was talking about. If you were using pure software implementations of WebAuthn, you could also authenticate to that sync fabric only using WebAuthn and you'd have that exact same problem you're describing.

account-5 4y ago

Nope. I still can't see me using passkeys. Unless someone can explain how I use them without a Google/Apple/Microsoft account, or without being reliant on some third party and a hardware device then it's useless for me. I would only ever use this if like my password manager the authenticator was software based (hardware independent), platform and vendor independent, open source, and offline.

pat2man 4y ago
Any password manager can support them. 1Password has announced a beta already.
- account-5 4y ago
  If/when keepassxc supports them I'll likely start using them. As it stands I'm not putting all my eggs(keys) in a third-party basket, one that might decide to shut my account with them for no reason or recourse (Google). Or to a device that can be lost, stolen, or broken. Having multiple devices and third party services to "fix" this is not the answer.

vouaobrasil 4y ago

Personally, I both love and hate the idea of passkeys. In terms of security, passkeys definitely have some real advantages, not to mention the convenience of never having to type a password or remember one again. Still, they have a serious flaw: practically, you need a hardware device with you, and practically it will be a phone. I hate having to rely on having my phone handy to log into anything. What if I lose it? With a password I can log in from anywhere. I feel like passkeys are a double-edged sword, like all of technology. On the one hand, they introduce new convenience and security, but on the other hand they make us even more tied to systems and devices. It's a lot of infrastructure that someone else has to maintain, and it's a single-point of failure in case you want to keep all your passkeys in iCloud, so you can migrate them to other iDevices. We are crafting increasing complex systems with tighter and tighter integration into our lives and I think we need to be cautious of passkeys before accepting them so readily. In short, there is no such thing as free convenience. There is always a cost, but we usually ignore that.

pat2man 4y ago
Ultimately, passkeys are just certificate based authentication. Certificates are generally more secure because they contain more entropy (and because they contain metadata). But nothing is stopping you from using something like a mnemonic phrase that you remember to generate a certificate. It would be trivial to create a browser extension that allowed you to use a "password" on a passkey enabled site. If thats the experience you want I am sure someone will provide it.
- vouaobrasil 4y ago
  Your proposed solution isn't a very good one. Actual password systems use server-side things like salts and other mechanisms like hashing. Having "trivial" client-side extension to generate a certificate would make brute-force a lot easier. So, if passkeys are the only way of logging in, then no, a browser-based certificate generator would not work to emulate passwords.
PassageNick 4y ago
>> I hate having to rely on having my phone handy to log into anything.<< This isn't the case. Nothing about passkeys says you need your phone to login on a website with your laptop, for instance.

tomjen3 4y ago

To any startups here: don't get fancy. Your primary offering is not the login feature, so just go with a standard key/pass/login with a b c Stackoverflow was cool enough that they could get away with trying something new, even if it made it much more difficult to get new users, but even they transitioned to the standard. When you are trying to grow your company, don't make me think about the login, don't waste effort teaching me something pointless, let me focus using your product.

danShumway 4y ago

My same response as always: https://news.ycombinator.com/item?id=34853404 https://news.ycombinator.com/item?id=34853404 I don't think the Passkey ecosystem is mature enough to be used as is, and I don't think it's good for us to naively accept that passkeys will get more portable in the future; there are multiple parts of the ecosystem that do not look like they're set up to move in that direction. Prove that they'll be portable, make them portable first. Make an implementation that works on my Linux devices and that won't immediately get blocked for failing attestation requests. Make a client that is Open Source where I can modify the code myself and use it in the real world without losing access to my keys. Then I'll pay attention. The overall discussion and debate about passkeys also gives me a lot of doubt about them. There are comments in this comment section saying that FIDO keys and Passkeys are portable because you can use them with other devices. No, that's not what portable means. The fact that you can use your phone or hardware token to log into a website doesn't mean the credentials you have on that hardware token or phone are portable. You can't recompile the firmware on those devices and keep access to your passkeys. You can't move those passkeys between devices easily (you can one-by-one create new passkeys on other devices if they're supported, but come on, that is not real portability). I don't have a lot of confidence about passkeys because I don't really see that passkey proponents understand the problems people have with them, and they're often extremely dismissive of those concerns. Yes, I understand that passkeys are on some level designed to be hard to port. Yubikeys don't have a backup/export option on purpose. But what I'm saying is that those design goals are incompatible with building a general replacement for passwords for ordinary people. There's some really cool stuff with FIDO that I would love to love, but I just don't have confidence that the people involved in the standard understand what the criticisms are, and I don't see how it becomes a generally accessible standard when those concerns aren't addressed -- and in fact, when we start talking about stuff like hardware attestation, when we start getting into parts of the spec where migration between platforms is explicitly supposed to be platform-dependent -- those are actively harmful parts of the spec that should be rejected. They're not just "we haven't gotten to building it yet", they're bad decisions. But I'm happy to change my mind. Give me a version of this that works on my Linux computers and give me a version of this that works on my Android phone running a custom De-Googled ROM. Give me a version where I can log into a computer that doesn't have bluetooth running, that doesn't require me to buy multiple 3rd-party hardware devices to handle log-in and backup, and that doesn't require me to manually update multiple keys for every single login. Show me that working on real sites and I'll happily change my mind about it. There's parts of FIDO that I do really like. It's just that those good parts are not worth naively playing into a process that's going to end with making it practically impossible for people to exercise control over their own data and their own devices.