Summary: The time and effort spent on defensive domain registration would be better invested in writing phishing-resistant authentication policies.

Today I want to make the case that registering domains for the sole purpose of protecting against phishing is tackling the phishing problem from the wrong angle. It is, to use a very British idiom, a “mug’s game”: an effort that’s unlikely to yield much success. Most organizations register additional domains based on various permutations of their primary production domain. Sometimes domains are registered to deter potential competitors, and the registrations are aimed at protecting their brand from trademark infringement. Increasingly, we see organizations acquiring domains to deter attackers from registering domains used in social engineering campaigns.

Once you get started on the latter, the pertinent question becomes how many permutations on your domain you’re willing to invest in. Where do you stop?

There is a stronger case to be made for registering key domains that help to catch emails gone awry (the inevitable “fat finger” errors). In the grand scheme of things, domains are cheap.

But once we start considering defensive domain registrations, the value of every subsequent registration diminishes. By using a tool like dnstwist, you can very quickly see how big the game of whack-a-mole could be. With a 4 character domain name, dnstwist generates over 1000 domains. If you multiply this against additional brands and common phishing keywords (support, login, helpdesk, etc), the scope of the problem easily explodes by orders of magnitude.

Conservatively, registering all these domains could easily cost $100k+ per year. Even after you’ve expended this effort, adversaries can always always find yet more permutations of your domain (or the services your users are familiar with) that you haven’t considered. And at the end of the day, registering those domains hasn’t moved the security needle one bit: we have merely expended scarce budget on a few surmountable hurdles for an attacker to side-step.

Let’s just eliminate the phishing problem?

Writing in this blog, my colleagues and I have implored Okta customers to embrace phishing-resistant factors like Okta FastPass and FIDO2 WebAuthn, for a number of good reasons.

Preventative controls are nearly always far more desirable than compensating controls. FastPass or WebAuthn can essentially eliminate phishing attacks that target user authentication. The same can’t be said for defensive domain registrations. The TL;DR is that phishing resistant methods of authentication cannot be phished the same way legacy factors like passwords, and basic MFA (OTP, SMS, etc) can, because they are scoped - that is, authentication is cryptographically tied - to the origin. In other words, a phishing-resistant factor will never authenticate to a domain that it was not enrolled in, even if the user has been tricked into visiting a malicious site.

Not only is this an effective security control, the user experience is far better than a password or any combination of legacy factors. As described in the Secure Sign-in Trends Report, phishing-resistant factors including FastPass and WebAuthn are;

• Faster to enroll

• Faster to use

• Fail less often

• Are not susceptible to brute-force attacks

• Inherently more secure (Phishing-resistant)

• Able to satisfy multiple factor requirements with a single user action (Biometric + Possession)

How can I start using FastPass?

Assuming you’re using Okta Identity Engine (OIE), FastPass is already available to you. If you’re still on Okta Classic, this is another great excuse to take the free upgrade to OIE.

Here are some resources I recommend to help you get started:

• Okta FastPass | Okta Docs

• Becoming phishing resistant with Okta FastPass | Step-by-step guide

• Going Password-less in Okta Identity Engine | Okta Demo Video

• Okta’s journey to passwordless & phishing-resistance | Oktane Video

• How modern credential phishing attacks work: the adversary in the middle (Part 1) | Blog

• A Deep Dive Into Okta FastPass (Part 2) | Blog

• FastPass | Technical Whitepaper

If your Workforce org is licensed for Adaptive MFA, I’d also recommend this cheeky rule that packs a lot of punch. An attacker that has stolen user credentials and/or a session cookie will almost always sign in from a New Device and a New IP address. With Okta Expression Language, we can force authentication attempts from New Devices and New IPs to prompt for phishing-resistant factors:

Making all user authentication flows phishing-resistant should be the north star for user identity. And Okta isn’t the only team offering guidance on this. If you need some impartial evidence, try:

• National Institute of Standards and Technology (NIST) - Digital Identity Guidelines

• Cybersecurity and Infrastructure Security Agency (CISA) - More than a Password

• Australian Signals Directorate (ASD) - Essential Eight Maturity Model

• The Executive Office of the US President - Moving the U.S. Government Toward Zero Trust Cybersecurity Principles

It’s time to take the phishing-resistant plunge, and Okta is here to help.

John leads the EMEA node of Okta's Detection and Response Engineering team.

His team develops detections and supplementary automations to protect Okta from threat actors, which in turn inform our rotational response and threat hunting missions.