Passkeys are a trap. Do not use them

Paypal actually merely prohibits hardware keys from being registered as passkeys for sign-in. I can’t register my Yubikey as a passkey for sign-in, but I can register Windows Hello which is device-bound. For 2FA, they only allow hardware keys, and do not allow platform passkeys of any kind. Also PayPal does not have any way to remove the password from your account, and even if no other option is registered, SMS is still forcibly turned on, so password+2FA is always available in the case of lost passkeys.

Apple still requires your account to have a password and 2FA to be able to sign in with. Your sign-in is not dependent on having one of your trusted apple devices with you to use the passkey. Which is fine strictly from the standpoint of lockout risk.

As far as I understand, they only allow U2F hardware keys to be registered as 2FA. I do take issue with Apple in this case, though, because upon registration, your whole account IS tied to those keys, and you have no say in the matter. SMS is disabled, trusted device codes are disabled, recovery contacts are disabled, the recovery key only exists for password reset and still requires your security keys to use it, and there is no recovery if you lose all your security keys.

Still, this is not as bad as if they were to require device-bound platform passkeys to sign in, since YubiKeys are very durable, not as expensive to buy extras as a smart device would be, extras can be stored in safe places without consequence, and user verification is not enforced on the hardware keys themselves during sign-in, meaning there is no PIN to be forgotten.

And of course, most importantly, Apple does not mandate security keys to be registered to your account. They are optional.

Google’s way of handling this is alright. You are always free to register synced passkeys and other 2FA methods to your account, and these device-bound passkeys are not required as the sole way to sign into your account. Google also provides no way of removing the password from your account.

They have a similar high-security account state to Apple available in their Advanced Protection Program, but this is voluntary, comes with a slew of warnings to ward off people who would be at risk of getting locked out, and synced passkeys are still allowed to be used to sign in.

As far as I know, Netflix does not offer passkey registration for user accounts. In fact, they don’t even offer 2FA. And I am not aware of any clever usage of passkeys for DRM by any company.

Dunno about general consensus, but I’ll give you my take.

Passkeys are better than password+2FA because of being more phishing-resistant, but always maintain password+2FA so that it is available for use in the case that you lose your passkeys.

Email is better than nothing, but unless you use a different email than is used for password resets, OR unless the company requires some second form of verification to reset your password, it turns your email into a single point of failure for the account you’re trying to secure, because you’ll be able to reset your password and complete 2FA with the same email.

Avoid SMS at all costs unless it is literally unavoidable. If there is a more secure option than SMS, use it and leave SMS disabled. This is because not only is there the risk of SIM-Swapping, but the telecom towers can literally be convinced to redirect your texts and calls to an attacker’s phone even without a SIM-Swap.

For passwords, do not reuse the same password across multiple sites. Find a password manager you’re comfortable using, create a strong Master Password for it, and use the password manager to generate strong random passwords for all your other accounts.

1 Like

The Netflix example was from the article being discussed. I haven’t actually used Netflix for the last few years, so I’m not aware of how things work there now.

Apple still requires your account to have a password and 2FA to be able to sign in with. Your sign-in is not dependent on having one of your trusted apple devices with you to use the passkey.

It looks like we’re describing different cases or mixing up some terms (which is super easy with passkeys/security keys/etc.).

You can sign into iCloud in the browser using only a passkey, without 2FA or a password. But in that case the passkey is the one from an Apple device, not from any password manager or non-Apple device

To sign in on devices (not on iCloud.com), right, the user is required to use a password and 2FA, where 2FA can be a trusted device

In everything else it seems like we just agree. Sorry if I missed something.

I think this is a fair criticism, and it’s one that I’ve been looking into ways to mitigate for the past few years.

A full login passkey (one that skips both the password and 2FA) is a single point of failure, and if a password manager or other account which holds such a passkey is compromised and the encrypted database which stores it is accessed, then that allows for the compromising of other accounts.

On the other hand, passkeys have a great potential to be secure, and their phishing-resistant nature and their immunity to data breaches and the way they’re just so unbelievably convenient to use make passkeys too tantalizing not to pursue.

The problem is that full login passkeys are an eggs-in-one-basket situation, so the solution is to make an adamantium basket that only you tightly control. And sure, you can just carry a YubiKey around, but plugging it in every time you need to sign in is annoying and not all websites allow you register a login passkey on a YubiKey.

Strongbox (only available in the Apple ecosystem) is the only password manager I have found which can suitably solve this problem without involving YubiKeys. They are based on KeePass and offer the ability to create offline databases which do not sync, they have a feature called “Virtual Hardware Keys” which basically uses the Secure Enclave as an HMAC-SHA1 key provider instead of a YubiKey, they have a quick unlock which allows you to use a PIN and/or fingerprint unlock, and this also leverages the Secure Enclave and the PIN has a three-try lockout after which the Master Password is required, you can exclude Strongbox from iCloud device backups from your iCloud settings, you can exclude databases from local device backups from within the app, and they have full support for passkeys.

What I’ve been doing is to register login passkeys for all my accounts to a database which has been set up to meet all those requirements, and I’ve done the same for all my Apple devices. I intend to delete my login passkeys from my Keychain once I’m ready to do so.

Anywhere that allows for it, I also register a passkey to my YubiKey for use on my Windows desktop. When I get a Windows laptop that is ESS-ready, I will begin registering passkeys to Windows Hello on that laptop.

Passkeys which are 2FA-only will remain on my Keychain, and passkeys which only skip the password but still require a 2FA code will be allowed to remain in my Bitwarden vault. Passkeys which are registered to accounts which do not offer 2FA, such as my passkeys for hibp, will also remain in Bitwarden and on my Keychain.

In this way, any passkey which fulfills only one factor on an account with 2FA can be synced to an account or password manager which stores the respective factor the passkey fulfills, and any passkey which fulfills both factors will remain on my devices and either backed by or bound to hardware.

By so doing, the bar that two accounts need to be compromised to pwn my other accounts is maintained while still allowing myself the convenience and security benefits of full login passkeys.

1 Like

I also love this approach, and there is a second option doing the same for macos: passage with Secure Enclave plugin. Low-level-wise it’s not the same, but security-wise I think it’s the same idea you propose.

I probably should learn more about Strongbox, but if i may ask, how are they supposed to back up this setup? With the HMAC-SHA1 from a YubiKey, we can back up the HMAC key, but I wasn’t aware we could do the same with SE. From my understanding, KeePassXC and KeePassDX have plans to do similar thing, but the backup issue makes them wait for the next .kdbx standard release, where hopefully multiple hardware keys will be allowed, and that will solve the backup issue.

or wait, if

they have a quick unlock which allows you to use a PIN and/or fingerprint unlock, and this also leverages the Secure Enclave and the PIN has a three-try lockout after which the Master Password is required,

Then that’s not the case where the database can’t be unlocked without the “hardware” SE as key. It’s just that an already unlocked database can be accessed using the Secure Enclave. But KeePassDX and KeePassXC already do the same thing.

The article was about companies poising to control users with attested passkeys, no? The only way they could control users with passkeys would be to make passkeys the only available sign-in method, and then only allow passkeys which cannot be removed from the devices on which they were created so as to make sure users can’t sync or export them to, and use them from, unapproved devices. Which, ultimately, would shoot them in the foot because EVERYBODY would start getting locked out.

Trying to find companies which do or don’t offer or use device-bound platform passkeys misses the point unless you can also point out that they have removed all other sign-in options or otherwise made them somehow mandatory to complete sign-in at the end of the day.

Also, I don’t see how passkeys could provide anything of value to DRM that it doesn’t already have. DRM already uses hardware-level security. The GPU, the monitor, even the HDMI cables have burnt-in encryption keys for use in DRM, and Netflix can already restrict things based on approved or not approved devices — Louis Rossmann made a video about how Netflix only allows 4K streaming on their short list of approved devices and fully leverages DRM to enforce that.

In this statement, I meant “maintain” rather than “have.” Point is, password+2FA is still always available on your Apple account, and this does not necessarily need to involve your trusted devices, you could use one of your registered SMS numbers for example.

As I remember the article, the point was that passwords can be shared, and a passkey-based system could be designed to prevent passkeys from being shared. Some companies could use that to protect copyrighted content. Not sure DRM solves this problem.

The lockout argument is absolutely valid, and I believe it will really stop companies from using passkeys this way in cases where it isn’t necessary. I am not protecting the article, i think it is clear from my other comments.

1 Like

The user provides the HMAC key. If you’re gonna back it up, that’s the time to do it.

Btw, bit of a tangent, but something fun about this is it’s uncapped. You can have a 512-bit secret if you want and Strongbox will accept it.

Virtual Hardware Keys were originally intended as a workaround for the inability to use YubiKeys during autofill on iOS, but it does nicely for backing your database against the Secure Enclave.

No, no, they keep the database locked when not in use. The Master Password hash is stored in the Secure Enclave, and when you complete your Quick Unlock methods, it takes the Master Password hash from there, takes the key files if any, and then gets a new HMAC-SHA1 response from the Secure Enclave to unlock the database. If you burn your three tries on the PIN or if you make changes to FaceID or TouchID, the master password hash is destroyed.

The only other way in is to provide your Master Password. And if you try opening your database from anywhere other than the device with the registered HMAC secret, it can’t be opened.

Other KeePass-based password managers store the full Master Key in protected memory and encrypt it with the quick unlock method. So if you get the database file and dump the RAM, you can throw it at a GPU farm and start brute-forcing it.

1 Like

Thanks! My description of how the other KeePass-like apps work was inaccurate, I see the difference now.

1 Like

Anytime! ^^

1 Like

Btw fwiw the TPM can do HMAC operations too tpm2_hmac - tpm2-tools

If anyone who’s reading this thread wants to take a crack at making a virtualized+sandboxed, tpm-backed password manager for Windows which offers offline databases and has a browser extension for passkey support and biometric+PIN TPM-backed quick unlock with anti-hammering and biometric change detection and it doesn’t store the Master Key while locked…