Passkeys and Enterprise Authentication

Update: Jun 9, 2023

I am thrilled to say that Apple has made some notable changes in iOS17 and MacOS Sonoma that pretty much address every issue I have pointed below. At this point, I have no reservations in saying, it is okay to use Passkeys in the enterprise with managed apple ID, with appropriate controls. The very small reservation being, dependence on iCloud — if that makes or breaks anything for you. Security is complex.

So what are the improvements?

1. Managed Apple IDs now support iCloud keychain
2. Admins can now control which devices users can sign into using managed apple IDs, you could restrict this to managed or supervised devices.
3. There is a new configuration that now supports attestation (com.apple.configuration.security.passkey.attestation), effectively letting you be sure that the passkey was created on a managed device.

What does this mean?

This means you can now use passkeys with managed apple IDs with confidence. You can only synch passkeys to managed devices. You can prove to RPs that the passkey was created on a managed device via attestation. And, you can turn passkey sharing off between employees.

Well done Apple!

Original post: Aug 22, 2022

I am a big fan of FIDO2, it brings a lot of convenience to the user, and improves the security posture. The protocol itself has characteristics that make it non-phishable.

So undoubtedly I was super excited when I saw passkeys gaining mainstream attention by Apple, Google, and Microsoft. This frankly legitimizes FIDO2, now you can pretty much assume that all browsers on all modern devices will support WebAuthn.

Undoubtedly in the consumer space, passkeys will be great. It is, a password replacement. But, Passkeys in the enterprise space, is still something that I personally I have some reservations in.

Passkeys currently do not support attestation

The first step in establishing trust is registration where attestation plays a big part. Orgs typically like to control the keys that can be used within the org by controlling the attestation certificate. This means, an attacker cannot hijack the registration process since they’d be caught when the attestation cert does not match. And the server can have the confidence of the origin of the device. This is especially important because you want to guarantee that the biometrics are of a level you trust, not so much an issue on iOS, but certainly an issue in the Android ecosystem.

Interestingly mobile platform authenticators do have attestation. But iOS16 will make passkey enabled by default, not controllable by the admin, and unless you are an iOS only ecosystem, this makes it a non-starter for real world orgs.

In the consumer space this is not such a concern because you want to increase the userbase on which your services work, so you probably do not want attestation. Enterprise, well, is the exact opposite.

Passkeys feels like watered down FIDO2

One of the key features of FIDO2 is detecting keys that are duplicated, there is a counter that increments authentication count, and a duplicated key can be detected because the client and server-side counters go out of synch. This is no longer true with passkeys since by design the key is duplicated across your devices. So effectively you lose this protection.

The other big issue is, FIDO2 is unphishable. But if you secure it with iCloud or Google login, which can be phishable, don’t you lose the unphishable nature of FIDO2? Bummer!

Passkeys rely on the vendor’s cloud

FIDO2 keys on a physical key that you plug-in such as a yubikey or feitan, resides on a physical key in your pocket. Not so when you use passkeys. They will synch to iCloud/Google cloud/Microsoft cloud. As of now, there is no mechanism for an enterprise to say, hey I want to protect my org’s private keys with an encryption mechanism I control.

In Azure for instance, for table or blob storage you have a number of options when storing your enterprise data, you can choose to encrypt by default by a rotating key that Microsoft manages, specify your own key, or even use HSM. When you have all these options in protecting the “contents” of your house, why wouldn’t you want to have such level of protection when protecting the front door (authentication) of your house?

Do I doubt that Apple or Google or Microsoft don’t have a great security infrastructure? No. But as an enterprise I cannot take that risk, I want to own and control my private keys, with zero possibility of any government or third party ever under any circumstance being able to get my key. And no it isn’t enough if they say they won’t do it.

Passkeys can be airdropped

So lets say, you are the prince of Nigeria, and we happen to meet in an airport lounge. The charming person you are, you social engineer me, an unwitting employee to airdrop my passkey to you. Now you can authenticate as me.

That may sound far fetched, but this could also be two developers saying, hey just share your password so I can test something.

This throws all non-repudiation controls out the window. As of now, there seems to be no MDM way of an enterprise admin to enforce disabling sharing of passkeys via airdrop.

Passkeys will get shared on personal devices

Let’s say my org issues phones that are tightly controlled by MDM, but, they allow me to use my personal iCloud account. Now I also have a personal Mac and personal iPhone that I use the iCloud account on. By design, the passkeys that I use for enterprise RPs are now synched to my personal phone.

Not only that, via QR code/Bluetooth, I can now use my personal phone to authenticate to the RP that otherwise should only be authenticated via a tightly controlled registered device.

This is another vector that seems hard to protect. There are some discussions on this problem, but I don’t think a cross-vendor solution exists as of today (please let me be wrong about this!).

Passkeys are only as good as the biometric protection on your device

This, I am not so worried on Apple devices, but Android has a very wide ecosystem, and not every device’s touchID is as good as the other. Until recently even devices as new as Samsung S21s were considered insecure (not anymore, but you get the idea). How secure is that TouchID on your OnePlus?

So this leaves an incredible overhead on the organizations to constantly stay on top of emerging security threats, especially in the android space, and effectively whitelist allowable android devices in the enterprise.

Windows — is a whole another story. Microsoft effectively doesn’t have a mobile OS. Windows Hello can be considered pretty secure, especially with all controls they offer and further security around TPM they offer/require on Windows 11. But, when using your mobile device to authenticate on Windows, they are back to relying on Android or iOS (at least as of now). And all the Android issues apply here too.

Passkeys are probably only good as a second credential

So this is something that is not a show stopper, but something you must consider, and this affects both the enterprise space and the consumer space.

As of today, passkeys are tightly bound to a vendor (Google or Apple or down the road Microsoft). There is no cross-vendor story. So if I decide to move from iOS to Android, all my passkeys don’t transfer from iCloud to Google cloud.

In the enterprise space, a user identity is tied to a billion ACLs, you don’t want to reprovision all of that, and the user’s activity history etc. just because they bought a new phone and switched ecosystems.

In the consumer space, you don’t want to lose the customer effectively because they got a new phone.

So what will you do? You will have to effectively maintain a primary identity, and use passkey as a replacement that you will use. So when you recreate a passkey in an alternate vendor ecosystem, your identity still moves with you.

Okay, so this means we still need to maintain an older identity using older mechanisms, right? <insert facepalm here/>

This is not a bad thing per-se because 99.999% of authentications will continue to be passkey as long as the user registers to use it, but effectively for the user this means the equivalent of “Would you like to register your face ID” .. and this time this will synch across your apple devices. You still will need your old fashioned MFA, username password in the background.

.. few other concerns, but lets get started with the above 