Yes, passkeys are safe, and for most people they're safer than passwords. A passkey is a cryptographic key pair: the website only stores a public key, and the private key never leaves your device or password manager. Because a passkey only works on the website it was created for, it can't be phished, reused or leaked in a server breach. The real downsides are not about security but about control: how your passkeys are stored, whether you can move them between providers, and what happens if you lose access to your account with the company that syncs them.
That second point is why passkeys were the most-discussed security topic on Hacker News this week. A post titled "Passkeys are a trap. Do not use them.", published on 10 October 2026, reached the front page with over 900 points by 11 October. This guide explains what passkeys are, what the post gets right and where it goes further than the evidence, and how to use passkeys sensibly.
The passkeys.dev introduction, maintained by members of the FIDO Alliance and the W3C Web Identity & Credentials Adoption Community Group, defines passkeys as "a replacement for passwords. A password is something that can be remembered and typed, and a passkey is a secret stored on one's devices, unlocked with biometrics."
Under the hood, a passkey is a WebAuthn credential. WebAuthn is a W3C standard that browsers implement, and it lets a website ask your device to create and use a public/private key pair. passkeys.dev lists four properties:
When you sign in with a passkey, three things happen:
Nothing secret crosses the network. Your fingerprint or face never goes to the website either; it only unlocks the key on your device.
The phishing protection comes from origin binding. When you create a passkey, it's tied to the website's domain (the "relying party ID"). If a fake site at a look-alike domain asks your browser for a signature, the browser simply won't offer the real site's passkey. With a password, you're the one who has to spot the fake domain, and people get that wrong.
Passwords fail in predictable ways, and passkeys remove most of them:
If you build login systems, it helps to see how much work a password needs on the server: salting, slow hashing and verification, as in my PHP password_hash and password_verify example. With passkeys, the server stores a public key and checks a signature, and there's no secret on the server to protect.
The viral post praises authenticator apps, and it has a point: TOTP (time-based one-time passwords) is an open standard, RFC 6238, so any app or even your own code can generate the codes. The algorithm is short enough to write yourself. Here's a Python version checked against the RFC's official test vectors:
import hmac, hashlib, struct
def totp(secret: bytes, unix_time: int, digits: int = 6, step: int = 30) -> str:
counter = struct.pack(">Q", unix_time // step)
mac = hmac.new(secret, counter, hashlib.sha1).digest()
offset = mac[-1] & 0x0F
code = struct.unpack(">I", mac[offset:offset + 4])[0] & 0x7FFFFFFF
return str(code % 10 ** digits).zfill(digits)
# RFC 6238 Appendix B test vectors (SHA-1, 8 digits)
seed = b"12345678901234567890"
for t, expected in [(59, "94287082"), (1111111109, "07081804"), (2000000000, "69279037")]:
print(t, totp(seed, t, digits=8), "expected", expected)
Output on Python 3.13:
59 94287082 expected 94287082
1111111109 07081804 expected 07081804
2000000000 69279037 expected 69279037
TOTP is portable and you fully control the seed. But it has one big weakness that passkeys don't: a TOTP code can be phished. If you type a valid code into a convincing fake login page, an attacker can relay it to the real site within its 30-second window. A passkey refuses to sign for the wrong domain, so that attack doesn't work.
The post is aimed at non-technical readers and agrees that "passkeys can be far more secure than passwords". Its argument is about who controls them. In summary, it says:
The concerns about control are reasonable:
But some claims go further than the evidence:
The fair reading: passkeys are a big security improvement, and the open questions are about portability and who decides what counts as an acceptable authenticator.
This is the most useful distinction to understand:
WebAuthn reports this to websites through "backup eligible" and "backup state" flags, so a bank, for example, can tell whether a passkey is synced.
If your passkeys are synced, sign in to your password manager account on a new device and they come back. That's why you should protect that account carefully, with its own recovery options set up.
If your passkeys are device-bound, you'll need another way in: a second passkey on another device, a backup security key, recovery codes, or the site's account recovery process.
A good rule is to register at least two passkeys for important accounts, for example one on your phone and one on a laptop or security key, so a single lost device never locks you out.
Passkeys remove phishing and password leaks, but they aren't magic:
For most people, yes, especially for email, banking and your password manager itself. A practical approach:
If you're a developer adding passkeys to your own site, keep a fallback sign-in method, and don't require attestation unless you have a strong reason, such as an internal staff system. The rest of your login flow still matters: secure session handling, as in my PHP login session example, and safe account recovery.
Yes. Passkeys can't be phished, reused across sites or leaked from a website's database, because the website stores only a public key and the browser only offers the passkey on the correct domain.
It's a 10 October 2026 Substack post that went viral on Hacker News. It accepts that passkeys can be more secure, but argues that features like attestation could let websites control which passkey providers you're allowed to use.
The main ones are dependence on the company that syncs them, uneven support for moving passkeys between managers, and the risk of lock-out if you lose your only device or your sync account.
Synced passkeys come back when you sign in to the same password manager account on a new device. Device-bound passkeys are lost with the device, so keep a second passkey or recovery codes.
They can't be phished, but malware on your device, a compromised sync account, weak account recovery or stolen session cookies can still lead to an account takeover.
Some password managers can export or transfer passkeys, and the FIDO Alliance has been working on standard credential exchange formats, but support varies. Check your manager's documentation before relying on it.
An authenticator app gives you more control over your secret, but its codes can be phished in real time. A passkey is stronger against phishing. Many people use passkeys where available and authenticator apps elsewhere.
Often you can keep one as a fallback, and many sites still require it. If you keep a password, make it unique and store it in a password manager.
// note
This is a learning note from studying the web. It is one small topic, written so I can remember it. It is not a course and not a claim that I have finished the subject.
If a sentence is wrong, say so from the contact page and name this title. Drafts never appear here. Related notes, when they exist, are other published posts, and the same sample rule applies to each of them.
The UK government plans to stop under-16s using platforms such as TikTok, Instagram, Snapchat, YouTube, Facebook and X from spring 2027. Here is what the official fact sheet says, how age checks might work, whether adults will need to show ID, and what it means for developers and parents.
On 6 October 2026 ASOS app users received a push notification reading 'ASOS HACKED'. ASOS later confirmed attackers took customer profiles including names, addresses, phone numbers and emails, but not payment details or passwords. Here is a factual timeline and eight practical steps to stay safe.
Fingerprinting identifies your browser from dozens of small details, with no cookie to delete. Here is how it works (with a small tested demo), why "fingerprints are the new cookies" went viral this week, what the ICO says, and what actually helps: browsers, settings, VPNs and incognito.
A new GhostAction wave is using hijacked maintainer accounts to commit a fake "Security Audit" workflow that steals Actions secrets and every credential in your git history. Here is how the attack works, how to check your repositories (with a tested script), and what to rotate.