Live data from Hacker News

Understanding Passkeys

michal.sapka.me

61–70 of 79 posts

Re: Understanding Passkeys

#61
On my Windows laptop, I was able to set up a passkey with Windows Hello [a fingerprint swipe] to get into a secondary Google account that really only exists to store [pages of] coloring books (PDFs)

I'm admittedly ignorant in this domain; but I thought it was interesting that my built-in Chrome passwords were, and still are, locked behind the Windows Hello pop-up and now I could theoretically use that same mechanism to sign in to a google account all together.

The answer is probably in this article but I just don't understand; I'd love to know why Windows Hello can now be used to sign-in to the account. Probably won't use it in favor of an authenticator app.

Suppose I should do a test to see how passkey behaves for the account on a Windows laptop and how that will then work on a Chromebook...

Re: Understanding Passkeys

#62
post #51

Earlier quoted context omitted.

passkeys are often 2 factors but not necessarily something you know, examples: - with macbook fingerprint sensor: something you have (private key on your device) and something you are (fingerprint) - with yubikey without fingerprint: something you know (passcode, hopefully required) and something you have (private key on yubikey) - with yubikey with fingerprint sensor: something you are (fingerprint, falling back to…

But that's the whole point - yubikey with fingerprint, or any combination of things that exclude "something you know", opens you up to a whole set of vulnerabilities. Like "legal snooping"; that can't be done if you're protected with "something you know".

you can choose to use something you know with passkeys if preventing legal snooping is your priority.

Re: Understanding Passkeys

#63
post #33

I always thought Passkeys is: Workflow for applications that aren't web applications. WebauthN only works in a browser, while passkeys work in "other" types of applications. The fact that the private key is stored on iCloud is mostly irrelevant for understanding how it works, that's a client device implementation detail. There are software-only authenticators that work with WebauthN just fine and allow you to back th…

webauthn can very much be used in a desktop application, you're just losing the phishing resistance factor, as the application can choose what to send as identifier, which includes collecting tokens for other tools/websites.

Re: Understanding Passkeys

#67

> The Client Device should sign the sent public key with its own Attestation Certificate. The certificate is used to attest to the manufacturer and its capabilities. A nitpick: should is a value judgment here. Quite a few of us would rather they do not, to avoid websites taking advantage of this to require specific proprietary hardware to authenticate. Thankfully my understanding is that Apple's passkeys do not provi…

It makes sense in an enterprise context, where the company might want to make sure no employee clones a client device key. In that case, they would require remote attestation to authorize only private keys living in secure elements (and thus less accessible to the employee).

Re: Understanding Passkeys

#68

I'm just confused about the "something-you-know" aspect of this. From my understanding, in the US you can be legally forced to give your fingerprint, face scan, probably your retina scan, maybe your voice identification... these are all "things you have", more akin to "username". But a password is the "thing you know", the thing they can't take from you (discussions of torture and AI mind-reading aside). So is the id…

We‘re using a FIDO2 security key as a passkey. Corporate policies force our users to also password-protect these.

So whenever people authenticate using a FIDO2 key as their passkey, they also need to enter its password.

The benefit of passkeys are:

- the Webapps only store a specific public key instead of a hashed password

- a direct connection is necessary for the challenge/response flow so that phishing attacks or MITM are impossible (AFAIK)

Re: Understanding Passkeys

#69
Looks like the OP tried to simplify things, but I think he's takes it too far. No mention of how FIDO preserves privacy, or how WebAuthn works with the browser protect against phishing. It doesn't get much beyond saying it's a protocol based on a public / private key pair.

Perhaps that is fair enough because his problem seems to be on how that private / public key pair is managed, as evidenced by his comment at the end:"I am waiting for an open solution that will give me the authority to manage and sync passkeys". But if you make Joe Citizen responsible for the protection of the private key, you will end up with plain text copies of it everywhere. That doesn't look like a workable solution to me - it's barely better than passwords.

WebAuthn went to the other extreme - it seemed to built on assumption the private key was stored in a hardware token and could not be copied. But that meant your ID died when the token was lost or broke. In effect in WebAuthn the private key was so well protected it also wasn't a workable solution. (Actually, they had a published solution to the lost token problem - you kept multiple tokens, and authenticated with every site with all of them. I don't know why they though that was going to fly.)

Passkey is somewhere between those two extremes - companies with a track record in protecting private data keep a copy, and manage the transfer between secure repositories. It's a step down in security, because you how have to trust the company not to leak it. But to be fair, I'd trust Google's ability to keep it secure more than I'd trust myself. You also have to trust the company to not give copies to devices that could leak it. So far they only seem to be trusting phones they make, which is a big restriction but is understandable. I can live with those compromises.

I'm not so OK with "if Google deletes my account, I lose my key". They are talking of allowing the transfer of the private key to other companies. Google giving a copy Apple is an obvious example, as it would lets you transfer your ID from Android to iOS. But so far it's only talk. And if they continue to insist only a phone they control can be trusted to store the key then even if they do allow transfer it still leaves you with just two key minding providers - Apple and Google.

I don't know what to do about that. You can't trust any machine that lets the user have sudo access (or in general change the software) - so Windows and the traditional Linux desktop is out. (Obviously Linux itself and open source in general is fine - Android is Linux after all. The issue is Linux desktops give their users sudo and then by extension any malware that gets in the ability to change/access anything - including the private key.) Perhaps they might allow transfer to other dedicated tokens. A totally open source token that doesn't support firmware upgrades would work.

In any case the key management problem is complex. Damned complex. The "just make the user responsible for key management" throw away at the end of the OP is never going to fly. It's a simple solution to a complex problem - and it's wrong. The reason we are in this mess state now isn't because Google/Apple are trying to lock you in - it's because there are trying to provide something that works for most people, and there are no easy/fast easy solutions.

Re: Understanding Passkeys

#70
post #9

Just because this is a common misunderstanding of passkeys, I'm going to state it again here: passkeys don't have to be locked to a hardware chip inside your device in order to work. It is entirely possible to have use passkeys only in software (shameless plug to the passkey manager I'm building, https://bulwark.id ), and that is most likely the way that most people will interact with them. I think it's unfortunate t…

How are you doing the Linux integration?
Post reply on HN