Security is a rapidly moving field, which makes it fun to keep up with, in the same way, that running on a treadmill can be fun. At the same time, though, parts of the security space change at a more deliberate pace. One example of an area that’s been pretty slow to change is user authentication. Since it’s nearly Halloween as I write this, let me tell you a bone-chilling ghost story. 

The concept of reusable user-specific passwords dates back to the work of a computer scientist named Fernando Corbató, who introduced passwords as a way to provide security in an early multi-user operating system called CTSS. Ever since then, users, admins, and security people have been complaining about the many problems inherent in reusable passwords; even Dr. Corbató called them “a nightmare” in 2014. The scary part: This 2012 WIRED Magazine article talks about the first known instance of password theft… in 1962! Sixty years of password theft is enough to make anyone’s blood run cold. Just imagine what the good doctor would think if he were still alive to see the state of user authentication today and the horrors that have arisen from his legacy. 

What Horrors, You Ask? 

There are lots of problems with passwords in the modern cloud-based world. To pick just three: 

  • People are generally bad at remembering arbitrary strings, so users often pick weak or easy-to-guess passwords, or pick one strong password and use it in lots of places. 
  • Developers have to be careful in how they process and store passwords so that they can’t be “cracked” from stored hashes or other data– a problem made much more difficult by today’s super-powerful GPUs, which can test billions of password hashes per second. 
  • Attackers have gotten better and better at social engineering and phishing as a way to capture user passwords. 

But MFA Will Protect Me, Right? 

In the same way that small children think that parental intervention can scare away monsters under the bed, there have been lots of attempts to solve the problems of reusable passwords, almost all of which revolve around adding an additional authentication factor. That’s where the name “multi-factor authentication” came into play. The idea behind MFA is that, even if an attacker can steal or crack a password, there’s still another authentication test that only the legitimate user can pass. MFA first became common with hardware tokens from SecurID, RSA Data Security, and other vendors, then moved to SMS-based codes, and is now evolving into notification-based MFA through Microsoft Authenticator or other applications. 

MFA isn’t perfect, though. Its security is only as good as the additional authentication factor you use. SMS has long been known to be vulnerable to various types of attacks, and, as we saw with the recent attacks against Uber and Rockstar Games, simple attacks that just spam users with repeated prompts will sometimes succeed. The underlying problem with MFA is that it’s used in addition to a password—so an attacker who can steal or guess the password has effectively removed the “M” in “MFA”.  

Now, a brief public service announcement: if you don’t already have some kind of MFA enabled on your own accounts, stop reading this and go do it now. Netflix, Facebook, Twitter, your Microsoft account, Apple, Google, your bank, and your cell provider all support MFA (as do many, many other applications) and you should enable MFA everywhere you can, immediately. It’s better to have MFA even with relatively weak SMS protection than not to have it at all. For bonus points, help a less-technical family member or neighbor get MFA enabled on their accounts too. Now, back to our regular program. 

A Better Anti-Ghost Mechanism? 

The latest industry solution is to push for switching all authentication over to a method known as passkeys. These aren’t new, they’re the consumerized version of the existing FIDO Alliance standards for authentication, which you might already be using. The difference is that Microsoft, Apple, and Google have agreed to follow a common standard for naming, registration, and handling of these credentials, making it much more likely that they’ll be widely adopted.  

If you’re not already using FIDO-based authentication, you should strongly consider it. In many respects, FIDO’s similar to certificate-based authentication, but for user accounts and not services. The FIDO standard (explained pretty well here) calls for creating a unique public/private key pair for each connection between a specific device and a specific service. That is, you’d have one key pair for logging into Microsoft 365 from your iPhone and a second, completely separate one for logging in from a FIDO USB security key. The private key may be protected with a strong biometric protector on a device, such as the Apple Secure Enclave or Samsung Knox mechanism, or available only after the user makes a “user gesture” of some kind (such as entering a PIN or pressing a dedicated hardware button). The FIDO Alliance website explains a passkey’s use like this: 

When a user is asked to sign-in to an app or website, the user approves the sign-in with the same biometric or PIN that the user has to unlock the device (phone, computer or security key). The app or website can use this mechanism instead of the traditional (and insecure) username and password.   

FIDO Alliance

The actual sign-in takes place when the user requests access to a service: the service sends a challenge to the user device, which requires the device to respond using the private key associated with that service’s previously registered FIDO credential. Signing the challenge using the private key requires the user to unlock it as described above. When the service sees a correct response to its challenge, it logs the user in. Notice that at no point is a password involved—meaning that there is no password to store, leak, be stolen, or for the user to write down or share. The genius of this approach is that there’s also no separate MFA gesture. The first authentication factor is “can the user unlock the device” and the second is “can the device respond appropriately to the challenge”. 

Moving Forward With Passkeys

The good news is that you can start using passkeys right now with your Microsoft 365 accounts. You wouldn’t know it from Microsoft’s documentation, which refers only to “passwordless” authentication. However, it’s simple to set this up using either Microsoft Authenticator or an actual FIDO2 security key. There are still some pitfalls; not every service that supports MFA completely supports passkeys, and Windows support for using passkeys on multiple devices still isn’t fully available. The very useful passkeys.io site has a demo that lets you test how passkey authentication works with your particular device, plus a chart showing you which capabilities various versions of Chrome, Edge, Windows, macOS, iOS, and Android support. I encourage you to set up a test device and a test account and start thinking through, and testing, authentication scenarios for your most important use cases. I’d recommend starting with providing better security for privileged accounts, then for the users who are at the highest risk of a phishing or spearphishing attack. The additional security that passkeys can offer will help keep the restless ghost of Dr. Corbató away from your enterprise network and make your users and services more secure. 

Join Paul Robichaux and other Microsoft experts at The Experts Conference 2022, December 6-7.

100% Free and Virtual. Get world-class AD and Office 365 training, plus earn 10 CPE credits.

Learn More

About the Author

Paul Robichaux

Paul Robichaux, an Office Apps and Services MVP since 2002, works as the senior director of product management at Keepit, spending his time helping to make awesome data protection solutions for the multi-cloud world we’re all living in. Paul's unique background includes stints writing Space Shuttle payload software in FORTRAN, developing cryptographic software for the US National Security Agency, helping giant companies deploy Office 365 to their worldwide users, and writing about and presenting on Microsoft’s software and server products. Paul’s an avid (but slow) triathlete, an instrument-rated private pilot, and an occasional blogger (at http://www.paulrobichaux.com) and Tweeter (@paulrobichaux).

Leave a Reply