They logged in, they didn't break in, how credential attacks really work
Read the post-mortems of 2026's biggest breaches, the SaaS extortion campaigns, the telecom data thefts, and a pattern jumps out. Almost none of them started with a clever exploit. They started with a valid login. A help-desk agent talked out of a reset, an employee phished into handing over a single-sign-on token, a vendor whose access was simply inherited. As the analysts put it: attackers didn't break in, they logged in.
This is the most important security idea for a working developer, because it is unglamorous and it is where the real risk lives. The bug everyone fears is rare; the stolen credential is constant.
The one idea: a login is a claim of identity, and claims can be stolen
Authentication answers one question: are you who you say you are? Classically you prove it with something you know, a password. The whole problem is that "something you know" can be learned by someone else: guessed, reused from another breach, phished, or simply read off a sticky note. Once they know it, the system has no way to tell them from you. The door isn't forced; it's opened with a real key.
Every credential defense is an attempt to make a stolen password not enough.
Why passwords alone fail
Three failure modes, all common:
- Reuse. People use the same password across sites. One breached site leaks it, and attackers "credential-stuff" it everywhere else, automated, millions of tries.
- Phishing. A convincing fake login page captures the password (and increasingly, the second factor too) in real time.
- Predictability. Weak or common passwords fall to a dictionary attack in seconds.
Notice none of these is a software bug you can patch. They are properties of "a secret a human has to remember."
Defense 1: don't store the secret, store a fingerprint
If your database stores plaintext passwords, one breach hands attackers every account, and every reused password your users have elsewhere. So you never store the password. You store a one-way hash of it, run the same hash on login, and compare. We cover the right way to do this (salts, bcrypt) in its own post, but the principle is: even your own database should not know the password.
Defense 2: a second factor (the big one)
Multi-factor authentication adds something you have (a phone, a hardware key) to something you know. Now a stolen password alone is useless, the attacker also needs your physical second factor. MFA is the single highest-leverage control against credential attacks; most of the breaches above would have been stopped by it, or happened because it was missing or bypassable.
But not all MFA is equal. SMS codes can be phished or SIM-swapped. The strong version is phishing-resistant MFA (passkeys / WebAuthn), where the second factor is cryptographically bound to the real site's domain, so a fake login page literally cannot use it. The browser refuses to hand the credential to the wrong origin. That domain-binding is the property that kills real-time phishing.
Defense 3: assume the credential will leak, and limit the blast
Since some credential will eventually be stolen, the goal shifts to containment:
- Least privilege. An account, especially a service or vendor account, should be able to do only what it needs. The telecom breach was catastrophic because the compromised access reached everything.
- Short-lived sessions and re-auth for sensitive actions, so a stolen session token expires fast.
- Monitoring for the tells: a login from a new country, an impossible-travel pattern, a sudden bulk export. Credential attacks look like normal logins, so behavior is often the only signal.
Why this is the lesson that matters
It is tempting to spend your security attention on exotic exploits. But the data is blunt: the way in is almost always a person and a password, not a zero-day. That reframes what "being secure" means for most teams. It is less about finding the perfect bug and more about: hash passwords, turn on phishing-resistant MFA, scope every account tightly, and watch for logins that don't smell right.
The reason to understand the mechanism, that a login is a stealable claim of identity, is that every control above stops being a checkbox and becomes obvious: each one is a different answer to "make a stolen secret insufficient." That way of thinking, building the model so the defenses follow from it, is the whole approach of the cybersecurity track.