Every customer conversation I’ve had in the last four to six months has involved talking about phishing resistance. I have heard a variety of explanations on what makes Beyond Identity, or any other company, phishing resistant. It’s a great question, and one that’s quickly becoming an urgent issue for organizations as an increasing number of regulatory agencies are requiring phishing-resistant MFA.

The best technical documentation on phish-resistance is from NIST. They outline the need to provide verifier impersonation resistance. The issue is, most people don’t really understand the complex terminology and the NIST standards aren’t as in-depth as they could be. 

Phishing prevention is impossible

In a phishing attack, the victim receives a phishing lure leading to a malicious link. The mechanism of delivery varies—SMS, email, fake websites, and QR code on fliers are all commonly used by threat actors. The contents of the malicious link might contain downloads of malware, trigger vulnerabilities in software, or deliver the victim to fraudulent web sites. 

Phishing also involves a fair amount of social engineering to encourage the victim to take action. 

So why can’t we stop phishing?

• You can reduce phishing, but you cannot stop adversaries from sending phishing lures
• With training, you can educate your workforce but that won’t stop victims from clicking on convincing links in lures

While we can’t stop phishing, we can solve a problem related to phishing for access credentials and/or access token theft. 

Stopping credential theft

Credential theft is the easier problem to handle. Most credentials are some form of symmetric, or shared secret (like passwords). The problem is that a shared secret must be shared and transmitted between a client and a server. Application load balancers, proxies, and content distribution networks ensure that these secrets touch the memory of many machines between the client and the server. 

If any of these machines were to become compromised, the shared secrets it contains are also compromised. Users can also unknowingly or unwittingly divulge the shared secret. 

Preventing credential theft requires the realization that the movement of the credential is bad. Every time the credential moves, it increases the surface area that must be protected. 

If a credential never moved, it would have a surface area the size of its host computer.

Asymmetric cryptography provides the technical means of creating unmovable credentials. Create an asymmetric key pair, share the public key, don’t move the private key, and sign challenges with your private key. This is a simple mechanism that chips away at the problem. 

But we can do better. Is there a way to guarantee the key won’t move? Most computing devices contain a Secure Enclave (SE) of some type, the most well known being Trusted Platform Modules (TPMs). It's possible to create a key pair within a TPM and ask the TPM to glue the private key to its internal nonvolatile secure memory. If successful the TPM will provide a receipt verifying the key construction and its storage location. 

This creates a credential with a guarantee it won’t move. It never leaves the TPM, never exists in memory, never ends up on a disk, and can never be transmitted over a network connection. The key can’t move, so it can’t be stolen. That’s the good news. The bad news is the fool, the human link, can still be compromised.

Signing fools: humans are the weakest link

If you’ve seen some of these demos you know that systems that use asymmetric keys and enclaves can still be phished. Secure Enclaves (SE) and asymmetric credentials do not make a system phishing resistant. While they are a necessary step, they are not sufficient. 

For that we must get to what NIST calls verifier impersonation resistance.

Any attacker who can phish me could trick me into signing their challenge. Imagine the adversary goes to a service provider I have valid credentials for. The adversary receives a challenge from the service provider and then relays that challenge to me and tries to convince me, the fool, to sign the challenge for them. 

If I do, they return the signed challenge to the service provider. You can’t prevent a fool from signing a challenge, you just have to get rid of the fool!

Humans will always click on malicious links. Even with cybersecurity training, users will still fall prey to social engineering. 

Removing the human element

This is where client-based authenticators come into play. A software-based client could execute an authentication protocol with the precision of a machine. That client will always know the identity of the server issuing the challenge, under the assumption that the certificate identifying the server and its TLS connection has not been compromised. The client can simply decide if the server name issuing the challenge is legitimate and only sign legitimate challenges.

Now we need to solve the problem of challenge legitimacy. 

Remember, a Secure Enclave can create a key pair and provide a receipt. Any tampering of its contents would be evident by an invalid signature. That receipt needs to include an attribute called the “audience,” a list of domains where the credential can be used. 

A good client authenticator would verify the challenge server name against the audience list of the key being asked for. If the name is in the list, sign the challenge, if not, restrict or reject access. 

Phishing resistance for authentication 

Phishing prevention is impossible. Phishing resistance for authentication, however, is real 

NIST 800-63-B provides the technical requirements needed for phishing-resistant authentication. 

Beyond Identity, which is FIDO certified, exceeds those requirements and provides true phishing resistant authentication by utilizing:

• Asymmetric keys over shared secrets to prevent movement
• Secure Enclaves to guarantee no movement
• Client authenticators to remove the fools

Ready to see how? Book a demo today.