Storing passkeys in password managers is okay, actually

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?

And yet, PKI and TLS are not enough.

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&87Dog and 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: DuckGreen&87Finance.

Asymmetric cryptography

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.

Have you ever tried to do text book RSA by hand with paper and pencil? That scarred me for life! I still remember where I sat in that university library for that one assignment. Zero out of ten, do not recommend.

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.

Do you know what secure software hasn't grown in the last decade?

PGP.

And yet, security companies boast their products are built on top of PGP.

Don't forget banks, they like their 1024 bit ElGamal keys secured with PGP.

Checkbox compliance, am I right?

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.

I have like twelve security keys. Does that make me powerful?

Uhh. I wouldn't say powerful. More like excessive.

Well, I had more. They were sent to my family members.

Security hardware

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.

Did you mean two factor?

While WebAuthn is used as a second factor, with user verification it can function as both factors to a website! Passkeys with biometrics come with user verification. 😉

WebAuthn friction

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!

Why might that be?

Recall how difficult it is for people do proper password hygiene by hand. WebAuthn with roaming and platform keys requires diligence on the person and support for multiple keys by the service.

Support for multiple? Is one key not enough?

Ever lost your phone or forgot something at the hotel and never got it back? If that key was your only means to access your accounts, then you have to recover each one individually. On the other hand, if you have a backup key on each account, then you could access them safely and swap out the lost authenticator with a new one.

Alas, there are services which support one WebAuthn credential.

*cough cough* PayPal.

Ugh. Only one? Why?

Because implementers are in a privileged position and are not aware that multiple keys are required for a pleasant experience on the unhappy path. They often store the WebAuthn credential as a single column on the user table, thereby limiting it to at most one credential.

Or how a certain single sign on vendor forces WebAuthn credentials into the same flows as TOTP codes. IT had to configure multiple authentication slots to enable both Yubikey (roaming), MacBook (platform), and iOS (platform) authenticators. Employees who have no choice in the matter have to select from a drop down each time they want to log in.

Hey! You can present all known credentials at once! It's fine! Otherwise, I'm coming for you.

Matthew Miller and others have done a lot of work to make WebAuthn more accessible. You should check out what they've written.

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.

Unless you have two Yubikeys made after 2020 and set them up together in a special way.

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.

How come client side credentials aren't more common?

Most security keys support up to 25 discoverable client credentials. Some cannot delete a credential without destroying the rest. The user experience leaves a lot to be desired.

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.

Secret synching

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.

Unless you use LastPass.

SwiftOnSecurity

@SwiftOnSecurity@twitter.com

The fact LastPass doesn't encrypt website URLs is a known flaw it appears they never fixed on purpose, going back almost 6 years hackernoon.com/psa-lastpass-does-not-encrypt-everything-in-your-vault-8722d69b2032

Thursday, Dec 22, 2022

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.

Passkeys

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.

Why is third-party support so important? Are the platform solutions not good enough?

They aren't. Today, I cannot use a credential from Apple KeyChain in Microsoft Edge on Windows without using my iPhone.

Also, Apple would be a third-party to Microsoft in that example. For now, third parties like Bitwarden and LastPass are integrating with these vendor APIs. The big three appear stubborn in extending credential access outside their ecosystem.

Apple will expand access to their Keychain in their next operating system to applications like Chrome. This move is important and I look forward more work in this area.

Why would they be stubborn?

Once these keys leave the Apple ecosystem, they can make no guarantees on it leaking out and falsely verifying people to applications.

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.

If Windows Phone were alive, would it support passkey syncing like iOS and MacOS?

Aside from the anti competitive practices Google used against Microsoft that contributed to its death — Microsoft's features are behind and their systemic choice to deprioritize security has put Microsoft in the news for investigation by the Department of Homeland Security.

Microsoft might have passkeys on Windows Phone in 2023, with concerning security defects — given their aptitude for security this decade.

Passkey managers

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.

Without hardware security, how can I be sure that my passkeys won't leak?

You can't! That's why Apple won't share their keys with others.

Even so, it has been good enough for passwords. Passkeys are, in every way, better than passwords when the user experience supports them.

For example, SSH keys stored with password protection have superior user experience and security for SSH hosts. It is common to recommend SSH hosts disable password authentication!

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.

In ten years, passkeys may be the only authentication mechanism for services, apart from the passkey providers.

I look forward to that day.

Acknowledgements

Thank you to Matthew Miller, Xe Iaso, and Ibzan for review in a personal capacity.