Navigating the ever-evolving authentication landscape

My amazing 2022 moment was an opportunity to work with a professional creative team to keynote the FIDO Authenticate conference in October. This blog post is a slightly edited version of the keynote I delivered, it was so much fun to create (thanks to Nadine Kano , Ryan Calafato and Jason Snavlin )! You can also see the original recording at the Authenticate website (registration is required).

Ahoy there! Gather round, stalwart seafarers, masters of domain (controllers) and destiny, and I’ll spin you a yarn. As the captain of your organizational ship, you’re steering through a sea of regulatory whitecaps while increasingly destructive security monsters rock your vessel. Some of you may be admirals of a whole fleet!

As you chart your course of implementation and adoption through ever more dangerous and unpredictable waters, you must keep your ship with its precious passengers and cargo safe. How do you determine the best way forward? And how can we seafarers develop a more collaborative approach to the broader set of potential threats above and below to make all voyages safer?

At Microsoft, we’ve repelled attacks across the seven seas, on our allies’ ships and our own. Given the trillions of signals we analyze every day, we’re often among the first to see new threats on the horizon. So, gather close me hearties as we explore our current identity security waters in 2022:

Password attacks: opportunistic attacks on passengers

The number one rule for any voyage is: “Keep your passengers on the boat.” If you’ve ever watched anyone on a cruise ship buried in their phone as they walk toward the rail, you know that’s not as easy as it sounds. Your passengers aren’t identity security master-mariners, so they face an enormous risk from password-based attacks that may send them overboard with nothing to hang on to.

Password attacks cost nothing to perform, so we see a lot of them. In fact, as of October 2022, Microsoft blocks 1,287 password attacks every second* across our platform. Such attacks succeed because our passengers are human. Password attacks rely on statistically predictable human behaviors to yield statistically predictable results:

• Breach replay, aka credential stuffing. Passwords are hard to remember, so passengers reuse them. Once attackers crack a password on a low-security site, they replay the same password on your high-security login page.
• Password spray. Since passwords are hard to remember, people pick ones that are memorable but also easy to guess. Complexity and expiry rules make this much worse—they pretty much guarantee attackers just need to try “Fall2022!” against all your users until they find a match—and they will find a match.
• Phishing. Passengers aren’t trained to spot subtle anomalies such as misspelled domain names. Emails or text messages can fool them into giving their passwords away on attacker-controlled websites.

Common passenger behaviors create an attacker’s paradise, so you have to save your passengers (who may ignore your warnings because they don’t understand the danger) from themselves. The simplest practice is to put them in lifejackets, that is, to enforce multi-factor authentication (MFA). Is it fancy? No, but it does get results.

Anything that floats will do. Even simple factors like SMS, one-time passcodes, or voice protection can drastically reduce a passenger’s risk of account compromise. More than 99.9% of compromised accounts lacked MFA.This can be a big job, but you can use granular policies to make it easier. For example, consider protecting the administrators on your crew first, and then enroll others according to their risk profile.

You can find a detailed breakdown of statistics and attacker approaches to password attacks in Your Pa$$word doesn't matter by Alex Weinert.

MFA attacks: targeted attacks on MFA credentials

Passengers falling overboard is your biggest problem, but it’s not your only problem. When it comes to opportunistic attacks, you don’t have to sail faster than the pirates, you just need to out-sail vessels that don’t turn on MFA. Targeted attacks are a different matter. They’re harder to execute, but it’s worth a pirate’s time and treasure to try to swipe passengers off the deck of an attractive diplomatic vessel.

For example, some second factors are vulnerable to MFA phishing attacks:

• SIM Jacking. A pirate fools a telephone provider into assigning them a passenger’s phone number, then intercepts second factor authentication messages sent via SMS.
• Adversary in the middle. Pirates capture both first and second factor credentials using a fancy version of phishing, tricking your passengers into authenticating on behalf of the attacker with their MFA factor. They get them to walk the plank, then take off their lifejacket as they hit the water!
• MFA fatigue. Pirates barrage a passenger with push notification MFA approval requests, hoping they’ll eventually click that approve button, either accidentally or to make the notifications stop. Our tests show that one percent of passengers will approve an unsolicited simple approval on the first try!

MFA attacks are a tiny fraction of the attacks we see today, but we know the attacker world is collaborating to make them easier to execute. This is where phishing-resistant credentials come in, and where we as an industry can really improve on lifejackets that won’t help passengers unless they are worn and buckled correctly.

You can find a detailed breakdown of statistics and attacker approaches to MFA credential attacks in All Your Creds Are Belong to Us by Alex Weinert.

Countering MFA attacks with recoverable, phishing-resistant credentials

Phishing-resistant credentials go a long way towards keeping your passengers safe by making it impossible for them to provide credentials to a phishing site. FIDO credentials, for example, employ a user gesture, such as a PIN or fingerprint, to unlock a private key unique to a specific internet domain. There’s nothing a user can do to unlock a website’s private key from the wrong domain because the user’s FIDO2 cryptographic sign-in credentials are strongly associated to a specific internet domain when registered, and the platform makes sure they can only be used to that same domain.

This approach is great for security, but phishing-resistant credentials still need lifecycle management, including recovery mechanisms. While enterprises already have workflows for self-service recovery of accounts in case disaster strikes, this is much harder to do for consumer websites, where security may not be a first concern.

We all love passengers who memorize safety instructions, show up first for safety drills, follow the guidelines, and voluntarily associate three kinds of multifactor authentication with their personal accounts. But how many people—outside of security experts—actually do this?

Because we also need to protect everyone else, the FIDO Alliance has defined both single-device and multi-device FIDO credentials, commonly called passkeys. The north star of single-device FIDO credentials is that the private key never leaves the device. Single-device FIDO credentials tightly manage the provenance of a credential’s private key. Examples of single-device FIDO credentials include FIDO2 security keys and Windows Hello. Multi-device FIDO credentials offer more freedom in private key management, making it possible for the user’s device platform to take on much of the responsibility for recovery scenarios. For consumers, this is a game changer. In everyday authentication use cases, you can ask passengers for either of these types of passkeys. In the future, for higher assurance use cases, you’ll be able to request passkeys with an extension called a Device Public Key (or DPK) or just continue using single-device credentials.

But let’s be real. Expecting our passengers to understand the intricacies of multi-device vs single-device FIDO credentials won’t get us where we need to go. Unlike crew members, passengers don’t want to think about ship safety. They just want to work on their tan.

In a perfect world, safe authentication behaviors should be effortless, if not mindless. Fortunately, we can deliver a user experience that’s both simple and ubiquitous: passengers use the same gesture they perform to unlock their personal device to unlock access to their internet applications, and if a shark eats their phone, they can get a new one, sync their credential from the cloud, and go on their merry way.

We can make the user experience intuitive across all use cases while we innovate and collaborate to tighten security and iron out edge cases. Passkeys can become the seat cushion that turns into a flotation device, or a fancy gown that inflates automatically when you drunkenly tip over the railing. And we’ll have a real chance of mainstream adoption, because the most secure option will also be the most convenient. 

You can start investigating passkeys today at passkeys.dev. 

Post-authentication attacks: attacks on sessions, tokens, and approvals

The tactics described above can help you keep passengers safe and out of the water, but you also need to keep water out of the boat. Post-authentication attacks are akin to an oncoming storm threatening to drown your passengers and sink all your cargo. In these cases, attackers aren’t impersonating passengers, they’re trying to puncture your hull by working around the authentication process or by co-opting applications.

• Token Theft involves stealing a token created on a legitimate, fully secure device and moving it to an unknown device under a hacker’s control.
• Consent phishing fools people into sharing excessive information when they’re not paying attention.

Attackers may also search source code repositories for OAuth tokens and other nonhuman credentials that developers have accidentally checked into their code, or they may launch a compound attack by compromising an unprivileged passenger and then scanning internal private code repositories for OAuth tokens.

The industry has been working on ways to batten down the hatches with endpoint management solutions and tools for identifying overprivileged accounts. We’re also working on longer-term mechanisms, such as attaching proof-of-possession to tokens and token revocation based on risk.

The good news is that because these attacks are thefts of scoped access, we can revoke that access when we figure out something’s wrong. And because we’re getting better at detection and faster at revocation, we can weather the storm—for now.

But there’s one more danger in the deep.

Infrastructure attacks: compromising federation servers and other identity infrastructure

When we least want or expect comes the kraken, a creature that can reduce your vessel to toothpicks and drag your business to a watery grave. This ferocious beastie uses many of the techniques already discussed, but it also uses even deeper techniques—executed by teams of professionals with sophisticated operations—to compromise and control the infrastructure that secures authentication.

While password attacks are an often-detectable “smash and grab,” identity infrastructure compromise allows the kraken to sit in your environment and conduct covert operations for the long haul. In other words, it grabs hold of your boat from underneath and slowly crushes it.

If an attacker can impersonate a passenger, that’s bad. If an attacker can compromise the mechanism that issues valid tokens, that’s worse. When an attacker can body snatch any valid user, your only hope of survival is to detect an anomalous use pattern. If you don’t notice, the consequences for your vessel—and all other vessels in your fleet—are dire. Even if the kraken doesn’t take you down directly, it may still take down boats operated by your supply chains and partners.

The kraken can take the form of a nation state or criminal organization. These attacks require vast resources because they must be silent. Nation-states often start with a password attack and follow up with attacks that are much harder to detect. They use identity infrastructure compromise to do some pretty terrifying things, not only to your passengers, but also to the federation servers in your engine room:

• Token forgery attacks are the worst by far. An on-premises compromise of a federation server might occur silently but result in a copy of the federation server’s private signing key being moved out of the organization and onto a server under attacker control. The attackers would then have the power to begin forging tokens that are completely valid as far as the existing federation trust is concerned. If they’re lucky, they can parlay that forged token into control of a privileged administrator in the cloud.
• Attackers may compromise a privileged cloud user using more traditional methods, but then add new federation contracts. Where once there was a single federation trust, there are now two, and now the attacker doesn’t have to worry about on-premises key rotation. Admins may even look at their federated trusts but not notice that someone else is proxying assertions into their organization.
• Attackers may go into the settings of perfectly legitimate nonhuman workload identities, such as service principals or scripts, and make almost-invisible changes, sometimes with two or three layers of misdirection in between. They may promote a known service principal into a global domain administrator for 30 seconds, leaving the perfectly innocent workload unmolested but adding a second keypair to the credential list. The workload can still authenticate and do its business, but the attacker can also authenticate—and reap the data.

For real-world examples of indicators of identity infrastructure compromise published by Microsoft, please visit our Solorigate IOCs blog entry. 

Defeating the kraken

So, what can we do to defeat a devious and unseen enemy that waits in the deep until it pounces? To bring down a kraken, we have to coordinate and collaborate. We have to form an armada and scour the waters, watching for disturbances not only near our own vessels, but also near all the vessels in the larger fleet.

This problem is so critical that it has, just in the last year, given rise to an entirely new subcategory in identity security: identity threat detection and response (ITDR). The intent behind this category is to bring together best practices and tools that can strengthen identity protection and more effectively prevent identity compromise.

Emerging standards will play a huge part in making vessels strong enough to withstand even the kraken.

• Shared signals allow collaborating vessels to perform near-real-time session management and restrict access across a federated environment the moment one of the vessels in the fleet spies the tentacled sea devil.
• Coordinated provisioning, such as SCIM, removes gaps the kraken may squeeze through, such as forgotten accounts that should have been deprovisioned.
• Beyond standards, analytics and risk detection act like depth sounders, finding anomalies and ringing the alarm so that response can begin immediately.

At Microsoft, we’ve been tracking these types of attacks very closely, and we’re excited to work with the industry on practices we think will improve the situation. We’re innovating to help our customers deal with the kraken by adding new capabilities to our family of identity and access products, Microsoft Entra, including Microsoft Entra Permissions Management, which performs anomaly detection and risk reduction across cloud platforms, and Microsoft Entra Workload Identities, which helps to manage non-human identities.

And of course, we’re still dedicated to enhancing the identity protection and risk detection characteristics that exist in Microsoft Azure Active Directory, part of Microsoft Entra, so we can collaborate across our platforms to find signals about user and sign-in risk and other anomalous activity. Just announced are new features to help with MFA fatigue and new granular policies to get that floating evening wear in the hands of your highest impact passengers.

Microsoft is committed to working towards successful mainstream deployment of passkeys. But we still love single-device credentials, so not to worry, we’ll let administrators decide which combination of single and multi-device FIDO credentials works best.

Where do we go from here?

Even if we can keep the kraken at bay, we’re sailing into the great unknown. We know there will be monsters, and we believe communications is the best way to stay ahead of them. We need more communications between crews on vessels, and more collaboration between vessels. We need to share identity-specific indicators of compromise, work on posture management, and improve our structural integrity in areas such as secrets management. We need identity teams and security teams to talk more often. If we do this right, our efforts will contribute to an evolution in how we defend ourselves against the perils of our journeys—seen and unseen.

And if you take anything away from my wizened tale, me hearties, let it be this:

1. Get lifejackets on people. Work on the highest impact passengers first. Out of every 10,000 compromises we see, only one has MFA turned on. Think about that.
2. Batten down your secrets. Find tokens stored in code, remove them, and convince the developers on your crew to avoid checking secrets into their code. Monitor the credentials set by your service principals, scripts, and OAuth Client IDs.
3. Don’t ignore the kraken. Watch your federated trusts. If you use Azure AD, you can run a Sensitive Operations Report to watch for suspicious changes to your infrastructure. Identify which anomaly detection you have now and figure out what else you need.

If you're a mariner, you know the value of telling tales of woe. Tell your tales loud and proud so we can all share your wisdom.

And don’t forget put on your own lifejacket before you assist others!

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.

* Source: Microsoft Azure AD authentication log data.