Press & Newsroom for Token Next-Gen MFA

The Aflac Breach Was Preventable —Token’s Technology Proves It

Written by Kevin Surace | June 23, 2025

Legacy MFA and auth apps are obsolete. Hackers exploit them daily. Token stops them cold.

ROCHESTER, NY, June 23, 2025 -- Token, a revolutionary provider of secure, biometric identity protection solutions, announced that its technology is the industry’s only available solution that could have prevented the serious data breach that Aflac confirmed on June 20, 2025. The Aflac breach possibly exposed customers’ Social Security numbers, insurance claims, and personal health information and is considered to be the biggest breach in a growing wave of cyberattacks targeting the insurance industry.

“With billions in revenue and millions of customers, Aflac now joins a troubling list,” said Kevin Surace, Chair, Token. “Erie Insurance and Philadelphia Insurance companies were also hit this month, with major IT disruptions affecting customer services.”

According to industry experts, sources close to the investigation say all signs point to Scattered Spider— a fast-moving, aggressive cybercrime group that’s quickly becoming a top threat. The breach method relies on (and expects) legacy multi-factor authentication (MFA) — where SMS codes can be intercepted or relayed, and users can be tricked into approving authenticator app prompts during real-time phishing. These methods are easily manipulated and no longer offer protection.

This type of hack requires little to no technical ability, and almost anyone who can create a simple spoofed webpage can execute this hack in minutes, leaving every company fully exposed today.

Token Ring and Token BioStick leverage a combination of biometric ID (fingerprint) and proximity (using encrypted Bluetooth) to the specific device logging in to the actual registered application. Token stores a unique private key per site, secured by fingerprint. During login, it signs a one-time challenge from the real site’s FIDO2 server, which verifies the signature and origin. If the origin doesn’t match, the login is rejected — blocking phishing and spoofing outright.

This stops real-time phishing because every credential is cryptographically locked to the exact web origin it was created for, and the authenticator will only sign a challenge that (a) comes from that origin and (b) is confirmed by a live fingerprint-match. A phisher can steal nothing re-usable and cannot trick the token into signing for the wrong site. If Aflac employees were using a Token product, the hack could not have occurred.

Layer Spec element Why it stops the phisher

WebAuthn (W3C)

Origin & RP ID binding – §5.1 «Relying Party Identifier» When the browser calls navigator.credentials.get() it hands the authenticator the hash of the site’s effective domain (RP ID). The authenticator will only use a private key whose RP ID hash matches. A fake site (“evil.example”) gets a different RP ID hash than the real one (“app.company.com”), so the token has no key it can use – authentication simply fails.
Client Data JSON – §5.8 The browser packages the server’s one-time challenge, the origin, and the type into clientDataJSON. The authenticator’s signature implicitly covers this blob. If the attacker tries to replay it elsewhere, the origin mismatch is immediately detected by the server.

CTAP2 (FIDO Alliance)

User Verification (UV) – Req FIDO2 §7 Token Ring’s onboard fingerprint sensor sets the UV flag in authenticatorData. The server requires that flag; remote malware cannot supply it.
Non-exportable keys – CTAP2 §6 The private key never leaves the hardware, so a relay proxy cannot copy, replay, or modify it.
Sign Counter– §6.1.1 Each successful sign increments a counter stored inside the authenticator and reflected to the server. If an attacker somehow cloned a credential, diverging counters expose the clone immediately.

TLS + Same-Origin Policy

Mandatory HTTPS (§5.2) WebAuthn calls are only allowed in secure contexts. The phisher can proxy traffic, but it cannot cause the browser to treat its page as the real origin, so it cannot invoke WebAuthn for the real domain.

Why the “real-time relay” trick fails

    1. User originally registered a Token device with the true site
during the registration with the true site, public/private cryptographic key pair is negotiated which is required and validated during every subsequent passkey operation from that device to that site
  1. User originally registered a Token device with the true site
    • during the registration with the true site, public/private cryptographic key pair is negotiated which is required and validated during every subsequent passkey operation from that device to that site
    • the serving site retains the public key which is used for further trusted communications with the private key on the device
  2. Hacker pushes a phishing email to the victim
  3. Victim opens the phish page. The page's origin is evil.example A sophisticated phish page could potentially ask for Authentication for the true site not evil.example
    Browser passes rpIdHash = SHA-256("evil.example") to the token.
    Token Ring has no key for that hash ⇒ authentication fails.
  4. Even if the browser passes the true page name to the Token FIDO2 authenticator, the attacker's domain does not possess the cryptographic credentials for the true page to complete the authentication process with the private key on the device
  5. Token Device has no identity for the incorrectly cyphered request ⇒ authentication fails - technically doesn't occur

If the attacker tries to be very clever and relay the legitimate site’s WebAuthn challenge through its proxy:

  • The challenge was generated for app.company.com; the browser at the phish site still reports its own origin, so the signature the authenticator creates cannot be validated by the real server (rpIdHash mismatch).

Summary:

Because Token products store a negoUated key pair per site and will only release a signature when:

  1. The site matches the domain the user is really visiting, and the domain has the secret key pair which matches the initial device registration, and
  2. The fingerprint sensor verifies the legitimate user.

A remote adversary has no path to “spoof the key” or “forward the signature” the way they can with OTP codes or push-approval apps. Implemented correctly, FIDO2 offers true phishing-resistant MFA — and that’s what makes biometric Token products orders of magnitude safer than legacy MFA.

The fastest, most effective way to lock down your data and networks is to roll out Token Ring or Token BioStick across your workforce. Even if an employee falls for a phishing email, hackers still hit a dead end. Why? Because legacy MFA — like SMS codes and authenticator apps — is laughably easy to bypass. Hackers relay codes, spoof app prompts, and trick users every day.

But Token’s biometric FIDO2 authentication and proximity controls make that impossible. Credentials never leave the device, can’t be replayed, and only work with a live fingerprint match and the right domain next to the actual device logging in. It’s the difference between a padlock and a vault.

About Token In a world of stolen identities and compromised user credentials, Token is changing the way our customers secure their organizations by providing passwordless, biometric, multifactor authentication. We deliver the next generation of multifactor authentication that is invulnerable to social engineering, malware, and tampering for organizations where breaches, data loss, and ransomware must be prevented. To learn more, visit www.tokenring.com.