Als het wachtwoord al gestolen is

De meest voorkomende manier om binnen te komen in een webapplicatie is geen slimme exploit. Het is een correct wachtwoord, getypt door de verkeerde persoon. Hergebruikt over sites, gelekt in andermans datalek, en opnieuw afgespeeld tegen jouw login tot er een werkt.

Dit is credential stuffing, en het werkt omdat mensen wachtwoorden hergebruiken en omdat de meeste inlogformulieren een onbeperkt aantal gokken accepteren zonder morren. Een aanvaller brute-forcet geen enkel account. Hij neemt een lijst van een miljoen bekende e-mail-wachtwoordparen en probeert er elk één keer, stilletjes, telkens vanaf een ander adres.

Het inlogformulier is niet de fout

Er is niets mis met het wachtwoordveld. De credentials zijn echt. De fout is dat de applicatie de vorm van de aanval nooit opmerkt: duizenden inlogpogingen, elk met een ander geldig ogend e-mailadres, de meeste mislukt, een paar raak.

POST /login   alice@example.com : hunter2      -> 401
POST /login   bob@example.com   : password1    -> 401
POST /login   carol@example.com : letmein       -> 200   <- een raak
...  1.000.000 paren, elk een poging, geen limiet geraakt

Geen enkel request is verdacht. Samen zijn ze de hele aanval, en een applicatie die per account limiteert in plaats van per bron ziet het nooit, want geen account wordt twee keer geprobeerd.

Wat we testen

We testen of de login, de wachtwoordreset en de multifactorstap één bron duizenden pogingen laten doen. We controleren of een mislukte login en een onbekend e-mailadres verschillende antwoorden geven, want dat verschil geeft een aanvaller een lijst van welke accounts de moeite waard zijn. We testen of multifactor overgeslagen, opnieuw afgespeeld of uitgezet kan worden vanaf een endpoint dat vergat te vragen wie er belde.

Daarna kijken we voorbij de voordeur, naar wat een geslaagde login waard is. Overleeft de sessie die hij uitgeeft een wachtwoordwijziging? Kan hetzelfde token vanaf twee plekken tegelijk gebruikt worden? Een gestolen wachtwoord is het begin; de schade hangt af van hoeveel één geldige sessie wordt vertrouwd, en voor hoe lang.

resetcode 5 keer geaccepteerd        -> herbruikbaar
MFA-endpoint /disable, geen her-auth -> bypass
sessie nog geldig na wachtwoordwijziging  -> gestolen toegang blijft

Je kunt niet voorkomen dat mensen wachtwoorden hergebruiken. Je kunt voorkomen dat een miljoen gokken niets kost.

De oplossing is geen strenger wachtwoordbeleid, dat vooral je echte gebruikers straft. Het zijn limieten die pogingen over bronnen heen tellen, antwoorden die niet verraden welke accounts bestaan, een multifactorstap die niet te omzeilen is, en sessies die eindigen wanneer ze horen te eindigen. We testen elk daarvan tegen jouw applicatie en vertellen je welke gok, op welk endpoint, de aanvaller gratis krijgt.