Why a private key, and not email or OAuth

The problem with a password

A password is something a human remembers, so it is short, reused and guessable. Attackers do not break encryption; they log in as you. Every site that stores passwords eventually leaks a list of them, and people reuse the same password across sites, so one leak becomes many.

A private key here is 256 bits of output from the operating system's cryptographic random number generator. It is not a word, it is not typed from memory, and there is nothing to guess, reuse or leak from a breach of another site.

The problem with an email link

A "sign in link sent to your email" flow moves the proof of who you are out of your hands and into an inbox that is:

• read by a provider that stores it indefinitely, and by anything that gets into that account,
• scanned automatically by mail security tools, which is why the link is only spent when you confirm it in the browser,
• subject to a password reset flow, which is an account takeover waiting to happen, and
• a permanent record of your address. We would rather not hold a list of addresses that can be correlated, sold or subpoenaed.

The problem with OAuth

"Continue with Google" is convenient, but it means a third party sits in the middle of every sign in. That party can:

• see which accounts exist here and when they sign in,
• cut off access to your account by revoking the grant,
• share or lose that data, as has happened at scale, and
• serve an attacker a fake approval screen if their domain is misconfigured or taken over.

A key has no third party in the middle. There is no grant to revoke and nobody to trust but us and you.

What we do with your key

• It is made in your browser. Pressing Generate uses the Web Crypto CSPRNG. The key is not fetched from us.
• We keep only a fingerprint. The database stores SHA-256 of the key, not the key. A dump of our database cannot be used to sign in to anything.
• It is never in a URL. Keys travel in POST bodies and cookies marked HttpOnly, Secure and SameSite=Strict, so scripts cannot read them and other sites cannot receive them.
• Nothing refers to it. Our Referrer-Policy is no-referrer, so a key can never travel to another site through a link.
• It is checked, not guessed. The key carries a checksum, so a typo is caught before we look anything up, and lookups use a constant-time comparison.
• Guessing is pointless anyway. 2²⁵⁶ is not a search space. Because the key is already unguessable, a slow password hash would buy nothing: we store a fast fingerprint of a high entropy secret, which is the correct choice.
• Failures look identical. A wrong key, a key that does not exist and a key that is not yours all produce the same message, so nobody can probe for valid keys.

The honest trade-off

There is no password reset. If you lose the key, the account is gone and we cannot get it back, because we never had it. That is the point: we are not able to hand your account to anyone, including us, and nobody can talk us into doing so. Use a password manager, and keep a second copy of the key somewhere offline.

Create an account with a key →