Live data from Hacker News

Pass the Passkey: A Novel Attack Surface in Passwordless Authentication

unit42.paloaltonetworks.com

21–30 of 54 posts

Re: Pass the Passkey: A Novel Attack Surface in Passwordless Authentication

#21
post #20

This is someone related to a major TPM pet peeve of mine: the TPM only really cares about global device state and has no concept that a device may be a multi-user system, have multiple processes with different security levels, have multiple tenants, etc. For example, it really ought to be possible to seal a secret such that it can only be unsealed if PCRs have certain values (the usual TPM thing) and the requester of…

Wouldn’t that be the job of the software TCB to ensure only the appropriate user is given access (and prevent the user from accessing the TPM directly obviously)?

The TPM validates the state of the software TCB, and the software TCB validates the state of the lower layer, and so on.

Re: Pass the Passkey: A Novel Attack Surface in Passwordless Authentication

#22
post #9

Boy I’m so tired of people trying to make clever attack names. They don’t help remember things, there are too many. So all 3 “pass-ta-key” attacks are not attacks on passkeys, they’re attacks on the Google vault. And if you get access to the vault, then you get everything. OK. And if you get access to a synced traditional password vault, then you get everything. So… meh. These are bugs, they will be fixed. Good on th…

> And if you get access to the vault, then you get everything. OK. And if you get access to a synced traditional password vault, then you get everything.

No? It’s why 2FA exists. I have an email with password of 5 characters only and the password leaked decade ago, never changed it and no one accessed it because it has 2fa. I can share my whole password vault and I would not care about it because it’s useless without 2fa. Not the case with passkey, glad I never set it up on any of my accounts, pass+mfa is good for 99% of accounts (not sms obviously), rest are public private keys.

Re: Pass the Passkey: A Novel Attack Surface in Passwordless Authentication

#23
post #20

This is someone related to a major TPM pet peeve of mine: the TPM only really cares about global device state and has no concept that a device may be a multi-user system, have multiple processes with different security levels, have multiple tenants, etc. For example, it really ought to be possible to seal a secret such that it can only be unsealed if PCRs have certain values (the usual TPM thing) and the requester of…

Wouldn’t that be the job of the software TCB to ensure only the appropriate user is given access (and prevent the user from accessing the TPM directly obviously)? The TPM validates the state of the software TCB, and the software TCB validates the state of the lower layer, and so on.

> Wouldn’t that be the job of the software TCB to ensure only the appropriate user is given access (and prevent the user from accessing the TPM directly obviously)?

This only works with the current TPM design if there is one “appropriate user”.

The real world contains Chrome, BitLocker, various VMs and containers, etc. The TPM does not properly accommodate this world.

Re: Pass the Passkey: A Novel Attack Surface in Passwordless Authentication

#24
It seems like I have to trust more things that aren't very intuitive and are out of my control for passkeys to really be secure. For passwords, I only need to trust myself. I trust that I don't lose them, don't re-use them, and don't fall for phishing attacks.

Of course I also have to trust that whatever service I'm authenticating to does their part correctly, but that's the same either way.

I'm going to continue to use passwords.

Re: Pass the Passkey: A Novel Attack Surface in Passwordless Authentication

#25
post #20

This is someone related to a major TPM pet peeve of mine: the TPM only really cares about global device state and has no concept that a device may be a multi-user system, have multiple processes with different security levels, have multiple tenants, etc. For example, it really ought to be possible to seal a secret such that it can only be unsealed if PCRs have certain values (the usual TPM thing) and the requester of…

I'm not even sure why OS exposes TPM directly to applications instead of having a virtual store for credentials that could be backed by whatever.

UPD. nvm, that's not what's happening

Re: Pass the Passkey: A Novel Attack Surface in Passwordless Authentication

#26

It seems like I have to trust more things that aren't very intuitive and are out of my control for passkeys to really be secure. For passwords, I only need to trust myself. I trust that I don't lose them, don't re-use them, and don't fall for phishing attacks. Of course I also have to trust that whatever service I'm authenticating to does their part correctly, but that's the same either way. I'm going to continue to…

This is an insane and uninformed take. The malware described in TFA can even more trivially harvest passwords, which have never lived in a TPM. Passwords offer no security benefit over passkeys.

Re: Pass the Passkey: A Novel Attack Surface in Passwordless Authentication

#27
post #14

Earlier quoted context omitted.

Have we standardized a way to backup and export passkeys yet? Do websites commonly allow multiple passkeys to be registered?

Those are the right questions: While I'd personally prefer full copy/import/export control, having the ability to set up an second key in advance is functionally-similar to having a backup of the first one. If I had my 'druthers: 1. All sites/services would allow the registration of 5 or more keys, which can be tracked/revoked separately. That way if one device is stolen, you can invalidate that key without affecting…

It's not functionally equivalent, but it is a workaround, but requires doing it on every site (if they allow it) and it cannot be freely moved and re-backed up offline from the site.

The actual reason is people have many devices. I assume this is at least somewhat common, but I still avoid passkeys so IDK.

You're designing a system where we should just be able to backup our own keys if we want to.

Re: Pass the Passkey: A Novel Attack Surface in Passwordless Authentication

#28
post #12

These are endpoint malware attacks, not attacks on Passkeys per se. This is already a game-over position for an attacker to be in.

Yes, there's no security bug here of any kind. The "novel attack surface" already assumes the attacker can execute code as your user.

Re: Pass the Passkey: A Novel Attack Surface in Passwordless Authentication

#29
post #23

Earlier quoted context omitted.

Wouldn’t that be the job of the software TCB to ensure only the appropriate user is given access (and prevent the user from accessing the TPM directly obviously)? The TPM validates the state of the software TCB, and the software TCB validates the state of the lower layer, and so on.

> Wouldn’t that be the job of the software TCB to ensure only the appropriate user is given access (and prevent the user from accessing the TPM directly obviously)? This only works with the current TPM design if there is one “appropriate user”. The real world contains Chrome, BitLocker, various VMs and containers, etc. The TPM does not properly accommodate this world.

The primitives of a tpm ("observations", which in practice map to ca-signing keys of various levels of boot stage) are a very poor match for the real world. In order for them to be usefully consistent, you have to have consistent inputs. That means you can't observe the kernel itself, but instead you observe a key that signs a kernel. This is awful when it's Microsoft signing a series of kernels that advance one-way but the TPM doesn't actually ratchet to prevent downgrade attacks (and would be even worse if it did, because then you'd inevitably brick machines again and again). Instead you trust a long-lived CA and God help you when you need to rotate it.

It's even worse if you're self-hosting the signing, to the point that despite a ton of work put into making it safe and understood I wouldn't do it with the current design; a bare-state unlock is more predictable and reliable but I'll make sure to regularly exercise my backup key and header.

Re: Pass the Passkey: A Novel Attack Surface in Passwordless Authentication

#30
post #23

Earlier quoted context omitted.

Wouldn’t that be the job of the software TCB to ensure only the appropriate user is given access (and prevent the user from accessing the TPM directly obviously)? The TPM validates the state of the software TCB, and the software TCB validates the state of the lower layer, and so on.

> Wouldn’t that be the job of the software TCB to ensure only the appropriate user is given access (and prevent the user from accessing the TPM directly obviously)? This only works with the current TPM design if there is one “appropriate user”. The real world contains Chrome, BitLocker, various VMs and containers, etc. The TPM does not properly accommodate this world.

Ugh?

I thought application talks to the OS and the OS that check before it do the TPM thing.

Post reply on HN