Handling passwords and tokens in your own app

Adding sign-in to an app means storing secrets you never want to see leaked: passwords, API keys, two-factor seeds. The rule for each is the same: store something that lets you check the secret, never the secret itself. Your app’s language has libraries for all of this; these tools let you try the formats, make test values and check your code gives the same answers.

Take care with secrets. This runs only in your browser: what you enter isn't uploaded, stored or put in a link, and the page is built so that it can't send it anywhere else. Your browser's extensions and other software on your device can still see what's on screen, so use a device you trust and real secrets only when you need to. Disconnecting from the internet once the page has loaded gives the most protection. Use is at your own risk: see the terms.

1. Store passwords as slow hashes

Store a password’s hash, made with an algorithm built to be slow, never the password and never a plain SHA-256. OWASP’s guidance puts Argon2id first where your platform has it; bcrypt is the widely supported alternative and what most frameworks use by default.

Under Hash a password in Bcrypt, type a test password, choose a Cost and Hash. Each step up in cost doubles the work: choose the highest your server can do in about a quarter of a second per sign-in, usually 10 to 12, and raise it as hardware gets faster. Under Check a password, paste a hash your code made and the password, to check your code and this tool agree; it also shows the hash’s version, cost and salt.

Bcrypt reads only the first 72 bytes of a password, so set a maximum length or hash longer ones first, and don’t cut passphrases short without saying so.

2. API keys: show once, store a hash

In the Password Generator, choose API key (base62) with a Prefix such as myapp_, so a key pasted somewhere it shouldn’t be is easy to recognise and to search for in code. For session tokens and reset links, URL-safe token (base64url) with 32 Bytes is plenty.

Show a new API key to its owner once, and store only its SHA-256. A key this random can’t be guessed back from its hash, so a fast hash is fine here, unlike passwords. Paste a test key into Hash / Checksum and choose Hash text: the SHA-256 row is what your code should store and look up when the key is used.

3. Two-factor sign-in with TOTP

Authenticator apps make six-digit codes from a shared secret and the time. Under TOTP / HOTP Codes, Make a new secret gives a Base32 secret, a QR code and the otpauth:// link your app will show at setup. Put your app’s name in Issuer and the user’s email in Account: authenticator apps show both.

When your code checks a code, compare it with what the tool shows for the same secret, and accept the period either side as well, as the tool’s Check a code does, to allow for clocks that drift. Store the secret encrypted, since anyone with it can make the codes, and give recovery codes at setup (the Password Generator’s Random characters makes a set).

4. Check the tokens you issue

If your app issues JSON Web Tokens, paste one into the JWT Decoder and look at it as an attacker would: anyone can read the payload, so it mustn’t hold anything secret; exp should be minutes or hours away, not months; and aud should name the service that accepts it. What’s inside this JWT? goes through each claim and checking the signature.