Passwords, Passkeys & Authentication

Password strength is not about weird symbols. It is about entropy — a measure, in bits, of how unpredictable the password is. Each bit doubles the number of guesses an attacker must make. A password with 40 bits of entropy needs about a trillion guesses; one with 80 bits needs an unimaginable number more.

Entropy is driven far more by length than by character variety. Adding one random lowercase letter multiplies the guess space by 26; adding symbols only widens the alphabet a little. This is why a long passphrase like correct-horse-battery-staple beats a short, tortured P@ssw0rd! — and is easier to remember. The catch: length only helps if the password is random. A long password built from song lyrics or predictable substitutions has low real entropy because attackers model those patterns.

The practical takeaway: you cannot both memorize dozens of long random strings and reuse nothing. Something has to give — and it should not be uniqueness.

Sites should never store your raw password. They store a hash — the output of a one-way function that is easy to compute forwards and infeasible to reverse. When you log in, the site hashes what you typed and compares. When a database leaks, attackers get hashes, not passwords, and the race to reverse them begins.

They have several tools:

• Dictionary attacks hash entire wordlists of common and previously-leaked passwords and compare — fast and devastatingly effective against weak choices.
• Brute force tries every combination. Feasible for short passwords; hopeless against long ones.
• Rainbow tables are giant precomputed lookup tables of hash-to-password, trading disk space for speed.
• Credential stuffing skips cracking entirely: it takes username/password pairs from one breach and replays them on other sites, betting you reused them.

Speed depends brutally on the hash. A commodity GPU can try billions of fast MD5 or NTLM hashes per second. That is why the algorithm matters: salting (adding a unique random value per password) kills rainbow tables outright, and deliberately slow, memory-hard hashes like bcrypt, scrypt, and Argon2id — the 2015 Password Hashing Competition winner — throttle guessing to a crawl.

The only sane way to have a long, unique, random password for every account is to not remember them. That is what a password manager is for. It generates and stores strong credentials in an encrypted vault, and you unlock the vault with one strong master password (and, ideally, a second factor).

The security model rests on that master password. Reputable managers — Bitwarden, 1Password, KeePass — use zero-knowledge or client-side encryption: your vault is encrypted and decrypted on your device with a key derived from your master password, so the provider stores only ciphertext and cannot read your data even if they are breached. Your master password is never sent to their servers.

The common objection — "isn't one vault a single point of failure?" — has a clear answer. Yes, the vault is valuable, so you protect it well: a long unique master password you use nowhere else, plus MFA. In exchange you eliminate reuse, defeat credential stuffing across every other account, and get autofill that quietly resists phishing (a manager will not offer to fill your bank password on a look-alike domain).

Multi-factor authentication (MFA) adds a second proof beyond your password — something you have or are, not just something you know. It is the single highest-value control most people can turn on. But not all factors are equal, and attackers have adapted to each.

TOTP codes follow the open standard RFC 6238: your app and the server share a secret and both compute a code from the current time, rotating every 30 seconds. It is solid — but if you can be tricked into typing that code into a fake login page, the attacker simply forwards it. That is the crucial limitation nearly every non-hardware factor shares.

Passkeys are the endgame: authentication with no shared secret to steal, phish, or leak. They are built on the FIDO2 standards — the W3C's WebAuthn browser API plus the CTAP protocol to your device or security key.

The mechanism is public-key cryptography. When you create a passkey, your device generates a key pair. The public key goes to the website; the private key never leaves your device — it lives in secure hardware like a phone's secure enclave or a hardware key. To log in, the site sends a random challenge, your device signs it with the private key (unlocked by your fingerprint, face, or PIN), and the site verifies the signature with the public key.

This kills entire attack classes at once. There is no password to reuse, no code to intercept, and — critically — passkeys are origin-bound: the signature is cryptographically tied to the real domain, so a look-alike phishing site simply cannot elicit a valid one. Server breaches leak only public keys, which are useless to an attacker.

The best password is no password. The best second factor is one that physically cannot be handed to the wrong website.