Understanding the passwordless authentication renaissance and how to plan your Microsoft Windows based organization for this change – PART 1

renaissance
a period of high artistic or cultural development

At the cusp of a new decade, we are now firmly in the renaissance of passwordless authentication.  Passwordless authentication has been around for many years but is only now in a form where enterprises can easily consume and deploy it for their users in modern computing settings leading to increased user happiness rather than the user friction we have seen with legacy password-based or legacy passwordless authentication mechanisms we may have deployed over the years. 

We are now in a renaissance, a period of identity and access management development and progression in both the enterprise and consumer world that none of us have experienced before.  It is so extremely positive to be a part of this change but without an understanding of how we got here and where we’re going, it’s hard for CISOs, Architects, Engineers, and other IT professionals to understand and plan for the cultural and functional change for your Microsoft based environment.  Over the course of 2 articles, I will attempt to help you understand and plan how to drive your Microsoft Windows-based environment forward with modern Microsoft passwordless authentication solutions.

The fine line between user experience and security

As time went on I kept that knife set with me and it was used increasingly.  The most often used knife became the 8″ chefs knife in that set.  I attempted to sharpen that chef’s knife over the years but cheap steel doesn’t hold an edge very well or for very long.  I didn’t realize how bad it was until I observed someone else struggling with that knife sawing away at a carrot as if it was a piece of lumber!  The carrot wasn’t being sliced, but instead smashed down and ripped by the dull knife.  It was not a great user experience anymore and the knife was performing poorly causing the end result to be almost unusable, a smushed carrot.

I purchased a well-rated chef’s knife from Amazon.  It cut so finely I could make curly Qs cutting thin slices of paper as if I was whittling wood! I took my old dull chef’s knife and held it in the air against the light with one eye closed.  Then I did the same with the new razor-sharp chef’s knife.  I saw the reason why the dull knife was underperforming immediately.  The edge of the dull knife was almost completely flat.  There was no bevel in the knife at all.  When I looked at the new knife I couldn’t even see the bevel between both of its sides.  The line was so fine it was almost invisible!

If you let the fine line between user experience and security dull, it will underperform and cause friction on both sides, i.e. your users and within your IT organization.  If you attempt to avoid this situation by maintaining your knife by sharpening it you must be careful that the bevel does not get ground down too much on one side and cause the metal to fold-over causing a dull edge as well.  Much like how we maintain and upgrade our IT systems if you give security or user experience a little too much over the other, it too will cause friction and not perform as well as you want.  The almost invisible fine line all kitchen knives strive to maintain is the fine line between user experience and security in the enterprise world we have to maintain.  You just want something that performs and gives an excellent user experience while keeping the environment very secure.

You always want to make sure you balance user experience and security properly with every system you deploy so users actually use your service but have no idea how extremely securely it is.  And you don’t do it just once, you constantly evaluate and maintain that fine line as the enterprise changes.  Modern enterprise security should be invisible to end-users because the user experience is just that good.  It’s our responsibility to walk that line and maintain it for the enterprise organizations we work for.

The fine line between user experience and security is like the edge of a sharp kitchen knife. Maintain that fine line and it’s a delight to use.

How did we get here?

Passwords have been around since the dawn of humans, it’s not a construct of the digital age.  For example, in ancient times passwords were a way to gain entrance into an area.  You were challenged by a guard to know the password and you were required to say it to prove you were someone that was allowed entry.  This concept carried on into the computing age.

We quickly found that user ID + password was a security nightmare.  We began implementing two-factor authentication (2FA) and multi-factor authentication (MFA) to overcome some of the challenges but it still left many issues unanswered such as password resets, password theft, password re-use and a slew of others.

We began to understand that we needed passwordless solutions.  So we began deploying certificates (X.509 certificates) to act as a form of encrypted credentials and prove our devices and users were authorized to access the network.  This proved to be cumbersome and did not translate well into the mobile age.  The Microsoft Windows OS was the fundamental enabler for this back during the Windows GINA (graphical identification and authentication) days.  Back then you had 2 choices, you can login with your user ID + password or you could use a smart card to SSO in without a password.  Smart cards were able to adhere to requirements of PIV (Personal Identity Verification) as per FIPS 201 (Federal Information Processing Standard Publication 201) developed by NIST (National Institute of Standards and Technology) and the military CAC (Common Access Cards).  Later, the HSPD-12 (Homeland Security Presidential Directive 12) in 2004 resulted in the FIPS 201 PIV II specification in 2005 which superseded the original PIV specification by 2013.  In a nutshell, a smart card is just a piece of plastic with an integrated chip holding a certificate built on the back of your PKI (public key infrastructure, i.e. Microsoft Certificate Authority) and a PIN that the user can set and has to memorize in order to “unlock” the card.  This allows the usage of the private key with the certificate on the smart card so it can be used for authentication.  This satisfied 2 factors, something you have (the card) and something you know (the PIN). However, they were very inflexible in what you could do with them which is why the military introduced a “next-generation” CAC.  Now the Defense Information Systems Agency (DISA) is in the process of figuring out how to move away from CAC smart cards completely by using biometrics for identity verification and authentication instead. 

United States Department of Defense (DoD) CAC (Common Access Card) smart card.  An integrated circuit chip (ICC – the exposed copper-colored square) allows you to insert into a reader allowing SSO into Microsoft Windows without needing to use a password.  Smart cards can be used as identification badges allowing for both physical premises facilities access with RFID readers and digital systems access using the integrated circuit chip.

Some enterprise organizations who could afford the financial and operational overheard of smart cards began to deploy them for their users.  After all, it was the only way Microsoft would allow you to SSO into Windows without using a password as of Windows 98 and Windows NT 4.0 (Windows 95 too but with a lot of work).  It was the first foray into passwordless authentication.  Enterprises began to see over time that smart cards weren’t a perfect solution as the way end-users began to compute changed from physical desktops or laptops with smart card readers to thin laptops, tablets, and mobile phones that didn’t support smart cards.  Smart cards became inflexible and while it worked for the military, could not meet business expectations of civilian enterprise users who were more consumer-oriented than the more stringent computing expectations of the military.  Some smart card-based organizations started buying expensive Thursby cases and using Derived Credentials to enabled a password-less experience for users to help the mobile use case along. NIST started supporting this direction in 2014. In many enterprises, this was not an ideal fit. In fact, it was debilitating trying to fund and manage some of these projects.  Companies were just going deeper into the rabbit hole and needed Microsoft to come up with a different way to authenticate with Windows. Microsoft Virtual Smart Card was introduced with Windows 8 and Server 2012 onward for better flexibility but still had operational overhead.

In some enterprises like healthcare organizations where login speed was critical and needed tap-and-go type capability from patient room to patient room, we saw 3rd party solutions attempt to mimic a user login.  A  quasi “passwordless” single sign-on experience if you will by using a helper agent.  They almost always relied upon a trick to get Windows to think you were using a physical smart card or mimicking the user’s login using credential vaulting since the Windows OS really understood only 2 things, username + password or a smart card cert. Healthcare organizations used Imprivata and Caradigm for this tap and go proximity-based authentication. We used agents to get around Windows authentication to introduce biometric authentication in the form of fingerprints, palmprints, retinas, and more as long as the readers and intermediary software supported them.

There were 2 problems with this approach.  Many of these solutions locked you in.  They locked you into a licensing model and a rather crippling update posture. Because it wasn’t natively part of Windows, you couldn’t update various other items on the Windows OS because it would break the client doing this “trick” to allow for authentication. Many enterprises were forced to have to remain in a legacy state until the vendor came up with an update. Then you would have to worry about rolling the update out throughout your environment. It was a hassle for enterprises but it was necessary for the business to function. I’ve walked into healthcare organizations and just stared at the legacy Citrix Receiver version they had on their clients wide-eyed. And the only reason for that legacy user experience was for authentication to continue working. That’s not a way to run a business. Access management should never become a hindrance in your environment, it should be an enabler.

Meanwhile, the great majority of enterprises continued using the familiar user ID + password.  Just add an MFA solution as a 2nd factor and that would help tremendously.  And it still does today.  I have deployed every MFA solution under the sun throughout my career.  We saw Microsoft purchase PhoneFactor in 2012 and watched it become part of Azure by integrating with the Classic portal.  Then we saw Microsoft transform and productize it into Azure Multifactor Authentication (MFA) using the Microsoft Authenticator app.  Now users could use SMS, TOTP, push notifications, 3rd party OATH tokens, etc. as their 2nd factor which lead to a lot of flexibility.  Then the move to ARM front and center as part of Microsoft’s greater identity platform in Azure AD where it belongs. We saw the many flavors over the years and the deployments go from on-prem MFA Server in a hybrid model to using the cloud service itself completely. We saw the rise of the Azure MFA service in the cloud itself eventually becoming more flexible than the Azure MFA on-prem server. We saw the rise of the Azure MFA NPS Server extension to handle our legacy RADIUS appliances and the advent of the Azure MFA adapter in AD FS 3.0, 4.0, and 2019 so we could leverage SAML 2.0 (or OAuth 2.0 if that’s your preference). 

But over time we started seeing SMS was a vector of exploitation. Even the biggest banks were using this when NIST released their new guidance in draft form in 2016 saying to not use SMS based 2FA but instead look to use the trusty TOTP (time-based one-time passcodes) from the old RFC 6238 or other one-time use solutions.  This was lest evident in the finalized NIST Special Publication 800-63B guidance from 2017 but enterprises had already heard the message and were concerned about using SMS.  OTP and TOTP was still much less likely to be attacked using an interception or replay technique.  Some organizations began disabling SMS and forcing users to use TOTP or push notification in response. 

And then the big step forward by Microsoft.  They realized the need for a new credential provider.  Something that doesn’t use user ID + password.  Something more flexible than physical smart cards or virtual smart cards.  They needed to develop a new credential provider for Microsoft Windows that was passwordless and Windows 10 was going to be the enabler for this.  That could prove the identity of a user with greater flexibility than before.  And so the concepts of Windows Hello and Passport were born that used a public/private key pair that was trusted.  This combination grew into what we know as Windows Hello for Business today. 

To fully round out the new passwordless identity platform, Azure MFA evolved from being a secondary authentication mechanism to a primary passwordless authentication mechanism using Microsoft Authenticator itself.  It was a shift in focus off of Azure MFA, where Microsoft Authenticator itself is now the focus that creates the human trust between user and device, and less focus the back-end services in Azure AD that run it.  Microsoft Authenticator is the user facing part of this access management flow so it made sense.  Azure MFA is becoming transparent this way and further integrated into Azure AD as a core service that helps to provide the various multi-factor authentication factors with Microsoft Authenticator passwordless phone sign-in capability now leading the charge.

Microsoft began working beyond it’s own walls and began to better the industry through the FIDO Alliance.  A partnership between companies to push an open standard for passwordless authentication.  I explained what the FIDO Alliance is and why you should care here:  https://www.jasonsamuel.com/2019/09/18/how-to-enable-fido2-password-less-authentication-with-microsoft-azure-ad-for-use-with-windows-10-and-saas-web-apps/#What_is_the_FIDO_Alliance_and_why_should_I_trust_them 

There’s a big push for Azure Active Directory (AAD) and all Microsoft passwordless solutions to be FIDO2 compliant.  The options to login to the Windows 10 system continue to advance to support any type of device and domain join status making it even easier to deploy no matter what your organization’s current Windows identity and access management maturity is.  It’s quickly becoming just a checkbox to turn on and at some point will just be the out of the box default for Windows as we move into the future.

Where are we going?

It’s time to re-evaluate where you are in your modern passwordless authentication journey and seriously plan how to execute in 2020 and beyond or you’ll be left behind. I can’t tell you how many times I go into a customer and have to deal with locked out user accounts and standing up SSPRs (self-service password reset) to help alleviate the legacy password based issues that have made passwords such an IT Service Desk nightmare. 

I’d say over the last 3 years or so the interest in Windows Hello for Business has really helped organizations think more along the lines of achieving a password-less future for their users. If you can go into Best Buy and purchase a high-end laptop with a fingerprint reader and Windows 10 can identify your finger as a credential and sign you in using the consumer flavor of Windows Hello, why couldn’t we do the same in our enterprises? In my opinion, this demand came from the consumer side more so than the enterprise side and I’m happily welcoming it.  It was user-driven and people-centric.  They demanded it and Enterprise IT delivers it.  From around 2017 onward I saw a great many asks from organizations I work with to help get it deployed and have assisted them in these projects over the years.  In 2020 I expect this number to grow exponentially now as Microsoft’s passwordless solutions are entering greater maturity and the industry as a whole is embracing passwordless computing as a standard.

As long as you use a Windows computing environment, you always have to rely on Microsoft to set the standard here. And it’s been set now. The future of authentication for Microsoft Windows-based enterprises is a combination of 3 password-less authentication mechanisms:

1. Windows Hello for Business – Satisfies authentication to physical Windows desktops and laptops that belong to your organization.
2. Microsoft Authenticator passwordless sign-in – as long as the user enrolls in Azure MFA and does device registration against the Azure AD tenant (not to be confused with device enrollment with Intune), this becomes a strong credential in a “digital” form factor that can prove you are who you say you are to the system you are logging into, even when that system may be a remote one. This satisfies authentication requirements for mobile devices (iOS, Android), BYOD devices (Windows, Mac, Chromebooks, etc.), SaaS web apps, remoting protocol level access such as Citrix Virtual Apps and Desktops, VMware Horizon, Microsoft WVD, etc. and replaces hardware OATH tokens, smart cards, or any legacy TOTP solutions.
3. FIDO2 compliant hardware security keys – Satisfies the need for a “physical” form factor for authentication other than a smartphone.  It has many of the same benefits I described above with Microsoft Authenticator but is a standalone out-of-band authentication device.  Keep in mind not to confuse FIDO2 with FIDO U2F. The FIDO2 standard can support password-less auth while the older FIDO U2F standard cannot.

Join me tomorrow for Part 2 of this article where I will cover these 3 solutions in more technical depth to help you plan your deployments as well as some real-world experience from the field that may help save you some research and development time in your organization’s passwordless journey.