When<\/em> WebAuthn is deployed in the enterprise, typically it’s via the use of roaming authenticators (commonly Yubikeys), platform authenticators (TouchID\/FaceID\/Windows Hello) or a combination of both.<\/p>\n\n\n\nIn my previous role, I deployed two Yubikeys to each member of staff; one for daily use and the other which would serve as a backup but also crucially, it provided a way to bootstrap access from the user’s iPhone\/Android.<\/p>\n\n\n\n
In my current role, I decided not to go down the path of roaming authenticators but instead rely on platform authenticators. They’re less costly (comes free with the laptop!) and provide a slightly better user experiencecccjgjgkhcbbirdrfdnlnghhfgrtnnlgedjlftrbdeut<\/p>\n\n\n\n
To summarise, we get the following security benefits:
\u2705 Strong resistance to phishing attacks<\/p>\n\n\n\n
\u2705 Strong guarantees that the user authenticating is the same person who set-up the keys. i.e., it is designed to be incredibly difficult, if not impossible to extract the credentials out of the authenticator. Therefore it is fair to say that when Mr. Wick<\/em> logs in to an application, we have an extremely high confidence that it is indeed Mr. Wick<\/em>.<\/p>\n\n\n\nPasskeys in the enterprise<\/h2>\n\n\n\n
The ability to bootstrap user authentication from another device is a killer feature and should help drive adoption. Widely used Identity Providers currently have no way<\/em> of supporting platform authenticators on more than one device without<\/em> falling back to weaker authentication (at the expense of a worse security and user experience).<\/p>\n\n\n\nAs an Okta user my self – passkeys are a game changer. I no longer need to go through the painful process of adding users to temporary exception groups simply because they want to sign in to an application from their mobile device. Instead, I can include the bootstrap process of setting up WebAuthn on both laptop and phone in the onboarding guide.<\/p>\n\n\n\n
Saying that, Apple has set a precedent that I fear Google and Microsoft will follow.<\/strong><\/p>\n\n\n\nThe Apple implementation of passkeys has removed<\/em> the ability for WebAuthn credentials to be device bound.<\/em> You have no<\/em> choice but to synchronise them to your Apple ID account. The same Apple ID that is a common phishing target for criminals and the same Apple ID that cannot be protected with phish resistant MFA (actually SMS is always available as a fallback)<\/p>\n\n\n\nTo summarise, this is where I stand on the matter:
\u2705 Passkeys could be used to bootstrap other devices so that staff can set-up strong user authentication on multiple devices. This is awesome and should help drive adoption because it should no longer be necessary to purchase hardware security keys<\/p>\n\n\n\n
\u274c We’ve gone from device bound, strong-guarantees-its-the-same-user<\/em> credentials to your credentials must<\/strong> be synchronised to this user’s personal iCloud account which can<\/span> be phished<\/em><\/p>\n\n\n\nSummary<\/h2>\n\n\n\n
We seem to be missing an opportunity to have the best of both worlds for consumer and enterprise adoption.<\/p>\n\n\n\n
By all means, drive hard the adoption for consumers and synchronise their credentials to their cloud accounts. I have no doubt that both user experience and security will increase.<\/p>\n\n\n\n
However, the threat models faced by enterprises aren’t necessarily the same as those that consumers face and therefore I think it would be a mistake to replace an existing strong process with a weaker one in the name of security and adoption; especially when there is little to no technical or UX reason to not give customers the choice<\/em>.<\/p>\n\n\n\nFor the avoidance of doubt, I think organisations coming from weak, phishable MFA will<\/em> benefit from passkeys; regardless of if they are synchronised or not. Nonetheless, I believe that if your organisation (like the last two I have worked for) is already immersed in the WebAuthn world then this could be a step backwards for you.<\/p>\n\n\n\n<\/p>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
A mouthful of a title but in this blog, I’ll try to answer this question based on my own understanding and experiences deploying WebAuthn. Firstly, if you don’t know what Web Authentication is (commonly referred to as WebAuthn), it might be worth having a quick read of my previous blog post as the WebAuthn standard […]<\/p>\n","protected":false},"author":32,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"templates\/template-full-width.php","format":"standard","meta":{"jetpack_post_was_ever_published":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-8265","post","type-post","status-publish","format-standard","hentry","category-tech"],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p1trTO-29j","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/emtunc.org\/blog\/wp-json\/wp\/v2\/posts\/8265","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/emtunc.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/emtunc.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/emtunc.org\/blog\/wp-json\/wp\/v2\/users\/32"}],"replies":[{"embeddable":true,"href":"https:\/\/emtunc.org\/blog\/wp-json\/wp\/v2\/comments?post=8265"}],"version-history":[{"count":38,"href":"https:\/\/emtunc.org\/blog\/wp-json\/wp\/v2\/posts\/8265\/revisions"}],"predecessor-version":[{"id":8305,"href":"https:\/\/emtunc.org\/blog\/wp-json\/wp\/v2\/posts\/8265\/revisions\/8305"}],"wp:attachment":[{"href":"https:\/\/emtunc.org\/blog\/wp-json\/wp\/v2\/media?parent=8265"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/emtunc.org\/blog\/wp-json\/wp\/v2\/categories?post=8265"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/emtunc.org\/blog\/wp-json\/wp\/v2\/tags?post=8265"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}