Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Why is WebAuthn so slow to take off?

news.ycombinator.com

Post reply on HN
Print view View original

171–180 of 182 posts

Re: Ask HN: Why is WebAuthn so slow to take off?

#171

Post by fao_ »

account-5 wrote: post #92
perlgeek wrote: post #61

Earlier quoted context omitted.

You're listing only the negative aspects, but in truth it's all tradeoffs. What you get is fishing-resistant authentication, that's pretty easy to use. > And adding more devices is not the answer either. Why not? What's your ideal authentication solution? Two things I'd love to see: Something like Mozilla Persona, and maybe SSH key authentication in the browser. No idea how I'd manage and back up my key though. Don't…

I really only see the negatives here. This solution offers me nothing over my password manager other that way less control over my own stuff, more ways to be locked out of my accounts, with the slightly added benefit that I don't have to worry about a sites shitty security practices. > What's your ideal authentication solution? I've said before as soon as passkeys can be managed offline and aren't tied to devices I'l…

> with the slightly added benefit that I don't have to worry about a sites shitty security practices.

I mean, here's the thing, I already don't have to worry about a site's shitty security practices because I'm using a random password for each account. Sure, my email could be leaked, but it's available on my CV anyway so, uh, congrats?

Re: Ask HN: Why is WebAuthn so slow to take off?

#172

Post by fao_ »

Nathanba wrote: post #120
account-5 wrote: post #92

Earlier quoted context omitted.

I really only see the negatives here. This solution offers me nothing over my password manager other that way less control over my own stuff, more ways to be locked out of my accounts, with the slightly added benefit that I don't have to worry about a sites shitty security practices. > What's your ideal authentication solution? I've said before as soon as passkeys can be managed offline and aren't tied to devices I'l…

It seems that they are set up to be like this already. At least Chrome+Android treat these passkeys like any password and they can be synced and accessed via API. I already see my passkeys in Chrome btw. https://developers.google.com/identity/passkeys/supported-en... This sounds pretty good to me, this is therefore like a regular old password except it's a cryptographic key that I don't have to remember and it's secu…

> This sounds pretty good to me, this is therefore like a regular old password except it's a cryptographic key that I don't have to remember and it's secured by whatever device PIN or face unlock that the device has.

So is my password, because I use (password manager).

Re: Ask HN: Why is WebAuthn so slow to take off?

#173

Post by SgtBastard »

GoblinSlayer wrote: post #150
xoa wrote: post #78

Earlier quoted context omitted.

Fully managed passkeys will always have the max needed entropy without any need for KDFs, never be reused, are amenable to a smooth path to hardware backing, and most importantly/fundamentally aren't symmetric factors. You don't need to share the private key with the website, and that in turn means that even if you stored it in plain text on your own computer you're still immune to the most common form of leaks which…

If the password is properly managed, how does it matter if its hash leaks?

Two major problems with holding passwords server side as hashes: 1) Every authentication attempt needs to send the password as cleartext (even if over TLS) so that the hash can be recomputed server side and compared. This gives ample opportunity for the password to be intercepted either over the wire or compromise of infrastructure server-side. Using asymmetric encryption doesn't have this vulnerabity.

2) Passwords that can be stored in the meatsack attached to the keyboard aren't as random as we'd like to think them to be, where as a secure pseudo-random function will generate keypairs with unguessable entropy.

Expanding on 2) While salting and non-uniform iteration counts of hashes prevents instant compromise from rainbow tables, they only slow down adversaries generating hashes from password guesses, as the salt and iteration count will typically be leaked from the same table as the password hash.

Its worth noting that while it definitely is infeasible to attempt to crack 100K+ users passwords from a password hash leak, using password spraying and especially password stuffing approaches will inevitably lead to compromise one or more accounts relatively quickly. At the other end of the spectrum, if a known high-value account can be identified, dedicating the distributed cloud resources to cracking a specific password can be a net-profitable undertaking.

Re: Ask HN: Why is WebAuthn so slow to take off?

#174

Post by WorldMaker »

Nathanba wrote: post #170
WorldMaker wrote: post #158

Earlier quoted context omitted.

The PINs protect a hardware enclave full of cryptographic keys. The PIN never leaves the hardware device it was input into. (It's an equivalent to the button on a Yubikey or something of that nature and there is a reason that PINs are lumped into the same settings as biometric unlocks like Touch ID and Face ID.) It's an intelligent trade-off, of course, in threat models that involve access to the physical device for…

Yes I was thinking of the theft scenario, for remote usecases it is definitely safer. I think webauthn could be great for 2fa without phones. But there are important things missing. For example the google authenticator app has an established way to backup and sync now. There is no such manual backup and sync possibility for Windows Hello passkeys. It's all a bit new now. I suppose as a website owner I would have to l…

> Yes I was thinking of the theft scenario, for remote usecases it is definitely safer.

The thing to keep in mind is that the remote threats are bigger and more common, and the "local theft" scenarios fewer and impacting fewer people. Obviously, it is terrifying as an individual user when a device is stolen with enough PIN information. But on the other hand, you can't so easily automate stealing devices physically from people. It is much harder to steal things to anything like the same degree of mass stealing credentials in remote attacks and database breaches.

For most ordinary users, they are much more at risk of remote attack or remote phishing than local theft. Device PINs are probably the right balance for the average user's threat model. (If you have larger concerns about device theft than the "average user", then plan accordingly. Find the right mix of other offered unlocks and snoop prevention mechanics as feels right to you.)

> But there are important things missing.

I think at this point in your post you are confusing Webauthn/FIDO keys in general and Passkeys specifically. In general, websites should absolutely allow you to register an entire keychain of public keys beyond just any single device's keys. (It's often the sign of a bad Webauthn implementation if it only allows a single key.)

Passkey standards themselves are an extra couple of levels of Webauthn standards on top of that. They include things such as synchronization of keychains, including recovery keys, manufacturer attestations about keys ("this key comes from the secure hardware enclave of an iOS device"), and the use of Bluetooth LTE for local FIDO key delegations (using a QR code to kick off a handshake between your Windows PC and your Android Phone to sign something over Bluetooth LTE, and Bluetooth LTE with physical proximity only).

The general goal of passkeys is to have keychains with keys from every one of your devices represented plus the ability to say that "these keys are somewhat more important" such as the keys from your personal phone as the true "master keys" of your passkey.

Apple, Google, and Microsoft have all agreed to interoperate in their implementations of Passkeys. In theory, the Passkeys keychains should all eventually "merge" into a single synchronized keychain representing your entire device ecosystem, generally with your personal phone as the "lead" or "head" at the table. In practice, for now, most Passkeys operations I believe still should assume that a user has N Passkeys (and N times M keys in general).

But yes, Apple is currently in the lead with Passkeys implementation (with UX in all of iOS, macOS, and Safari) and Google isn't far behind in Chrome implementation (though I hear Android is somewhat behind still) and Microsoft currently has the most "catch up" to do in terms of Passkey UX.

Re: Ask HN: Why is WebAuthn so slow to take off?

#175

Post by bawolff »

GoblinSlayer wrote: post #152
bawolff wrote: post #112

Earlier quoted context omitted.

The average user is not typically subject to remote attacks. There are exceptions of course. However we should design the default security experience for the threats the average user faces. Most users aren't being targeted by the NSA, etc. Unless you mean the webserver they use being attacked, but that is just as vulnerable for 2fa. The only difference is the user cannot screw up and use the same credential on multip…

The average user isn't targeted personally, they are targeted en mass, the more people fall into the category, the more valuable target they become. A personal attack is needed only if the credential storage is not standardized.

Remote attacks (e.g. say having a zero day in the sms messenger app. Not talking about remote in the sense of phishing emails are sent remotely or when attackers target service providers instead of users) typically get noticed and fixed really fast if they are used en masse. In practise it is much more common for attackers to pick specific targets in order to preserve how long their vector lasts for.

Re: Ask HN: Why is WebAuthn so slow to take off?

#176

Post by bawolff »

noisenotsignal wrote: post #157
bawolff wrote: post #133

Earlier quoted context omitted.

If we are assuming that the password manager is on the same device used to login, a replay attack is bordering on rediculous. In this scenario, you are assuming that the client is not compromised (since otherwise they would just steal it before you use it) the server is not compromised (otherwise what is the point), you do not have an active mitm (otherwise they could use the token directly instead of replaying). All…

Sorry, I meant replay really broadly because I could not come up with a better term in the moment. For example, a password can be leaked in many ways (guessed, by a breach if the website has poor password storage, etc) and be “replayed”, as in the attacker just enters the password themselves. A code does not have that problem because it is temporal.

Ah ok. Its confusing because one of the requirements for time based one time password 2fa is that if you use the same 2fa token twice,it is still supposed to reject the second one even if it is in the same time window.

On the server side usually a "key" is stored, which for TOTP based 2fa would allow the attacker to create future 2fa tokens if they got ahold of the key. So what really saves you is the website choses the key not the user, meaning every website has a different one. Not the temporal nature.

Anyways, usual term for what you are referring to with reusing passwords is "credential stuffing".

Re: Ask HN: Why is WebAuthn so slow to take off?

#177

Post by SgtBastard »

WorldMaker wrote: post #160
crote wrote: post #142

Earlier quoted context omitted.

If I am not mistaken, all Passkeys implementations allow keys to be synced between multiple devices. This means it is by definition possible for them to be stolen or leaked. Webauthn keys are only secure against stealing & leaking if they are backed by a proper separate token like a Yubikey, but it seems the People That Be want us to get rid of those ASAP.

To my understanding, Passkeys implementations don't sync private keys, they sync and cross-sign public keys. Some vendors may also add "recovery" public keys to those synced keychains so that you can "Forget Password" your way out of a lost device or locked account or bootstrap new devices, and you have to trust your chosen vendor's security for how they manage that private key for any "recovery" keys. But my impress…

> To my understanding, Passkeys implementations don't sync private keys, they sync and cross-sign public keys.

I haven't seen anything in the FIDO alliance or vendor (Apple, Google, MS) documentation to suggest that they're cross-signed public keys - can you point to some that I may have missed?

The reason why I ask is on the face of it, it doesn't make sense to implement in this way: It would mean that each new device would have its own keypair per service and cross signed by at least one other trusted device. Which could be fine, but now each service needs to store n public key pairs (one per device) after validating that the new key has been signed by a known key.

Then, when a new device is added to the Keychain (in apple's case), that device needs to generate m new keypairs for m services, have them cross-signed and then proactively registered for each service.

It does make sense to implement it as the person you're replying to suggests, where a shared private key is shared over an authenticated, end-to-end encrypted process - with the corresponding weakness that if the authentication method for adding new devices to an existing Keychain is compromised, so are all passkeys.

Hence the question.

Re: Ask HN: Why is WebAuthn so slow to take off?

#178

Post by SgtBastard »

wkat4242 wrote: post #118
JackGreyhat wrote: post #109

Earlier quoted context omitted.

Your password cannot leak, because it does not exist. Passkeys can also not be phished.

Cannot be phished by currently known methods. Trust me, sooner or later they will find a way. Either through specific implementation issues, workarounds etc. Remember when everyone shrugged off concerns about sms 2fa codes?

The WebAuthN standard (and corresponding browser implementations) do inject browser supplied attestation of the requesting domain, so only a horribly broken implementation would sign a request for mail.google.hackers.ru with the key provisioned for mail.google.com - the user has no input into what the browser supplies, hence its phishing resistance.

That being said, there's no end-to-end verification of the server, so any DNS-poisoning or proxy-MITM-ing of traffic that presents a certificate trusted by the browser will validly present the Passkey implementation a domain that matches a validly provisioned key, allowing session hijacking or the start of oracle attacks on the private key itself.

Also: phishing the recovery passwords to add a new device to the synched keychain is definitely a thing.

Re: Ask HN: Why is WebAuthn so slow to take off?

#179

Post by SgtBastard »

drexlspivey wrote: post #29
DangitBobby wrote: post #27

Earlier quoted context omitted.

Devices get snatched out of hands all the time.

Even if they snatch it unlocked they still can’t login because there’s an extra biometrics check required for WebAuthn

In at least Apple's case, Device PIN is also a factor to unlock the secure enclave where the passkeys are kept - so, assuming there's no stronger enforcement that it must use FaceID/TouchID, shoulder surfing a PIN unlock of the device and then swiping it grants access to all accounts.

Re: Ask HN: Why is WebAuthn so slow to take off?

#180

Post by [deleted] »

iudqnolq wrote: post #124
fatfingerd wrote: post #91

Earlier quoted context omitted.

You also won't have access to the TOTP backup of emergency codes.. If you get hit on the head or have the trauma of your life you might not have a password. These are tradeoffs that people use to balance security. Many people will lose to a sim swap despite not needing access to their life savings while on vacation with absolutely no proof of identity and a fallible memory.

I sync my (encrypted) OTP secrets between all my devices.

[deleted]
Post reply on HN