Filling codes only on the right site (phishing protection)

Autothenticator · Updated 18 October 2026

This is the core of the product.

Binding

Each account is bound to the sites (and, on Android, apps) where it may be filled.

Site binding, the usual kind, is a registrable domain, such as example.com. It covers every subdomain (login.example.com, www.example.com).
Shared hosting suffixes are handled properly: alice.github.io and mallory.github.io are different sites, and github.io on its own can never be a binding.
Pattern binding (advanced) narrows it, for example to https://*.example.com/login*.
App binding (Android) names an app by its package name, for example com.example.bank. Android guarantees an app can't pretend to be another app's package name.

Where bindings come from

When you scan a QR code on a page, that page's site becomes the first binding.
A built-in list adds known sign-in domains for big services whose sign-in page is on a different domain. For example, Microsoft accounts also bind microsoftonline.com and live.com.
Importers add bindings from the same list.
Accounts with no binding can't be filled anywhere. They're "copy only" until a site is added.

When a code is filled

The page's real address, as the browser or the operating system reports it, must match a binding. Nothing the page says about itself counts.
Only HTTPS pages. Plain HTTP is allowed only for localhost, for developers.
When several accounts match, a picker is shown. It never picks one silently.
Android apps get their own app bindings. They also get the accounts for a site that has declared the app as its own (Digital Asset Links), but only if the installed app is signed with the certificate the site names. A fake app with the same name gets nothing.
On Android, the website address is believed only from a trusted browser. That means Chrome, Firefox, Edge, Samsung Internet and other mainstream browsers, each checked by its signing certificate. Any other app claiming a web address is treated as itself, because an app can show a real site inside its own window and read what's typed.

Lookalike warnings

When a page has a code box but matches no account, Autothenticator checks whether the page imitates one of your bound sites, and warns you if it does:

the same name under another ending (example.co for example.com);
your site's name inside another address (example.com.evil.net, login-example.net);
one character off after swapping common lookalikes (examp1e.com, rn for m, 0 for o).

A warning never allows a fill. It exists because a person who sees nothing might copy the code by hand instead.

Fill-only

New accounts with a binding are fill-only by default. The code is never shown on screen or copied, only filled into the bound site.
Turning it off: a person can turn it off for one account, or change the default, after a warning that no genuine company will ever ask for the code.
Accounts with no binding can be copied, because there's nowhere to fill them.
What it stops: someone being talked into reading a code out, and codes pasted into the wrong place.
What it doesn't stop: once filled, the code sits in the page for a few seconds before it's submitted, so a technical user with the browser's developer tools could still read it. Businesses who need more use machine restriction and hardware keys (see Autothenticator Business and Enterprise).

Copying

Copying skips the site check, so the app always shows the bound site next to the copy button, as a reminder.
The clipboard is cleared after 45 seconds by default (it can be changed, or turned off).
Windows clipboard history, and cloud clipboards, may keep a copied code. That's a reason to fill rather than copy.

Clock

TOTP codes come from the device's clock. A wrong clock gives wrong codes.
When syncing, the app checks its clock against the sync service's time. If it's more than 15 seconds out, the extension and the Android app say so, and how to fix it. Nothing is changed automatically.
Last resort: a per-account time offset (up to ±10 minutes), for a service whose own clock is wrong.