Hacker News Reader

Comment by lxgr | Hacker News Reader

WebAuthN is great, but I can't help but feel that Passkeys are actually a step backwards.

At least on iOS, there is no way of preventing them from being synced to iCloud, which is the opposite of what I want for high-stakes credentials like bank accounts or government e-signatures.

I've tried to raise [1] a related issue (i.e. the inability for relying parties to opt out of credential syncing, if not an explicit requirement to opt in to it) to the W3C WebAuthN working group, but it seems like the working group itself is strongly pro cloud synchronization as well.

Today, Google has sent me an email about their intention to deprecate their (device-bound) iOS authenticator in favor of (iCloud-synchronized) Passkeys, and I guess I'll begrudgingly have to switch to using an external FIDO authenticator instead.

[1] https://github.com/w3c/webauthn/issues/1714

View on HN

My cynical assessment of Passkeys is:

If Google/Amazon/Apple/Meta/whoever locks your account out, you now lose access everywhere.

This isn’t a theoretical risk. You’ll see lots of people complain about this online.

Also, Passkey providers now get sweet sweet metadata about your accounts around the web.

But yeah, authn is hard to do right. Equally, asking your users to fall into $BIG_PROVIDER’s arms seems wrong.

My personal hope is that various accountable nonprofits will begin to offer passkeys.

Agreed. This whole thing seems incredibly user hostile. At the very least, there should be severe legal recourse (criminal liability and also large, material-to-earnings statutory damages) if one of these providers intentionally locks you out of a third-party account.

That third party account should be treated like your personal property, and them denying you access to it should be treated like their CEO breaking into your house and stealing your stuff.

If they don't want to take on the liability, and it kills the passkey spec, that's fine with me. The current system avoids the issue by allowing people to store credentials in a decentralized way.

Lol. If something does happen Google will immediately and repeatedly remind you with every communication that they have no liability. Once your account gets flagged or locked, Google adds the following to damn near every email:

“We have concluded the review of the information you’ve submitted. To prevent possible fraud and abuse, your services will remain suspended. It is our policy to not discuss the specific reasons for these suspensions.

Note that in the Google <PRODUCT> Terms of Service, we reserve the right to change, suspend, or discontinue any aspect of our services at any time, including availability of a service or any feature, without notice and without liability. We also reserve the right to impose limits on certain Service features or restrict access to some or all of the Services without notice and without liability.”

> If Google/Amazon/Apple/Meta/whoever locks your account out, you now lose access everywhere.

Fortunately, both iOS and Android also support "detachable passkeys" a.k.a. Yubikey and co. ("roaming authenticators" in WebAuthN/FIDO parlance).

Unfortunately, only Android is planning to offer [1] a first-party Passkey provider API, because that's what I'll probably be using 99% of the time (finding my external authenticator for every login is frustrating).

> Also, Passkey providers now get sweet sweet metadata about your accounts around the web.

To my knowledge, both Google's (for Android) and Apple's sync backends are end-to-end encrypted. I'm not sure if that includes the metadata as well as the private keys, though.

[1] https://developers.google.com/identity/passkeys/supported-en...

> Fortunately, both iOS and Android also support "detachable passkeys" a.k.a. Yubikey and co

That’s good to know.

Although my concern would be, that’s really good for people who use YubiKeys, but regular people won’t, and they can then get bitten by account lockouts.

Is there something regular users can do to use Passkeys (let’s say they use Google) and have some recourse if Google locks them out?

Also, what happens if they use Android, have no other computing device (this is fairly common in some parts of the world), and their phone gets stolen?

Passkeys don't negate regular account recovery processes. Just as if you were to lose your password, you would have to talk to support.

Right now, the identity of an account is tied to knowledge of the email address and the password. Something you know. If you forget the password, you need access to the email account.

With passkeys,the identity of the account is tied to either a BIGTECH account, or to physical devices.

If BIGTECH locks you out or you lose access to all your physcial Yubikeys at the same time, you will never access the account tied to the passkeys again.

I don’t know about privacy, but the lockout risk doesn’t seem worse than losing your phone or Yubikey. You should have multiple independent ways to log in for any account you care about. Passkey will be one way.

Possibly two ways, if you have both Android and iOS devices and you register both? (I assume Android and iOS remain independent.)

So if passkey is just yet another way to log in, then all the security aspects are moot, no? The attacker could still attack the other login methods. E.g., even if the passkey is a secure surface, it does not replace the insecure attack surfaces.

ideally the site requires 2FA for those, or sends a confirmation email and makes you wait a few hours, etc.

What if one loses all their devices in a natural disaster, a house fire, or burglary, or lost baggage while traveling?

A password is in your head. If you lose that, there's not much use for the said password. But otherwise, it's secure. And it's pretty secure from an infosec perspective if it's a passphrase.

1Password literally asks you to print out your private key. Yet their hygiene is lauded.

I think it's more likely that you'll lose your password by forgetting it? People forget many things without losing their heads.

There's no perfect solution. Having a printout of backup codes in a fireproof safe is pretty good, but it's of no use while traveling. A Yubikey is good, but it might not work (wrong USB port) and it's a device that could break.

Having multiple ways to log in reduces your risk of lockout, but also makes it more likely that someone unauthorized could get access.

Passwords, particularly passphrases, are easy to remember and you can reuse a similar structure for probably decades:

- There-are-three-ducklings3-in-the-lake

- There-are-five-swans5-in-the-lake

- There-are-six-hedgehogs6-in-the-bush

And so on. You only need to remember the latest number and animal, but the entropy of the whole string is much higher unless someone also knows your personal password structure (which is kind of like a second factor).

With a password manager, you only need to remember that one passphrase. If you have to enter it daily, I think it’s very difficult to forget.

You can access your passwords mostly independently from any device and it’s probably about as secure if good generated password hygiene on websites and services is used.

Well okay, but now you depend on a password manager. Hope you picked the right one and backed it up?

I’m not sure this is better than using a device to log in.

You are right, choosing the right one (reading its whitepaper and what encryption it uses where), and backups are very important for those. I suppose logging into all of the services we use these days is complicated and not very secure no matter the method.

Giving your passwords to a company that cares about money more than you is risky. But losing devices with passkeys is a big problem too. Even if passkeys are saved to your Google, Apple, or Microsoft account, if that account itself is behind a passkey, how do you access it if your phone holding the key breaks? If a disaster or fire happens, all your devices could be gone.

Passwords are good because you remember them in your head, so long as the head works, so do the passwords. This might be an obvious statement, but it's clear passkey providers kind of glance over it.

Personally I don't want to be dependent on a third party like Google or Apple for my identity. That's never going to be acceptable.

If they just accept normal Yubikeys (and multiple at a time for redundancy) that'd work for me but this passkey stuff where the vendor gets to decide things and I don't fully own my credentials is just wrong IMO.

I wonder if there's a fully self hosted passkeys option?

I'm also opposed to attestation. With TOTP I can use any app I want and back up my keys however I like. But Fido gives a lot of control to websites, they can choose what kind of authenticators or apps to accept. This can make it too easy to get locked into vendor solutions because they are the only ones every website trusts.

> I wonder if there's a fully self hosted passkeys option?

If external authenticators work for you, physical keys (like Yubikey, Solokey etc.) are arguably self-hosted!

For on-device passkeys, at least Android is preparing an API for this [1]. I hope that iOS will follow at some point, as well as Firefox (which unfortunately has been quite slow to adopt all aspects of WebAuthN).

> I'm also opposed to attestation. With TOTP I can use any app I want and back up my keys however I like.

In principle I agree, but some service providers like banks are legally liable for fraud losses (at least in some jurisdictions). I'd say they do have a legitimate interest of being able to verify which authenticators they trust.

Of course, it's being already exploited in a pretty much expected way: My government offers a (free to end-users, tax paid) e-signature solution. They support, among other authentication methods, FIDO – but only a very specific authenticator, of which the e-signature service provider is the exclusive reseller in the country...

[1] https://developers.google.com/identity/passkeys/supported-en...

> If external authenticators work for you, physical keys (like Yubikey, Solokey etc.) are arguably self-hosted!

Yes. And this is what I do with all my personal stuff (though I use the GPG mode on the yubikey, not Fido2). But, because a passkey can be backed up, websites targeting mainly passkeys will be likely to offer only a single authenticator to be enrolled. Of course with hardware authenticators that is not going to work. Lose that one and you're screwed. This is why multi-authenticator support is so important.

> For on-device passkeys, at least Android is preparing an API for this

Thanks, I'll have a look at that. I'd want it on the PC too though (BSD). But anyway, hopefully it will come. I never really looked at it, as for now the website acceptance part is still so low that it didn't matter anyway. For the ones I use regularly, only Office 365 supports it. I'm not interested in the old FIDO MFA mode, only full passwordless will do.

> Firefox (which unfortunately has been quite slow to adopt all aspects of WebAuthN).

Yes, this is really a PITA now. They really don't seem to give a ***, they only offer CTAP2 (full FIDO2 + PIN) mode on Windows. Still not working on Mac, Linux, BSD... It's been in this sorry state for years now.

> In principle I agree, but some service providers like banks are legally liable for fraud losses (at least in some jurisdictions). I'd say they do have a legitimate interest of being able to verify which authenticators they trust.

Banks here already use their own authenticators which they provide anyway, but yeah that's a point. Many other sites shouldn't be able to make such decisions though, IMO.

PS: I'm not sure why you are being downvoted, I really appreciated your insightful comment. Especially about the Android option I wasn't aware of.

I have yet to see a bank use login restrictions to make itself more secure. I've been trying to get my bank to offer actual 2FA for years, and their response is that they moved from offering SMS/Email codes to only offering SMS codes.

A bank should not have control over what authenticator app I'm using. Their authenticator apps that they do have are terrible and my security would be improved if I could just use a simple 2FA app. In practice, this is just a way to make it so that DeGoogled devices, Linux devices, etc... won't be able to interact with normal services because they're "less secure". And the companies saying that will be the same ones asking me for authentication over the phone via my mother's maiden name. They don't need this, they're not technically qualified enough to have this level of control over what devices I use.

I honestly don't think attestation should have been part of the spec at all. There is an extremely narrow range of instances where knowing what client/hardware/OS someone is using is justifiable, and in almost all of those instances you should probably be directly controlling the hardware itself (providing a phone for your employees, installing a kernel module, etc...)

And there's nothing official to discourage companies from using attestation other than some vague "but don't do this if you don't need to" language. It's a bad idea that will be used to restrict people's control over their own devices that they own.

At least today these services all offer websites so I can still log on and use them without installing an app. But with attestation we're moving towards a future where you won't be able to log into your bank unless you own a "supported" Android device or an iPhone, and rooting those devices will mean that you don't have access to online banking services all of the sudden.

> Their authenticator apps that they do have are terrible and my security would be improved if I could just use a simple 2FA app.

Good point. I was at my bank last year to discuss a mortgage. It's already a bank I don't feel so good about because their idea of "authentication" is to type a 2FA code that you get from the bank app into the bank app (so you have to type the code in the same app that just gave the code to you!). This really feels like busywork rather than real security.

But anyway was she sat down I saw her log in from a Windows 10 endpoint into a VDI system that was clearly Windows XP (or 2k3 server) judging by the login screen and window decorations. Sigh... I have serious reservations now about leaving my money there.

Of course VDIs are sometimes considered more secure but at my work we have really come back from that idea. Back when wannacry hit on a friday afternoon most laptops had already left the office for people's homes. But the VDI servers were online 24/7 and constantly kept getting re-infected and spreading malware throughout the network.

> And there's nothing official to discourage companies from using attestation other than some vague "but don't do this if you don't need to" language. It's a bad idea that will be used to restrict people's control over their own devices that they own.

Totally agreed, this is also the problem I have with attestation.

https://connect.mozilla.org/t5/ideas/support-webauthn-passke...

This page has a recent comment from a Mozilla employee on Firefox support:

04-24-2023 04:39 AM

    We are actively working on supporting this feature.

    Here is our current roadmap (might change):

    - WebAuthn Level 1 + CTAP2 is riding the trains for Fx 114
    - WebAuthn Level 2 + 3 are planned to ride the Fx 116 train
    - Passkeys (though details are still about to figured out) earliest completion is Fx 120

So, it's coming but it's going to take at least six months or so. Current beta version is 113.

Hmm that's nice actually!! Because I only need the first one and perhaps the second, I will not do full passkeys until it becomes possible to self-host it anyway.

I really hope it will come to all platforms though. Not just Windows or Mac but also Linux and BSD.

How is this different than a password manager with encrypted cloud backup? Your recourse if someone breaks passkeys is legal, not technical. Security must be a balance with functionality, and this is a huge improvement over passwords. (Tangentially, it would be great if we got cryptographic digital identity cards like Estonia has for signatures but that’s more of a long term goal)

Cloud sync (encrypted!) is important because your average user needs that convenience and durability of authenticator.

The difference is that I can choose my password manager on iOS (and thereby pick my desired security level for password synchronization or opt out of it completely), but not my Passkey synchronization backend: iOS forces these to be stored in iCloud Keychain. (Passkeys are unavailable without iCloud Keychain [1]!)

Ideally, there would be a per-passkey UI option to opt out of synchronization at creation time.

> Security must be a balance with functionality, and this is a huge improvement over passwords.

Sure, but I'm somewhat disappointed that the WebAuthN WG basically forced this huge change of semantics (it's essentially a security vs. availability tradeoff) into relying parties without explicitly collecting their opt-in beforehand, or even providing an ergonomic way of opting out.

[1] https://support.apple.com/guide/iphone/sign-in-with-passkeys...

I agree there should be a way to opt out of system level ecosystem passkey sync with a big ol’ “you’re fucked if you don’t back these up somewhere” click through warning.

That's exactly what I want, ideally at a per-passkey level.

It should also be able for relying parties to express that desire (whether opt-in or opt-out by default). As it is, I think it'll just make banks and governments less likely to adopt passkeys.

That's sad, because all in all I think WebAuthN has the potential to have a very positive impact on security globally.

Putting on my "personal opinion" hat;

If a platform gave users this option per credential, and there was any visibility to that choice on the relying party side, the replying party would likely just reject the credentials they don't like outright, and tell people 'go figure out how to twiddle this setting if you want to use your phone here'.

Part of the web focus of these APIs mean that they will default to being open and user centric - features that might enable relying parties to block user choice will receive tremendous scrutiny, and proceed very slowly. Sites are expected for now to accept what the user chooses, and do additional steps as necessary to meet their needs. This means passkeys as a whole are not going to be always accepted as a MFA replacement.

Even features like hardware attestation are gated by a prompt by some browsers, because some consumer-facing websites went live with code saying "we will only support this one brand of security key". This led to some of the warnings in the document here: https://www.chromium.org/security-keys/

I can sympathize with the desire of a "footgun mode", which might even lie to the website about whether the credentials are backed up. However, I wouldn't trust something that critical to what is almost going to be a poorly maintained path through the system. Instead, I use (two) Yubikeys for such credentials.

> The difference is that I can choose my password manager on iOS

This is what you expect when you buy into the closed Apple ecosystem.

Yes, being able to choose my own password manager is indeed an important feature to me. I'm pretty sure that feature is not unique to closed platforms, though.

You're basically complaining that your choice of using closed down platforms arrived with delay

Yeah this is fair. It blows my mind that platform players don't understand that the security posture needs to be configurable at a per-credential level. The hope would be that 3rd parties step in and provide implementations that afford these options to users, but that would require platform players to stop dragging their feet on allowing PW managers to hook in to WebAuthN challenges as a credential store/backend.

Okay so use a YubiKey?

I must be missing something but I do not get all this hand-wringing. Don’t like the passkey options from Google or Apple? Fine! Use the hardware authenticator you absolutely already have if you’re the kind of person who has these sorts of objections.

Sure, I already do that, but why shouldn't there be a choice in on-device passkey implementations just like there is for password and HOTP/TOTP authenticators?

Your argument sounds a bit like "Don't like Safari? Just use a different OS then" in the context of allowing browser choice on iOS. There is no technical reason a Passkey provider and OS/platform should be necessarily bundled.

It would encourage competition in both functionality and security, it reduces reliance on a single account your entire digital life, it allows niche products to address special requirements in all kinds of scenarios...

> Your argument sounds a bit like "Don't like Safari? Just use a different OS then" in the context of allowing browser choice on iOS.

Except… you can just use a YubiKey. It’s closer to saying “install Firefox” than “install a different OS”.

> There is no technical reason a Passkey provider and OS/platform should be necessarily bundled.

Sure, fine. This is like V1 of every provider’s implementation. None of this was even available three months ago, I have no doubt these things are coming.

> Except… you can just use a YubiKey. It’s closer to saying “install Firefox” than “install a different OS”.

No, you're literally recommending I use a separate physical device because there is no API to achieve the same functionality that the OS provides via their bundled implementation.

> Sure, fine. This is like V1 of every provider’s implementation. None of this was even available three months ago, I have no doubt these things are coming.

On iOS, Passkeys have been available for more than half a year now. I really hope that Apple will eventually follow suit.

> No, you're literally recommending I use a separate physical device because there is no API to achieve the same functionality that the OS provides via their bundled implementation.

A $50 device that I have no doubt you already own, and that does not require you to change or modify any of your existing computing setup or habits.

If your point truly has merit, you shouldn’t need the hyperbole.

> Cloud sync (encrypted!) is important because your average user needs that convenience and durability of authenticator

Local-only iOS+macOS Codebook sync (open-source encrypted! by SQLCipher) provides password and TOTP convenience, durability, transparency, decentralization and fewer supply chain dependencies with one-time purchase. Founded in 2005.

https://www.zetetic.net/codebook

https://github.com/sqlcipher/sqlcipher

> password and TOTP convenience

Passwords and TOTPs are not MITM-safe, WebAuthN/Passkeys implicitly are. (Credentials are bound to a specific RP, i.e. it's impossible to accidentally provide one to the wrong website or a scammer on the phone.)

Codebook links passwords to specific websites/RPs. Some people don't take phone calls from random callers.

Can Apple allow existing password managers like Codebook to manage passkeys and synchronization locally?

> Codebook links passwords to specific websites/RPs. Some people don't take phone calls from random callers.

Sure, but passwords are still multiple-use, and sometimes auto-fill fails (often due to websites actively messing with it), requiring me to manually copy-paste the password and exposing me to phishing risk, or that of insecure/malicious applications on my system sniffing the clipboard.

> Can Apple allow existing password managers like Codebook to manage passkeys and synchronization locally?

Unfortunately not at the moment. There is some hope though, given that Apple has recently added a TOTP API for third-party authenticators, but I'm personally not holding my breath.

> sometimes auto-fill fails

For those, Safari share sheet -> "Find in Codebook" = dialog with URL-matched credentials appearing first.

> insecure/malicious applications on my system sniffing the clipboard

iOS now requires interactive user consent for apps to Paste from clipboard.

> iOS now requires interactive user consent for apps to Paste from clipboard.

Fortunately it does – a big security win. But unfortunately, macOS does not yet, and I'm copy-paste-ing passwords there more often.

I'm often wondering if drag and drop of text is actually more secure than the pasteboard?

> Codebook links passwords to specific websites/RPs.

WebAuthn is different:

1. The client (browser) knows which site is requesting credentials, which means a phishing site cannot ask for another legitimate site's credentials

2. Credentials are created as private keys and unique per-site.

3. The authentication protocol does not share secrets; it is based on public/private keys.

4. The authentication protocol involved indicates the requesting origin.

There are still vulnerabilities if you have compromised DNS or javascript on the site, but it is overall significantly stronger against phishing and credential reuse attacks than password managers could provide before - even those with browser integration.

> Tangentially, it would be great if we got cryptographic digital identity cards like Estonia has for signatures but that’s more of a long term goal

Wonderful. Until every second web service starts to require a signature from such digital identity ("age verification" perhaps?) and that's the end of pseudonymity.

You have the option to use a non cloud password sync method today. Best of all, that can sync a single password or private key across multiple vendors. This locking down inside bubbles really needs to go for me to want to use passkeys, I don't want to register 3 separate passkeys for each account I want to register 1 and sync them between my devices.

You’re not the target. Your average user who doesn’t even know what a password manager is or doesn’t want to use one is.

Agreed I'm not the average user but what does that have to do with the passkeys not being exportable between devices/clouds and instead being forever locked into only that vendor's cloud? The average user does not own only Google or only Apple or only Microsoft products nor do they want to enroll every account for every new device manufacturer key store instead of have options to use something else. This isn't predicated on existing use of a password manager it's just also a downgrade from that aspect of them.

For the client-side, the spec is comprehensive in allowing the authenticator to decide whether backups are allowed. In this case it's iOS not exposing that to you as a user. I get why you'd want this, but trusting Apple to store your single-device passkeys for high-stakes credentials but not trusting them for syncing them is somewhat of a very specific threat model I'd say, and definitely not in Apple's own interest to support, to your detriment.

RP-side, it's true that RPs can't opt out of credential syncing, but I think that would be weak at best, as the authenticator can do what it wants. The RP can use attestation and the DPK extension to effectively bind authentications to the same originating device.

> trusting Apple to store your single-device passkeys for high-stakes credentials but not trusting them for syncing them is somewhat of a very specific threat model I'd say

I don't think it's that specific of a threat model, to be honest.

Many people are logged into iCloud on multiple family devices – are they aware that with Passkeys, by default every device they are logged in to has single-factor access to their entire online life?

Additionally, Apple's iCloud security posture has been in the news lately with some quite horrible stories that are very relevant to Passkeys, in my view: https://www.wsj.com/articles/apple-iphone-security-theft-pas...

You can't even use Passkeys on iOS without using iCloud; if you opt out of iCloud, Passkeys are disabled.

Apparently so; I just saw that as well (and edited my post). Bizarre.

Between that and completely removing anonymous attestation (i.e. implicit device binding), it makes me wonder what Apple's motives here really are...

> Today, Google has sent me an email about their intention to deprecate their (device-bound) iOS authenticator

Is this the TOTP authenticator app that Google only started actively maintaining again in the last year or so? If that's the case, that's pretty funny timing.

Reply on news.ycombinator.com