WebAuthn passkeys vs. passwords: a workspace-tool comparison
Why a passkey is structurally a stronger authentication primitive than a password — and what changes when a workspace tool drops passwords entirely.
Passwords have been the default authentication primitive on the web for thirty years. They've also been the structural source of nearly every credential-exposure breach in the same period. Passkeys — built on the WebAuthn standard — are the replacement that most major platforms (Apple, Google, Microsoft, GitHub) have rolled out over the past three years. For a workspace tool, the choice between password-based and passkey-only authentication is meaningful in concrete ways.
What a passkey actually is
A passkey is an asymmetric cryptographic keypair. The private key lives on your device (or in a synced credential manager like iCloud Keychain, Google Password Manager, 1Password, Bitwarden), and the public key lives with the relying party — the workspace tool. When you sign in, the workspace tool sends a challenge; your device signs it with the private key; the workspace tool verifies the signature with the public key. The private key never leaves your device.
From the user's experience: you tap a biometric prompt (Touch ID, Face ID, Windows Hello, Android biometric) or a hardware key, and you're signed in. There's no string to remember or type, no autofill to spoof, no password manager to compromise.
Why passkeys are structurally stronger
Phishing resistance is automatic. A passkey is scoped to the domain it was created for. If you create a passkey on koaich.com and an attacker sends you a link to k0aich.com with a perfect visual replica, your browser refuses to honor the passkey — the origin doesn't match. Passwords have no such built-in defense; the burden is on you to notice the spelling.
Server-side compromise doesn't expose credentials. If a workspace tool with passwords is breached, password hashes leak — and any user who reused that password elsewhere is now vulnerable on those other sites. If a workspace tool with passkeys is breached, the attacker walks away with public keys, which are useless. The private key never left the user's device.
No reuse risk. Every passkey is unique to the site. Your koaich.com passkey is a different keypair than your gmail.com passkey. Compromise of one says nothing about the other.
No transmission risk. Passwords are sent to the server (over TLS) at every login. Passkey authentication transmits a signature, never the secret. There is no "listen to the wire" attack against passkey login.
What changes when a workspace tool drops passwords entirely
No password reset. The password-reset flow is the most common backdoor in workspace security. An attacker who compromises a user's email account can typically reset the workspace password and gain access. A workspace tool with no password has no reset flow — recovery routes through different mechanisms (hardware-backed account recovery, recovery codes, social recovery), each with its own properties.
No password reuse leverage. Credential stuffing — using passwords leaked from one breach to try other sites — accounts for a substantial fraction of account takeovers in mature security telemetry. A workspace tool with no password is immune to this entirely.
Different recovery model. The trade-off: when something goes wrong, recovery has to be designed in. Koaich uses Shamir's Secret Sharing across the user's own devices plus recovery codes; Apple uses iCloud Keychain account recovery with trusted contacts; GitHub allows recovery codes and SMS fallback (the latter is a weak point). The recovery model is the new attack surface, and it has to be designed carefully.
Onboarding is different. Users used to passwords expect a username + password field. Passkey-only onboarding starts with "tap your authenticator" or "register a passkey," which is unfamiliar to most users. The UX has to bridge the gap.
WebAuthn details that matter
WebAuthn is the W3C standard that makes passkey authentication work in browsers. Several technical details determine the security posture of a workspace tool's WebAuthn implementation:
Resident keys (discoverable credentials): the authenticator stores enough metadata to find the right key without the user typing a username. This is what enables "tap to sign in" with no username field — the right pattern for a workspace tool.
User verification (UV): the authenticator requires the user to prove presence (touch a sensor) and identity (biometric or PIN). Workspace tools should require UV — otherwise a stolen unlocked device is a free login.
Attestation: the authenticator attests to its make and model. Workspace tools can use this to require specific classes of authenticators (e.g., hardware-backed only, for high-security tiers). Most consumer flows skip attestation; enterprise flows often require it.
PRF (pseudo-random function) extension: a WebAuthn extension that lets the authenticator derive a deterministic secret from the credential. This is what lets a workspace tool encrypt local data under a key bound to the authenticator — see Koaich's encrypted-IndexedDB approach.
When passwords still make sense
Passwords remain the right primitive for: services that need to work for users without modern authenticators (most users have one now, but not all); services where the security posture doesn't justify the UX investment; services where recovery requirements outweigh credential security. Most consumer SaaS that isn't security-sensitive lands here.
Workspace tools that handle sensitive content — and especially tools positioned around the property that "the vendor cannot read your data" — should not lean on passwords. The credential is the gate; if the gate is a password, the vendor's promise about what's behind the gate is undermined by every credential-stuffing attack against the password.