Identity: passwords, MFA and passkeys
Most breaches now start with someone signing in as somebody else. This lesson shows you how to protect accounts the modern way: passwords that follow current guidance, second factors ranked by how well they resist phishing, passkeys, and the recovery and leaver processes that attackers aim for when the front door is locked.
By the end you can
- Explain why accounts have become the perimeter, and tell authentication apart from authorisation
- Write a password policy that follows NIST SP 800-63B, and check new passwords against breached lists
- Rank second factors by strength, and say which ones a fake login page cannot get past
- Describe how a passkey sign-in works and why a look-alike site cannot use it
- Close the gaps around the login: help-desk resets, shared devices and staff who leave
The everyday picture
Think of a big hotel. Years ago a doorman stood at the only entrance and knew every face, so the rooms barely needed locks. Today hundreds of guests come and go through side doors, the lift, the car park and the pool. The doorman can't see most of them. What keeps a room safe now is the key card in each guest's hand and the lock on each door.
That shifts the risk to new places. A key card that opens any door is a disaster if it is copied. A card that only works for one room, and only in this hotel, is far safer. And the weakest point is often the front desk: someone walks up, says "I lost my card, I'm in room 412", and gets a new one without proving anything. Account security works the same way. The login is the door lock, the factor is the key card, and the help desk is the front desk that hands out new keys.
Accounts are the new perimeter
Not long ago, most company systems lived in one office network. A firewall at the edge was the main defence, and anyone inside was trusted. That edge is mostly gone. Mangrove Market's back office, email, code on GitHub and data warehouse all run in the cloud. Buyers approve orders from their phones. Partner shop owners order stock from their own devices. Riders sign in on personal Android phones. The only thing that stands between an attacker and those systems is the account.
That is why attackers spend so much effort on stealing sign-ins. In How breaches really happen you saw the two biggest routes: phishing, where a fake page collects what people type, and credential stuffing. Both work because a password is a secret that can be copied and replayed by anyone who learns it.
Two words get mixed up constantly, so pin them down now:
- Authentication answers "who are you?" It is the login: a password, a code, a passkey.
- Authorisation answers "what may you do?" It runs on every request after login: can this rider see refunds, can this buyer approve a $40,000 order?
This lesson is mostly about authentication, because a perfect permission system is useless when an attacker is signed in as a real buyer. Authorisation bugs are a big topic of their own in the Application Security course (Application Security).
Quick check
A rider signs in correctly with his password and code, then finds he can open the refunds screen meant for head office. Which control failed?
He proved who he is correctly, so authentication worked. The failure is in deciding what a rider may do, which is authorisation. A stronger factor would not help, because he is the real rider.