Stoppa credential stuffing vid edge

Credential stuffing

-attacker använder automatiserade verktyg för att testa stulna kombinationer av användarnamn och lösenord mot inloggningssidor. Attackerna är enorma — en enskild operatör kan testa miljontals inloggningsuppgifter per dag över hundratals målsajter. Traditionella försvar som rate limiting och CAPTCHA:er är otillräckliga eftersom angripare fördelar sina förfrågningar över tusentals IP-adresser och använder tjänster som löser CAPTCHA:er. Så här stoppar vi credential stuffing vid edge, innan förfrågningarna når ditt autentiseringssystem.

Attackytan

En typisk credential stuffing-operation använder en lista med stulna inloggningsuppgifter (tillgängliga på marknadsplatser på dark web för så lite som 10 dollar per miljon poster), ett automatiseringsverktyg (vanligtvis ett eget skript eller ett verktyg som OpenBullet) och en pool av proxy-IP:n (residential proxies som roterar vid varje förfrågan för att undgå IP-baserad rate limiting).

Angriparen konfigurerar sitt verktyg att skicka inloggningsförfrågningar i en kontrollerad takt — långsamt nog för att undvika att utlösa enkla rate limits, men snabbt nog för att testa tusentals inloggningsuppgifter per timme. Varje förfrågan kommer från en annan IP-adress, med en annan user agent-sträng, vilket får det att se ut som en ström av legitima inloggningsförsök från olika användare.

Varför rate limiting misslyckas

IP-baserad rate limiting är den första försvarslinjen de flesta team inför, och den är den första som brister. Tjänster med residential proxies ger tillgång till miljontals verkliga IP-adresser — hemmaroutrar, mobila enheter och IoT-enheter — som roterar vid varje förfrågan. Ur serverns perspektiv kommer varje inloggningsförsök från en unik residential IP utan någon historik av missbruk.

Kontobaserad rate limiting (som begränsar inloggningsförsök per användarnamn) är effektivare men skapar en möjlighet till denial of service: en angripare kan låsa ute legitima användare genom att avsiktligt misslyckas med flera inloggningsförsök mot deras användarnamn.

Device fingerprinting som grund

Device fingerprinting ändrar spelplanen eftersom den identifierar enheten som kör attacken, inte den IP den använder. Ett credential stuffing-verktyg som körs på en enda maskin eller en VM-farm producerar ett konsekvent device fingerprint över alla sina förfrågningar, oavsett vilken proxy-IP det roterar genom.

Vår Bot Detection-motor identifierar automatiseringsverktygen i sig. Selenium lämnar navigator.webdriver-artefakter. Puppeteer och Playwright har distinkta egenskaper i JavaScript-runtimen. Headless Chrome saknar specifika webbläsar-API:er som Chrome med gränssnitt inkluderar. Även egna HTTP-klienter som inte kör JavaScript upptäcks genom TLS-fingerprinting — deras Client Hello-meddelanden avslöjar det underliggande HTTP-biblioteket.

Hastighetsspårning per enhet

När vi väl har en stabil enhetsidentifierare (via Device Identification) kan vi tillämpa hastighetskontroller på enhetsnivå i stället för på IP-nivå. Om en enda enhet försöker logga in 50 gånger på 5 minuter — oavsett hur många olika IP-adresser dessa förfrågningar kom från — är mönstret otvetydigt credential stuffing.

Vår IP Intelligence-modul spårar hastighet över tre tidsfönster: 5 minuter, 1 timme och 24 timmar. Detta tillvägagångssätt med flera fönster fångar både aggressiva attacker (hundratals försök per minut) och långsamma, lågintensiva attacker (några få försök per timme som pågår över dagar).

Analys av beteendesignaler

Utöver bot detection och hastighetsspårning granskar vår Smart Signals-analys beteendesignaler som skiljer automatiserade attacker från legitima inloggningar. Verkliga användare uppvisar naturlig variation i timing av förfrågningar, skrivhastighet och navigeringsmönster. Automatiserade verktyg tenderar att producera mekaniskt konsekvent timing, identiska förfrågningshuvuden och inga muspekarrörelser eller scroll-händelser.

Vi kontrollerar också inkonsekvenser i signalerna som tyder på förfalskning av miljön. En webbläsare som utger sig för att vara Chrome på macOS men presenterar WebGL-parametrar som associeras med en Linux-VM flaggas omedelbart. En user agent-sträng som inte matchar TLS-fingeravtrycket utlöser en manipulationsvarning.

Utrullning vid edge

Nyckeln till att stoppa credential stuffing är att stoppa den innan den når ditt autentiseringssystem. Vår agent laddas på inloggningssidan och samlar in signaler under sidladdningen — innan användaren (eller boten) skickar in sina inloggningsuppgifter. Resultaten från fingerprint och bot detection är tillgängliga när inloggningsformuläret skickas, vilket gör att din server kan avvisa automatiserade försök omedelbart.

För mål med hög volym rekommenderar vi att man rullar ut vår integration för Cloudflare Worker eller CloudFront Lambda@Edge, som kör fingerprint-validering vid CDN-edge. Detta innebär att credential stuffing-förfrågningar blockeras vid den edge-nod som är närmast angriparen och aldrig når dina origin-servrar.

Resultat

Våra kunder rapporterar en minskning på 99 % av volymen credential stuffing efter att de rullat ut tracio.ai på sina inloggningssidor. De återstående 1 % består av mycket sofistikerade attacker som använder full webbläsarautomatisering med noggrant förfalskade signaler — vilka fångas av vår detektering med flera metoder inom de första dussintalen förfrågningar när hastighetsmönster framträder.