Modern Authentication Architecture: Passwords, Passkeys, and Beyond
How passwords, passkeys, cryptography, and secure design fit together into a coherent authentication strategy, for teams designing systems, not just using them.
Signing in has changed quickly: from passwords alone, to a password plus a second check, to passwordless methods such as passkeys. If you build or choose systems, it helps to know how these pieces fit together, more than following any single trend. This guide explains each one in plain terms and what to consider when designing a sign-in system.
The options at a glance
| Method | How it works | Main weakness |
|---|---|---|
| Password alone | A secret the user remembers and types | Reused across sites, can be phished, and depends entirely on the user to be strong |
| Password plus a second factor | A second check, such as a code or an approval on your phone | The password can still be phished, and some second factors can be tricked as well |
| Passkey↗ | A cryptographic proof from your device, confirmed with a fingerprint, face, or PIN | Needs a recovery plan if devices are lost, and support varies between apps |
Passwords: a starting point, not the end
Passwords are everywhere because they are simple to build and everyone understands them. Their weaknesses are well known: people reuse them across sites, attackers trick people into typing them on fake pages, and their strength depends entirely on what each user chooses. Good design treats a password as a baseline to be layered with extra protection, not a sufficient control on its own.
Adding a second factor
A second factor is an extra proof of identity on top of the password, such as a code from an app or a prompt on your phone. It blocks many attacks that rely on a stolen password alone. But a convincing fake login page can sometimes collect both the password and the code, so a second factor reduces the risk without removing it.
Why passkeys are a bigger change
With passwords, both sides must protect a shared secret. Passkeys use public-key cryptography↗, the same idea behind secure web connections and digital signatures: the website holds only a public key, and your device proves it holds the matching private key without ever sending it. That is a different security model, not just a more convenient password.
Design principles for sign-in systems
| Principle | What it means | Why |
|---|---|---|
| Never store passwords as plain text | Use a modern, salted hashing↗ method designed for passwords, not a general-purpose one | If the database leaks, the passwords should still be unreadable |
| Keep the fallback as strong as the main method | If a device does not support passkeys, the backup↗ way in should not quietly become the easiest target | Attackers aim at the weakest route |
| Limit sign-in attempts | Slow down repeated guesses and credential stuffing↗ (trying stolen passwords on many sites) | Protection should be built in, not added later |
| Collect little personal data | Gather only what sign-in needs; systems often collect more (device details, location, behavior) | Less data held means less data that can leak |
Beyond the login screen
Signing in is only one control in a larger security design. Well-built systems assume a sign-in can eventually be bypassed or stolen, and add more layers: checks on what each user may do, monitoring, and detection of unusual behavior. A successful login should not be trusted completely for the rest of a session.
Questions to ask when choosing a sign-in approach
- What happens if a user loses their phone or their only passkey device?
- Is the backup method as secure as the main one?
- Can an attacker keep guessing without being slowed or noticed?
- If one account is stolen, how much can the attacker reach?
The best sign-in design does not rely on one perfect control. It combines several imperfect ones so that a single failure does not become a full compromise.