Storing passkeys in password managers is okay, actually- 24 min read - Text Only
Passkeys, as a technology, is finally available and accessible to all sorts of people, from the
hunter2s to the
@ZutWp@E2Uvp!AL9 kind of people. Passkeys raise the security floor for everybody and they lower the cognitive friction for everybody.
Passwords and secrets
"Ah ah ah, you didn't say the magic word!"
Secret door knocks and a password to a cautious doorkeeper are low tech. And yet, that's what people, of all kinds, have used to protect their bank accounts, movie ticket purchases, and pet exercise trackers like it's 1970.
Passwords are symmetric, and that is one of their major problems. The receiver of the secret has the the ability to authenticate in your place — hence symmetric. Then, suppose the receiver is trustworthy and never authenticates as you, what if someone else listens in and repeats your password in your place? We use secure communication channels for that — often over Transmission Layer Security (TLS). And yet, with the internet being a distant and confusing place, how are you confident that you're telling your password to a trustworthy and intended receiver? For that, we have Public Key Infrastructure (PKI), Certificate Authorities (CAs), and root certificates packaged by your operating system, device vendor, or browser which anchors all accepted certificates you receive from the other side for TLS. In short, PKI and TLS safeguards even the
hunter2 people from shouting their second favorite nephew's name to a malicious bystander or imposter in the clear.
There are a lot of layers just to communicate and authenticate safely, right?
Passwords and secrets are unusual and unnatural. It's like keeping track of who we've said what to and eventually we slip up. The cognitive load of remembering which password goes to whom promotes insecure behavior like password reuse and predictable patterns like
DuckGreen&87Movies. While these passwords fill up the "password strength" bars on their respective websites, it takes one leak for a malicious person to guess what the password might be for the bank:
Do you know what unusual and unnatural science can help us weak and fallible people? Cryptography! A science of making computers follow complex predictable steps that gives us confidentiality, authenticity, and integrity of our communications and data. Enter asymmetric cryptography! A way to prove or communicate something without revealing a way for another to do the same. Computers can do this efficiently — people can't.
The core mathematics in asymmetric cryptography that power passkeys and WebAuthn security keys have been around for decades. While RSA signatures and ECDSA have kept to their promises, newly discovered risks and their mitigations come out every few years. For example, security keys and TPMs use deterministic ECDSA with constant time operations to mitigate power fault and timing attacks.
Recall how challenging it is to keep passwords apart and to never send them to the wrong recipient. Password managers have this neat benefit: they know when you reuse passwords between sites and can make up unguessable passwords unique for each site! Then when you sign into one site, it doesn't recommend passwords for another site. However, password managers do not stop confused users or victims of phishing from copying passwords out and into another website or application.
WebAuthn, which passkeys use, build in an effective defense to secret sharing: origin binding! In other words, the website name, or "origin", is a part of the authentication verification. That is, even if the same secret were used to prove the identity of someone, the proof will be rejected by any origin it isn't intended for. And because it is asymmetric, the proof cannot be changed to be accepted by another origin!
WebAuthn has been around for five years now and its adoption is limited to enterprise users and the security conscious power users. To use WebAuthn, they'd use roaming security keys, which provide high assurance on authenticity and a means to verify a user's consent or presence on multiple devices.
It took years for personal computers and phones to come out with security hardware support – like TPMs or Secure Enclaves. New devices can use these built-in platform capabilities to authenticate people with biometrics.
Now into 2020 — all these people finally have a built-in platform authenticator! Except, this barely improved WebAuthn adoption because of one sticky detail: WebAuthn is a two party solution to authentication.
If the person who wants to authenticate is one party, then the other must be the website or service they wish to authenticate to. Guess what services don't have WebAuthn yet? Banks, dine in movie theaters, and pet exercise trackers!
WebAuthn is having a hard time growing on the service side because:
- People lose things and they need a way to access their accounts
- Implementers don't understand WebAuthn
- People and implementers think two or more security keys are too complex
Security key limitations
Normally, when a user authenticates with WebAuthn, their device is sent a list of known credentials from the service and these server-side credentials are forwarded to the security key. If the security key can decrypt a credential, then it can prove it knows the private key for the authentication challenge. Server-side credentials require no storage on the security key and therefore it supports as many websites and services as needed! However, these credentials are not usable by a second authenticator, as another authenticator cannot decrypt its credentials.
Implementers deliver poor user experiences with server-side credentials. Instead of treating it as its own thing, it is commingled with other second factor methods and it becomes a pain to use.
On the other side, there are client-side discoverable credentials where the security key retains the context and private key then when challenged, proves it knows the private key. That key never leaves the security key; therefore cannot be used by a backup security key in passwordless authentication.
Client-side credentials and server-side credentials require the receiver — called a relying party — to keep track of public keys for each account. The authentication challenge is then matched to a trusted public key and is verified.
If all websites used discoverable client-side credentials, people would have to carry a literal key-chain of authenticators — one with a big price tag if lost.
People need to authenticate with many websites with as little physical hardware and as few public keys as possible. The hardware is now accessible. But the limitations are too much for people. They need syncing private keys.
Apple synchronizes the credential vault between devices without having access to the vault contents using end to end encryption. This vault held website and Wi-Fi passwords, and now it holds private keys to authenticate with websites.
The other two share key material in a similar way: passwords are accessible when the owner hands off the data from device to device, or when they present their passwords and passcodes to the vendor after losing all devices.
Password managers follow in kind. A vault can be decrypted when a person presents their username and password. However, the encrypted vault may not be delivered to the person until they complete a second factor challenge. When the vault is updated, the vendor receives an updated vault where the new credential and other identifying info is encrypted.
The difference between a password manager and Apple's Keychain is that password managers are compatible and available across multiple browsers and platforms. They also support sharing credentials to families, friends, and businesses. Although, in most circumstances, you should not be sharing credentials.
The big three tech companies: Apple, Google, and Microsoft, are bringing a different kind of authenticator to the masses: passkeys. These synced credentials are shared between devices with end to end encryption and are backed up to the cloud without giving the keys to that company. On each device, it is stored in the platform's vault which is secured using the platform's hardware.
When an individual visits a website and is presented with an authentication form, its origin — such as
cendyne.dev — is searched in the vault's index for matching credentials. This platform vault built-in behavior is credential discovery! Password managers do the same thing in browser extensions and native applications.
When a WebAuthn credential is indexed, discoverable, and synced between devices: we have a passkey!
Platform-provided passkeys solve the frictions WebAuthn security keys have.
- People can lose things and still access their accounts
- Implementers are given a simpler model to implement
- People and implementers can get by with one WebAuthn credential
However, passkeys by these vendors have one last hurdle to overcome: interoperability.
Password manager interoperability
Concurrent to the evolution of passkeys, platform vendors have released APIs that enable third parties to supply password credentials to websites. For example, Apple's Credential Provider Extensions give third parties a well defined way to recommend password credentials with a consistent user experience. More can be seen in Implementing AutoFill Credential Provider Extensions.
Before these integration options were available, everyone had to copy their passwords from their third-party password manager every time they authenticate. This is a big friction point and makes phishing easier!
Friction in security push people to insecure workarounds. Platform support for third-party credentials is vital to secure everybody, including passwords and passkeys.
Apple is stubborn in sharing passkey private key material to other parties.
Instead of sharing Keychain private key material to other parties, third parties may instead interface their passkeys to applications and websites with a new API in their next iOS release. Android 14 will support third-party passkeys too. Windows Hello is a year behind on supporting passkeys in the first place — who knows when they will catch up.
If Apple isn't going to share their Keychain keys to other vaults, then third parties like 1Password will have to bridge the platform divide across Safari on iOS and Edge on Windows.
This gap will close soon. People that use different platforms will be secured with greater convenience and be at less risk. Third parties will cross that bridge first.
The answer for most people will be a cross-platform credential provider. Third-party password managers will meet the needs of people that use Android and Windows sooner than a first party collaboration by Google and Microsoft.
Password managers have been available to people for over ten years now. In that time, platforms have provided more ways to integrate their credentials with less friction. Platforms have demonstrated interest in supporting third-party credentials.
Passkeys are catching on and the same platform support story will repeat, albeit at an expedited pace.
Password managers lack something that platform vaults have: hardware backed encryption and system-provided integrity. They are implemented with web technology which is challenging to end to end encrypt.
Password managers have proven they can be effective and secure enough to improve security for all kinds of people, especially the most vulnerable.
In the last five years, third-party password managers have gotten into the big three platforms. In less than two years, we should see support for passkeys grow for first- and third-party passkey providers.