On a WordPress site, a shop or a custom app, passkeys replace the password people retype, reuse and then forget. The private key stays on a device they control. Your server stores a public key and a credential id, not a shared secret. A fake login page has nothing reusable to steal, because the person never types the credential into the page.
Contents
CodeWiz adds registration, sign-in, recovery and a password fallback that stays on day one. OAuth, JSON Web Tokens and single sign-on are a different design, covered in our authentication system development article. This article is only about passkeys.
It is for shops buried in reset email, offices that share one computer, and teams with their own application. CodeWiz was founded in 2023 by Dragan Plavšić in Banja Luka. We build authentication, WordPress and shops for clients locally and abroad.
What passkeys replace on a website
A passkey is a WebAuthn credential for one relying party: your site. The phone, laptop or hardware key holds the private key and signs a fresh challenge. The person unlocks that signature with a fingerprint, a face or the device PIN.
For returning customers, passkeys take the place of the password they reuse across shops. They also replace the staff password on wp-login and the password field in a custom session. They do not replace authorization: roles and orders still decide what that person may do. Prove an email address before the first credential exists, and leave guest checkout free of any prompt.
The browser binds the signature to the real origin. A lookalike domain gets no password to replay, because the ceremony has none. These credentials remove the shared secret and resist phishing of passwords. A weak recovery email, an unlocked phone or malware on a trusted device can still do harm.
Where passkeys are stored
Synced passkeys are encrypted and copied across the person’s devices by the platform or a password manager. Apple iCloud Keychain, Google Password Manager, a Microsoft account on Windows, and managers such as 1Password or Bitwarden do this. A new phone on the same account can reach your site again, so that platform account’s recovery has to be strong.
A device-bound credential never leaves the authenticator that created it. Hardware security keys work this way, and a platform can create a key you ask not to back up. Lose that object and that credential is gone unless another one, or a recovery path, is already registered.
Store the public key, the credential id, the user id, a sign counter when one is sent, and the WebAuthn backup flags. Those flags say whether the key may sync and whether it is backed up now. A dump of that table is not a password list. Name each credential by device and let the owner remove one.
Registration and sign-in
WebAuthn is a short ceremony between your server, the browser and the authenticator. The WebAuthn Level 3 specification is the reference, and Google’s guide shows the prompts browsers already ship. A long library sample is unnecessary.
Registration starts with a random challenge, a relying party id on a domain you control, and a user handle. The person approves a new key pair with a biometric or a PIN. Your server checks the challenge, the origin and the relying party id, then stores the public key.
Sign-in sends a new challenge. A discoverable credential can appear before a username is typed. Your server checks the signature and the origin, rejects a reused challenge and opens a normal session. Require user verification when this login stands in for a second factor.
Set the relying party id once. A credential for www.example.com will not appear on example.com if the ids differ. Pick the parent domain you control and test both hosts. Conditional UI lists saved credentials in autofill, and a plain button remains for everyone else.
Passwords, one-time codes and passkeys
Most shops already have a password and a one-time code. Replacing both at once fills the support queue. Compare what each factor protects before you delete one.
| Password | passkeys | One-time code | |
|---|---|---|---|
| Server stores | Hash of a shared secret | Public key and credential id | Shared seed or phone number |
| Phishing | Can be typed on a fake page | No shared secret; bound to your origin | A code can be read aloud |
| Database leak | Hashes can be attacked offline | Public key cannot sign in | A stolen seed mints codes |
| Other sites | Often reused | New key pair per site | Per site; SIM swap is not |
| Shared computer | Easy to watch or save | Do not store in a shared profile | May show on a shared screen |
| Phone lost | Reset email is enough | Sync, second credential, or recovery | New number or new app |
One-time codes stay useful as a fallback and as an extra step for staff. They are still shared secrets.
Account recovery when a phone is lost
Recovery is the product decision. Someone who orders from a phone will lose it and will still want the orders and the invoice.
When the credential was synced, passkeys usually return on a replacement phone that signs into the same Apple, Google or Microsoft account, or the same password manager. Name the platform in the help text. That account is now part of your threat model.
A device-bound credential does not return with a cloud login. Register a second one before the loss: a laptop, a hardware key, or both. Nudge staff until two credentials exist. Everyone else needs a single-use recovery code stored only as a hash, or a support check before a new credential is attached.
The email reset link is now the weakest door. Expire it quickly, rate-limit it, and do not let it skip checks on an administrator. In security audits and penetration testing we try that door the way an attacker would. Store recovery codes only as hashes, and log every restore.
Shared office computers
A reception desk, a warehouse PC and a family tablet are bad places for a platform credential. People who unlock the same Windows or macOS user share what that user stored. A fingerprint does not tell them apart.
Leave platform passkeys off a shared operating-system account. The browser can run the ceremony on the computer while the person’s phone, reached by a QR code and a proximity check, holds the key. A hardware key is the other clean choice: PIN, sign-in, and the key leaves with the person. Do not create a credential during guest checkout.
WordPress, a shop plugin, or a custom relying party
On WordPress, a maintained plugin can add WebAuthn to the profile and to wp-login without replacing users, roles or WooCommerce. Treat www and the bare host as one relying party, and do not cache login responses. Test the theme, any two-factor plugin and the shop account pages before that stays in production.
Customer passkeys belong on My Account and, once the prompts are clear, on the returning-customer login. Staff who refund, export addresses or install plugins follow stricter rules. Nothing in the cart should wait on the ceremony, and a failed prompt must not empty the basket.
A custom app makes you the relying party. The credential table sits beside your users. You set the relying party id, verify each assertion and then issue your normal session. Who may enrol, how recovery works and what a shared PC may store are your rules, written in Laravel, Node.js or the stack you already run.
A hosted identity product fits several apps that already share it. For one WordPress shop, a plugin or your own user table is usually the smaller change.
A second factor for administrators
A customer credential with user verification is a strong everyday login. Sync also means the key lives wherever that cloud account lives. For wp-admin, shop managers and anyone who pays out or exports data, keep a second factor.
Staff passkeys are not a reason to delete the authenticator app or the hardware key. Prefer a device-bound hardware key, with a spare stored safely, and leave SMS as a last resort because of SIM-swap risk. Keep the administrator password and the current one-time code on the first day. Ask again for the stronger factor before a plugin install, a payout change, a customer export or a new administrator.
Offer passkeys on day one, and do not force them
Day one is an offer, not a cut-over. After a successful password login, invite the person to save a credential on this device. Let them dismiss it, remember that choice, and never show the invite during payment.
Staff should live with the new login for a couple of weeks and note every confusing prompt. Then offer it to customers. Count how many passkeys people actually save, and watch cancelled prompts and errors by browser. A spike on one phone is a defect to fix.
Keep the password until people who can switch are doing so, support has a recovery script, and a real lost phone has been handled calmly. Earlier, you strand an old phone, a locked-down browser or an in-app webview with partial WebAuthn. That password is still phishable: rate-limit it and do not leave it as a quiet door for administrators.
Mistakes that lock people out
- The new login is the only method before recovery and support exist.
- One credential is treated as a finished account.
- The reset email is easier to abuse than the login it replaces.
- The relying party id differs between www and the bare domain.
- A platform credential is saved on the shared shop computer.
- Attestation is required, so ordinary phones are blocked.
- The login response is cached and reused for the next person.
- Takeover is called impossible, while a recovery link does the attacker’s work.
Treating passkeys as the only door on the first weekend is the mistake we meet most often. The prompt worked on the developer’s phone and failed on a shared Windows login.
How we work
- Discovery: who signs in, on WordPress, a shop or a custom app, and on which devices.
- Plan: synced credentials, device-bound keys or both, the relying party id, and recovery rules.
- Build: enrolment, sign-in, a credential list, and the password path you are keeping.
- Test: current phones and desktops, a hardware key, a shared profile and a lost phone.
- Launch: the offer after a normal login, staff first, not forced on the first day.
- Support: a short recovery runbook, logs for failed ceremonies, and a log of every restore.
Why CodeWiz
- Work we already do: authentication, WordPress and shops, so login matches the account pages people use.
- A real studio: founded in 2023 by Dragan Plavšić in Banja Luka, for clients locally and internationally, remotely.
- Open source first: a maintained plugin or a known WebAuthn library, not a private widget.
- Fit to the risk: a quiet customer offer and a hardware key for administrators.
- In service of the shop: fewer reset emails, and nothing that blocks checkout.
- Fair pricing: premium development without premium prices, scoped after we have seen the site.
Frequently asked questions
Can we delete passwords on the first day?
No. Offer the new login and keep the password until a group already has a second credential and a support path. Older phones and some locked-down browsers still need a way in.
What if a customer loses their phone?
A synced credential usually returns when the new phone joins the same platform account or password manager. A device-bound credential does not, so another credential or your recovery process has to exist first. Switching the whole shop before passkeys are widely saved strands the people who lose a phone first.
Is this safe on a shared office computer?
Yes, when the private key stays on a phone or a hardware key the person carries. Do not save a platform credential in a Windows or macOS account that several people unlock. A QR prompt to their own phone leaves the shared PC without the key.
Can a WordPress shop add this without a new login system?
Often yes. A current plugin can attach the ceremony to existing users and WooCommerce account pages. We still check caching, the domain, staff roles and guest checkout. A custom app usually wants its own relying party, because the user table is already yours.
Do administrators still need a second factor?
Yes. Keep a device-bound key or an authenticator app for anyone who can change the shop, export data or add users. A synced credential is a sound customer login. It should not be the only control on the admin.
Add a calmer login and keep a way back in
Tell us whether the accounts live in WordPress, a shop or a custom app, and whether staff share computers. We will propose an offer that does not force anyone out on the first day. Contact CodeWiz or see our services.