Passwordless Passkeys — Shared Account Access revisited [5]

Different vendors are slowly releasing (beta) options regarding Passkey management. (1Password, Bitwarden)

Sites and services are adding login-with-Passkey and perhaps somewhat different, sometimes a Passkey can be registered as a 2FA option inside an account instead of replacing the main authentication. Even some Password managers have started addressing their main password interaction: allowing (beta) users to sign-in with a Passkey. (1Password link 2, Bitwarden link 2)

In the previous article(s) I imagined functional desires beyond the horizon and potential pit-falls and opportunities regarding Passwordless and Passkeys. Though you can read this current article independently, you are welcome to open tabs: Previous article [4].

In this article I continue to address the future world of Passkeys keeping various use cases in mind, trying to find best-fit solutions.

Image Credits: FIDO Alliance

Example of Passkeys and Shared Accounts

In the future Passkey world, one scenario I see reality growing towards is the following: for example, a shared 1Password Vault containing various records amongst them Passkeys of websites. This example Vault is accessible by Bo(b) the Boss and Employee Eric.

This means that resource site A, has 1 Passkey registered and they are both used by Bo and Eric as the resource site provided one login for the company. — That’s something every company can relate to; various (vendor) sites on which accounts were registered with info@company.tld or backoffice@company.tld. For a 365-linked site or vendor like Cloudflare, one can use the multi-user account capability to link individual users, but most websites do not have that capability to register separate user accounts for every employee in the company on that resource website that might one day use it.

Now, ideally, regardless of the website having 1 user account, the website could still register two passkeys and have Eric and Bo save those in their non-shared Vault. Ideally, Bo’s one would be the ‘owner passkey’, and Eric’s the ‘regular-user’ passkey. This way, company owner Bo can revoke Eric’s passkey if they ever part ways. At the moment I have seen no information about “Passkeys access levels”, so this would be a feature request.

(In)Practicality of Security Keys Today

Imagine an employee going down the list of websites in the company’s shared Vault and upgrading enabling or upgrade the MFA on each vendor site. 1Password supports generating OTP-numbers inside the Vault-item, which is based on a shared secret which could be in incentive to have it replaced. This employee could add a FIDO2 Security Key today (or perhaps a Passkey “as a Security Key” which is sometimes offered by the browser), but here the issues occurs:

The employee cannot remove the OTP from 1Password because all the other employees in the company (or the Boss/manager) cannot use the employee’s Security Key to login and still rely on the OTP as the second factor. The Employee cannot ‘prepare’ the account by registering the Boss’ Security Key because that requires involvement of the Boss. (Meaning the Boss has to login the account and go through the steps of registering a Security Key.)

So what do we need?

A method to register the other Security Keys without them actually being there. Perhaps we can imagine a way to have Bo’s Yubikey generate a file which authorizes Eric’s Yubikey to register Bo’s Yubikey to websites on her behalf. Or perhaps a simple non-secret certificate that can be shared via the Vault that Eric can use when he registers his Security Keys on a website with the flag “These too please”.

Wouldn’t a Passkey in the Shared Vault fix all these problems?

A shared Passkey would indeed (or could) replace the password, the OTP and even the e-mail address technically, but currently it would (seem to) be a passkey that is not device-bound so it can be synced inside the 1Password shared Vault. This means, the private key material cannot be inside (or depended on) the hardware Secure Enclave of the phone or motherboard’s/CPU’s TPM. A Security Key would have increased security because the keys would be on separate hardware. So using 1 synced Passkey would negate the need for extra registrations of Security Keys / Passkeys, because the company would always authenticate with one key. It doesn’t really solve the issue, it side-steps it.

Please don’t get thrown by me putting these different use cases on the table together. I want to showcase the friction people run into when upgrading their current account list as well as scrutinize any alterative that is supposed to be superior. — The goal is to identify the suboptimal aspects, address them, and imagine / design better solutions.

Security Keys are a strong form of authentication, this is proven. They work best for employee-individual’s (or family-member individual’s) accounts. (Perhaps for techies only.) Regarding shared accounts, this would require every employee to login all the shared websites and register their key or plug-in their Security Key in Eric’s workstation to register extra ones. (Be warned, that sometimes the Security Key’s PIN is required for registration, so doing this on Eric’s workstation is not ideal.)

So we lack a great User Story around Shared Account Access, managing the set-up procedure and the Shared Access over time. That part does not seem to be fixed by Passkeys currently without paying a penalty.

Let’s start a train of thought:

1. Does it matter this Passkey future password-secrets inside a shared vault will get replaced by a Passkey which technically is also secret information?
2. Even though the whole authentication will become phishing-resistant, the storage and management of these shared passkeys would still be very similar as the password. From a purest standpoint, wouldn’t it still be a list of secret material that could be duplicated, leaked — though only on the users’ side this time?
3. Is needing to let go of hardware requirement really an architectural consequence of having shared, sync-able, Passkeys? Or is it a choice?
4. In the iCloud Keychain, the Secure Enclave is involved in decrypting the Key-chain's content, including Passkeys. 1Password’s implementation of saving Passkeys in its Vault, seemingly this let’s go of that dependence of the Secure Enclave to support cross-platform capability, correct?
   (It might support the Touch ID unlock later, but the initial decryption is not rooted in secrets on the iPhone but the user’s 1Password’s Main Password and Secret Key code.)
5. A Passkey can be device-bound, meaning they cannot leave the device, so they can also not be duplicated.
6. Asking the user if the Passkey should be device-bound or not could be a usability nightmare, because it is already getting hard to see the difference between sign-in-with-Apple (SSO, generated IDs +pass) and using a Passkey since the user just sees/experiences a Touch ID / Face ID interaction. A user in real life understands the difference between a sliding door, a revolving door, a garage door that rolls up. By looking at them, most of the time, users have an idea what is going to happen. But with authentication? Understanding the implications? That’s going to be a different story. Putting a pin in this for now.
7. Back to 3–5: Can we design a flow which works towards Shared Account Access by Passkeys but leans more on the management of it all and doesn’t give of the hardware-bound characteristic if it doesn’t have to.

Improve the design around Passkeys from lessons learned from management of physical Security Keys

Okay, I wouldn’t mind if 1Password (for example) keeps track of some of my Passkeys without having the secret material saved in its Vault. Like the listing of a website with SSO login, a similar listing or ‘ambassador Passkey entry’ still helps me. Don’t get me wrong, I still want 1Password to help me log-in to the website, but I don’t need it to store the complete Passkey. The flow of the authentication would be a bit different if we use device-bound Passkeys that are referred to from inside the 1Password Vault.

When logging into a website, 1Password would manage the interaction with help of the underlaying operating system so the secret key material never leaves my trusted device. The TPM or Secure Enclave would be used to do the work. This Passkey would also be clearly marked in 1Password as being depended on, for example, your “iPhone 2023”.

This effectively says: perhaps we should admit that we need different types of Passkeys, for different uses and we need to communicate that clearly to our users.

1Password still has the play a very important role. Being the ledger, the diary, keeping track of credentials. However, in the case of passwords, they are the keeper of the secret itself, for these highly-protected Passkeys, they perform the role of conductor.

Now, if we visit the 1Password Vault on device B with such a record, it would state something like: “This Passkey requires your iPhone 2023 to log-in this site”. Imagine that it is possible to add a second device-bound Passkey (of device B with help of device A). The 1Password record would then list “Passkey on your iPhone 2023” and “Passkey on your iPad 2022”) for the particular website record.

It would be 1Password’s job to manage this process.

Here comes the magic flow:

Since asymmetric crypto allows for encryption without interaction of the private key data. When registering a new account on a website and registering a Passkey (reference) in 1Password Vault, 1P could add the public key of device B iPad as well right then and there!

This requires that 1Password Vault has some pre-generated (signed!) key pairs (device-bound) and the public part could have been saved inside the Vault.

As soon as a new account is registered and the users checks the box “add/authorize my iPad 2022 too”, such a prefab public key is used and the Passkey reference is added to the website’s record inside 1Password.

Now from my understanding, normally a keypair (inside Passkey) is generated linked to the domain name, but prefab keys will have to be cryptographically bound to the website or app in a later stage. Device A’s iPhone 2023 could make an assertion (since it was authorized by iPad 2022) that “prefab public key 100 was linked to website https://domain.tld at time {t}.” and sign it.

This all will have be conducted by 1Password extension and/or desktop app.

The functional result is that there is not one Passkey shared amongst n-number of devices. No, there are p-number of Passkey-references shared amongst n-number of devices and the Passkeys’s secret material remains protected by the local Secure Enclave or TPM, the password manager being the conductor of it all.

This proposed solution would be great for resources like banks or other resources in which you might want to extend the Multi-Factor-Authentication nature from “having access to the secret material (Passkey)” with “having access to specific devices”.

Alternatively, if the website is the local library or a blog, one could use a “fully syncing Passkey” which is not device-bound and goes completely wherever you load your 1Password Vault or other Password manager of your choice.

Taking a score: Device-bound Reference-Synced Passkey & Fully Sync-able Passkeys

What are the imagined implications of the two? (The points are discussed for both.)

Device-bound Passkey (which is referred to from the Password manager).

1. ✅ Strong phishing-resistant authentication (v2023–07).
2. 🔒 Cannot be duplicated (unless Secure Enclave is compromised).
3. 🔒 Cannot be shared (unless whole device and local-auth is shared).
4. 🔒 Cannot be exported or back-upped. (As far as I know, like a FIDO2 Credential on a Yubikey, these secrets do not leave their device by design, or they should not.)
5. In a multi-device-bound Passkey strategy, Passkeys can be revoked per device on the related website. (And automated if there is a client-server protocol for that use-case.)
6. Provides the infrastructure for revocable Account Access Sharing to other people.
7. Provides the infrastructure for Time-based and Device-based (auto-revocable) Account Access Sharing to other devices or people by adding expiration.
   (Requires Passkey attribute of expiration that server listens to.)
8. This type of Passkey could have an attestation stating where it was generated on/in informing the website (or anyone) of the chain of trust. This could improve trust in a specific Passkey.
9. ✅🔍 On Passkey usage, it can be known (or logged) exactly which device and which inferred user/owner logged in as they are unique.
   (This requires the site to have labelled the Passkeys.)

Fully Sync-able Passkey

1. ✅ Strong phishing-resistant authentication (v2023–07).
2. 🟠/🚀 It can be duplicated.
3. 🟠/🚀 It can be shared depending on Password manager’s implementation.
4. 🟠/🚀 It can be exported or back-upped depending on Password manager’s implementation.
5. Duplicated-instances itself cannot be revoked independently from the original as they are complete copies. Registering a new Passkey to the website replacing the old would be required.
6. Provides only non-revocable Account Access Sharing to other people by giving them a copy of the Passkey.
7. (Though access to the Passkey could be ‘revoked’ (time-based), once shared, it should not perceived to be revocable as the secret key material was once shared and still active in this scenario.
   [Depends on 2/4.])
8. No assertions can be made on where this Passkey was generated. (No attestation during registration.)
9. 🟠 On shared Passkey usage, it cannot be known (or logged) who or from what device the Passkey was used on the Passkey alone.

Passkey type independent characteristics
Because this can be facilitated by 1Password or other Password managers:

1. Provides infrastructure to register Passkeys on behalf of other users without disturbing them by use of prefabricated (public, signed) keys.

Which one is best?

That’s the question. I think it is not without risk to only focus on fully sync-cable Passkeys. Though it definitely, relatively, falls under the ‘keep-it-simple’ strategy. In the long term I am concerned history will repeat itself. Though we have fixed the server-side, as these servers are no longer responsible for keeping passwords that can be stolen, now all that comes at the user’s end.

The difference with device-bound Passkeys is that it is simply harder if not impossible to steal the secret key material from a hardware protected Passkey. An attack would shift again towards social engineering and tricking the user rather than trying to attack the Secure Enclave. Fully sync-able Passkeys (as of now) don’t seem to use the hardware protections for cryptographic operations with the Passkey. The protections are software-based.

The irony

Remember the list we were working down: yes, it very ironic that first in point 2 and 3 we practically cried a river that during first stories around Passkeys as they did not support cross-platform syncing (like Windows and iOS). Now we have Passkey syncing and we saying: wait. Is that wise 100% all of the time? 🤷 — I hope the developers forgive us.

Recap Requirements for new Multi-Platform FIDO Credentials+

1. Easy to use.
2. Works on all devices in your primary eco-system.
3. Works on all devices in other eco-systems too.
4. Always with you.
5. Security level.
6. Recoverable.
7. Phishing Resistant.
8. No shared secrets.
9. + (Desired) Access Sharing. (Previous article)
10. + Protection against undesired Access Sharing. (Previous article)
11. Granting Access Just-in-Time | FIDO2 User2User

(Extended list started from: Outtake from Video ‘Move beyond Passwords’ (link))

Unpacking flow of secrets

We talked about two different kinds of Passkeys, but we need to eliminate some ambiguity. In my writing I mentioned a ‘device-bound Passkey’. On the FIDO Alliance’s site, this is written:

Passkeys optimize access and usability for FIDO Authentication

Organizations can deploy FIDO sign-ins with passkeys across a variety of use cases. Passkeys enable users to access their FIDO sign-in credentials on many of their devices, even new ones, without having to re-enroll every device on every account. Alternatively, device-bound passkeys that are bound to a FIDO security key or platform are an option for organizations that do not require syncing.

(https://fidoalliance.org/passkeys/)

So in other words, they do not leave the key or machine. They do not sync. Though it is possible to generate a Virtual Smart Card inside a TPM on Windows, it would be acceptable for the encrypted secret material to be stored on the device outside the TPM / Secure Enclave in encrypted from, just only accessible by cryptographic operations performed on the Secure Enclave. This way there is a cryptographic dependency to the device when trying to use the Passkey.

For the record in our Venn Diagram, we should acknowledge the existence for data-storage inside the TPM or Secure Enclave, even though the chaining of keys is an acceptable practice. (The Secure Enclave encryption keys encrypt the Keychain encryption keys, which encrypt… etcetera.)

Sometimes different technical implementations have identical functional effects, to get to a higher level (of refinement), we have to switch back and forth between technical and user implications.

So, in the article a device-bound Passkey is actually one depended on hardware of a device, not storage-wise per se, but definitely in usage.

→ This means that theoretically, the Passkey could be wrapped and encrypted by a device’s non-sync-able encryption key and the result stored inside 1Password Vault. You would still need it’s origin device to use it elsewhere and it would be useless without the origin device, but it is a choice that can be made. (For whatever reason.) — Mentioning this as a side note, I have no functional need to want this at this moment. The benefits/restrictions listed in ‘taking a score’ section would remain the same. For clarity’s sake, it doesn’t hurt keeping the Passkey’s storage and access in the same space, especially when discussed in the functional domain.

For your overview:

1. A fully sync-able Passkey. Generated, stored and usable anywhere with access to password manager’s Vault. Cross-platform.
2. A platform-bound Passkey. Generated with help of Secure Enclave. Stored in form cryptographically via encryption-chain depended on Secure Enclave encryption keys (so Touch ID, Face ID, Windows Hello). Allows for syncing within the same platform. (Apple for example via Key-chain.)
3. A device-bound Passkey (reference-synced) as mentioned in the article. Generated with help of Secure Enclave. A reference can be saved in a password manager’s Vault for administrative and interactive purposes. Stored in form cryptographically depended on Secure Enclave encryption keys (so Touch ID, Face ID, Windows Hello). Undecided where data is stored exactly but encrypted on system and not meant for syncing. Only usable by authenticating with device they were generated on. (QR-auth possible.)
4. A device-bound hardware-secure-stored Passkey (it imitates a Security Key or TPM’s virtual Smart Card or imagined Secure Enclave’s equivalent.) — Generated and Stored, inside the Secure Enclave / TPM, inherently cryptographically depended. Protected by hardware throttle. Can never be synced as hardware does not allow export.
5. There are other variants popping up: Microsoft Edge on MacOS allows you to save a Passkey to a certain website. I believe it is saved inside iCloud’s Key-chain earmarked for this browser, but you cannot access it via Safari or on other iOS devices. This also brings the Wild West implementation nature of the emerging Passkeys. I would consider myself a techy, but even for me, it is not always clear what software is doing and what the implications are in the moment. I worry how average end-users will experience this in the future.

Final thoughts

That is why the need for the so-called Conductor (Password manager) will not go away, whatever form of authentication we use.

I do not recommend offering all these types to all users. I do think it would be powerful for a password manager if they can manage type 1 and 3, however it will require delicate coordination with the underlaying operating system.

And is it server-side-decided if the Passkey is type 1 or 3. Can sites of banks enforce the use of type 3?
Should we really prompt users to choose? Will they understand?
Which type will be the default?
These questions need some further pondering.

For now, please take away from this article: the functional need of managing Passkeys as well as Passwords, the need for a User Story around a form of Shared Account Access, hopefully with a device-bound key strategies to anchor specific websites and the conceptual idea of prefabricated prep-Passkeys for facilitating revocable account sharing, applicable for devices as well as other users like co-workers or family-members.

Thank you for reading.

Joeri • Juramento