News
WebAuthn vs Passwords for Public Site Login
May 20, 2026
WebAuthn vs passwords for public site login is an authenticator-bound credential versus a string people reuse. Passkeys (WebAuthn / FIDO2) prove possession of a device-bound key, often with a biometric or PIN on that device. They cut credential stuffing and many phishing forms that only steal a password field. They do not replace TLS, rate limits, or access control on /wp-admin. A brochure site with no login does not need them. RoastMyOpsec does not click Sign in, does not touch WebAuthn, and does not score missing passkeys as an F. It may still grade login discoverability and cookie flags on the URL you paste.
The practical difference
A password is a shared secret that leaks in dumps and support chats. WebAuthn is origin-scoped: the browser will not silently use a passkey for a lookalike host. SMS OTP is a third costume — better than password-only, worse than a passkey for phishing. See rate limits vs captcha and change-password well-known.
Asset links and apple-app-site-association matter if the passkey should work in an app. That is a different public file.
How to choose an auth plan
No accounts: skip passkeys. Marketing plus a newsletter: magic links or a host you actually harden, not a leftover WordPress login. Real accounts: offer passkeys, keep a recovery path that is not 'email us the password,' rate-limit the remaining password or OTP fallback. Do not leave XML-RPC on as a password oracle. Recovery codes belong in the user's hands, not in a public gist.
| Method | What it proves | Public site | Takeaway |
|---|---|---|---|
| Password only | Knowledge of a string | High stuffing cost | Add rate limits; prefer passkeys |
| WebAuthn / passkey | Device-bound key for this origin | Best for real accounts | Not a roast F if missing |
| SMS OTP | Possession of a number | SIM-swap and phishing cost | Fallback, not the only factor |
| change-password well-known | Where to rotate a password | Optional if you still have passwords | See change-password vs reset URL |
When passwords still win (as a fallback)
A carefully rate-limited password plus passkeys still wins for users who lost the device. Passkeys win as the default for new accounts. Missing WebAuthn on a brochure is healthy. Pair with admin discoverability if /wp-login.php is the real story.
What the roast can prove
Login path discoverability and cookie flags on a consented GET. WebAuthn ceremonies are out of scope. Confirm passkeys in your own staging login. Pair with consent-based scanning — do not roast third-party logins as research.
Common mistakes
The first mistake is passkeys on a marketing host whose real login is a different origin with no related origin binding.
The second mistake is a password fallback with no rate limit because 'everyone uses passkeys now.'
The third mistake is treating missing passkeys as a header-scan F.
Free audit the URL you own
RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.
Free audit nowFAQ
- Is a password-only login a vulnerability?
- It is a weaker authentication choice, especially without rate limits. It is not an automatic roast F. Passkeys are the upgrade for sites that have accounts.
- Do brochure sites need WebAuthn?
- No. If there is no login, skip it. Missing passkeys is not a roast finding.
- Does RoastMyOpsec test passkeys?
- No. It does not run WebAuthn ceremonies or score missing passkeys.