If you haven’t looked into FIDO2 yet, you really ought to. Username/passwords is essentially no security in today’s day and age. MFA adds some security but is phishable. Not all MFAs are equal. And FIDO2 as a standard gives you the convenience and security, a rare but good combination in the security/identity world.

I had written earlier about Passkeys in enterprise scenarios.

When Passkeys were first baked into iOS16, it felt a bit not ready for enterprise scenarios. And as indicated in that blogpost, with iOS17, Apple has rolled out some very thought through improvements that make Passkeys a great solution for enterprise. I can’t wait really.

You will still synch key material through iCloud, which you can disable by disabling keychain synch — effectively making it a good solution for a single device scenario if synching through iCloud gives you heartache. Android still doesn’t have all the controls as of today, but at least for iOS you can offer enterprise level control and the convenience of touch ID and face ID with pretty decent security level.

Now naturally there are still concerns, like you being forced by an authority to divulge your password vs. your biometric. So I still advise using Passkey as a second factor. But this brings me to the main focus here, which is things you need to think of, when rolling out Passkeys to consumer scenarios </drumroll>.

Here are important things to consider, and please do add to this list if you feel I missed anything.

Not all consumer scenarios are equal

The word “consumer” can mean many varying degrees of concern. A banking consumer is very different from a HOA member. This is a critical factor to consider how you design your passkey infra. The driving factors behind passkey may be entirely different here. While in the first scenario your driver is security, the second scenario is convenience. Its nice not to have to remember a password right?

Recommendation: Your Passkey architecture is not a one-size-fits-all. Different apps will need to treat the problem differently.

This leads me to the second point.

Your passkey is as secure as the consumer’s iCloud

Historically, there have been breaches that were essentially the customer’s iCloud account being compromised. And by extension your google account. Google and Apple have an unenviable task. They need to offer security while not adding friction for your most non-technical user. This is not an easy task. While FaceID is simply amazing when it comes to scanning your face and creating a unique thumbprint of the user that is more unique than even a thumbprint, reality is, your passkey is just as secure as the customer’s iCloud account.

So if you are an app for whom security is paramount, say a banking app, and you rely on the customer’s passkey as the only authentication factor, a breach of the passkey is a breach of the customer’s banking account. Not good.

Recommendation: Use Passkey as a second factor for sensitive scenarios.

You the admin will get no notification of breach

And this brings me to my next point. In corporate infrastructure, you can build detections and protections that in most (not all) scenarios help you detect breach. This may be as simple as the user raising their hand, or some SIEM flagging a problem. You have step up OAuth scenarios, or risk based conditional access policies that kick in. All these protections are nice, but they have something in common.

The commonality is, you getting a timely notification of a need for better treatment from a security perspective.

This is not possible in consumer passkey scenarios. If someone’s iCloud account gets compromised, you have no way of knowing. Apple will not send you a notification. Same applies for Google. This IMO is a shortcoming of passkeys which gives me pause using passkeys as the only factor in authentication.

A phrase I have heard in reference to passkeys is “Password replacement”. I like that phrase. It is a replacement for one of the factors. You decide which one. In enterprise scenarios where you control the story end to end, it could be your only factor in most scenarios. In consumer, perhaps not.

Recommendation: Same as above, use Passkey as a second factor for sensitive scenarios.

You should maintain a fallback identity.

I do like passkeys but nothing spells vendor lock in better than Passkey. At least your iCloud keychain can be manually copy pasted one by one if you decide to move from iOS to Android or vice versa, what do you do with passkeys? These two clouds do not talk to each other.

The answer, you have to setup your passkey again. Basically a re-registration process, and deprovisioning of the older passkey.

But how do you do that, if you didn’t maintain the ability for the user to prove their identity in a mechanism other than passkey? The answer, you can’t.

In enterprise scenarios, this means a phone call, or a ticket to the IT department. But in consumer scenarios such high touch treatment means the cost is multiplied across the number of users.

The answer, is to maintain a non-passkey identity that is hardened, inconvenient, and sure less secure than passkey, but used as a fallback mechanism when a passkey can absolutely not be used. The benefit being, in 99.9% of login transactions, you remain unphishable when using a passkey. And you get the convenience of biometrics protection. But where that is not possible (such as account reset, account recovery, or where you are in unfriendly territories), you have the option of not using passkey.

Recommendation: Maintain a non-passkey identity

Passkeys can be airdropped and shared or synch to insecure devices

Well, like I said, your passkey is just as secure as your iCloud. And if Apple allows “1111” as your passcode that you can keep for the next 10 years, your passkey is not too secure is it? Similarly, enterprise scenarios allow passkeys airdropping to be disabled. But not so for consumer scenarios. Could someone be socially engineered into sharing their passkey? Sure!

Now this won’t happen over the internet, so this attack won’t scale. But just something to be mindful of, that this is something your app (RP) cannot dictate, that “I shall not accept an airdropped key”.

Closing thoughts

So what are your thoughts on this? Are you rolling out passkeys to consumer scenarios? What other considerations do you have in mind?

Rolling out Passkeys: Consumer and enterprise-ish scenarios was originally published in Winsmarts.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is a non-tech post, but rumination over the rapid progress of AI especially around ChatGPT etc.

Lets be honest, this was eventually going to happen. And if it wasn’t Microsoft and OpenAI, someone else would have forayed into this sooner or later. But this rapid progress in AI has me worried on a few fronts.

Trusting what you see or hear

Generative AI is more and more within the reach of many. Cars were invented, and initially we were afraid of them. 155 years ago, there was the “Red Flag Act” where a self propelled road vehicle had to be preceded by a person at least 60 yards ahead carrying a red flag warning others of the risk. This effectively blocked all innovation in cars since the car had to move at the pace of a person walking. Reminds me of many stupid laws we pass today like the accept cookie nonsense, thanks to GDPR. Eventually we realized this was stupid and grew out of it, it took many years though.

Generative AI has gotten so good that with a few lines of code for free, you can generate pictures of anyone. How far are we from floating very convincing videos of world leaders declaring nuclear wars, or influencing elections, when we cannot tell truth and reality from fake? This has been used in every conflict, such as dropping leaflets from german planes in Dunkirk, or Generative AI being used to create convincing phone calls from a scammer.

How can we trust what we see or hear? And if we cannot, how justified are our reactions to untrustable information? Is this a problem we already face — I’d say yes. Our politicians now flat out lie shamelessly. Our media sources aren’t much better. But its about to get a lot worse, a lot quicker.

Displacement of skills

Economic cycles in controlled capitalism like we have, deem a boom/bust rhythm. Typically we compare this with a fire burning an old forest, so new saplings can grow. The winds of creative destruction replacing horses with cars, so we all benefit, people retool, people reskill, and the society improves. Everyone benefits.

Will that be the case with AI? The fire burning the forest this time around isn’t better skilled people, it is computers. And computers are learning faster than any human can possibly match.

If people cannot reskill fast enough, well you can hope they have access to the benefits of this new technology. For instance, I will never run at 100mph, or fly at 700mph, but I have access to cars and planes.

But what if my access to AI is either stymied, biased, or simply kept out of my reach because of cost?

Impact on society

Now I have heard Sam Altman compare this with calculators. No Sam, this time is different. Undoubtedly calculators made us stupider, but we learnt to use the tool to benefit from it, but absorbing a technology into the psyche of a society takes time. Within weeks of releasing ChatGPT3, we now have ChatGPT4.

And the only people benefiting from that are the ones who already have too much, the silicon valley execs.

Will your average McDonalds worker who takes your order be able to reskill fast enough, when their job is displaced with a human-less McDonalds?

So what do we do with such people on the altar of capitalism? And what alternative do we leave for people who are hungry?

Look, I am a capitalist. But it cannot be a 100% free for all. You raise your kid, enable the kid to be a productive member of the society right? Replace kid with “someone who needs help so they can add to the society”. You invest in education, you distribute rewards, or an unbalanced capitalistic society is deemed to fail.

With the pace at which AI will improve, no human (I mean _no human_) will be able to match these machines. So unless we seriously consider distributing the benefits on AI to everyone, this innovation could rapidly turn as the most unsettling advancement we have ever created.

Hardly anyone will disagree that we are already an imbalanced society. Well it could get a lot more imbalanced very fast, AI will simply catalyze what you see, and very rapidly.

Too few control it

While the original goals behind OpenAI were laudable, it is no longer Open, or Non Profit.

Elon Musk on Twitter: "I'm still confused as to how a non-profit to which I donated ~$100M somehow became a $30B market cap for-profit. If this is legal, why doesn't everyone do it? / Twitter"

I'm still confused as to how a non-profit to which I donated ~$100M somehow became a $30B market cap for-profit. If this is legal, why doesn't everyone do it?

I’m not against anyone making money on an opportunity, but lets be real. You have the very narrow mindset of a few cappucino smartphone toting engineers in a very narrow band on the west coast, making important decisions that affect rest of the world, mostly out of their own judgement. There are sensitive issues I’d rather not touch with a 10 foot pole, but opinions differ on sensitive issues, and everyone is convinced that their opinions are correct.

What is the consequence of concentrating such power in the hands of so few? Forget the fact that at some points we are already making wrong decisions, it will lead to clash of opinions.

Over relying on AI

Samsung S23 Ultra has 100X zoom and they showed off how you can zoom into the moon and take really impressive shots. Until some clever research showed, they were simply replacing the actual moon pixels with images.

However, until this was shown, almost all of us assumed, the zoom was real. Samsung has still not commented on it.

And you have some very valid points being raised around, if we are manipulating pixels anyway, why is this wrong? After all, Google has “Magic Eraser” on Pixel phones, but is that photo real?

Leaving that debate aside around what is real or not. When the recipient sees that photo, they assume its real.

But we know it is not always perfect. But it is so close to perfect that as humans we fail to understand risk.

A perfect example of Tesla Autopilot. The word “Autopilot” leads you to believe, it is hands off, go take a nap, and has been promised as “just around the corner” by none other than Elon Musk since 2012. Heck I paid for Autopilot in 2015, and it is still nowhere close to hands off.

BUT undeniably, it has gotten better, a LOT better. It was 5% bad when I tried it, now it is 0.1% bad. Very impressive. And they’ll raise it to 0.01% too. But what happens when you are a good candidate for 0.01% — well you die.

Now don’t tell me this is not a real concern. Accidents do happen because people over pivot on their confidence in AI.

There will always be stupid people, putting _others_ lives at risk.

How much longer before weapons use AI to make kill no kill decisions? And are we sure, given the advantage they offer in the battlefield, that some hot headed general or overzealous contractor, isn’t already doing this, and we just don’t know about it?

Summary

This feels like a losing battle. As humans we will always be wowed by the next shiny thing. It is with experience as a society that we learn there are pros and cons for everything. Your smartphone lets you do you so much but is also a digital leash. Your car lets you move at 100mph, but is also a killing machine in the wrong hands. A passenger jet is marvelous, but also can cause germs to spread globally very quickly.

It is with experience that we learn to tame innovation, reduce the risks, improve the outcome for the society as a whole.

At the pace AI is moving forward, it is outpacing our ability as a society to tame this innovation.

I’m worried, I hope I am wrong.

Thoughts on ChatGPT and AI was originally published in Winsmarts.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

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 

Passkeys and Enterprise Authentication was originally published in Winsmarts.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

The first thing you need to know is the concept of v1 endpoint vs. v2 endpoint. V1 is older of course, but v2 is OIDC compliant. And our newer SDKs (and recommended path) is to target the newer v2 endpoint. Why is that important?

Because the older library, ADAL (Microsoft.IdentityModel.Clients.ActiveDirectory) targets the v1 endpoint. In fact, ADAL is being deprecated. Your existing ADAL apps will not stop working, but starting June 30th, 2020, Microsoft is not adding any new features to ADAL. You should strongly consider updating to MSAL.

But then we have many other libraries, AppAuth, Azure.Identity, Microsoft.Identity.Web, where do they fit in?

Microsoft.Azure.Services.AppAuthentication enables S2S communication using OAuth 2.0 client credentials grant, and it depends on ADAL. Since it depends on ADAL, you should consider moving away from it.

Azure.Identity is great for using Managed Identity and is available not just for .NET but many platforms, in a very similar and well thought out programming paradigm. Managed Identity is a service principal whose credentials you don’t have to manage, and it does not have a backing app registration. You must always prefer to use a MI, vs. a SP whose credential you have to manage. There are still borderline scenarios where SP with a known credential is necessary but those are far and few in between. Azure.Identity, takes a dependency on MSAL. It is worth mentioning that both MI and SP target app permissions, and .default scope is a convenient shorthand for requesting all scopes your app is pre-consented to. So you would generally use MI/SP with a scope such as https://graph.microsoft.com/.default

MSAL.NET or Microsoft.Identity.Client is the .NET version of the Microsoft authentication library, and it targets the v2 endpoint. You should use this. In fact, there is a family of platform specific MSALs

Microsoft.Identity.Web is a higher level abstraction on top of MSAL, which makes using common identity scenarios in ASPNET a whole lot easier. Now this raises an interesting question. When should I use Microsoft.Identity.Web and when should I use MSAL.NET directly? I am going to steal this amazing flowchart, but also encourage you to read this article here.

One last thought,

1. You should always prefer to use a Microsoft SDK if available for a platform
2. If a SDK is not available, you should prefer to use a standard OIDC complaint SDK
3. And finally, as a last resort, you should target the OIDC spec.

Hope this helps.

Demystifying Microsoft Identity SDKs was originally published in Winsmarts.com on Medium, where people are continuing the conversation by highlighting and responding to this story.