Beskytt innlogging mot brute force og credential stuffing

«Brute force» brukes ofte om alle automatiserte innloggingsforsøk. Det skjuler viktige forskjeller. En angriper som gjetter mange passord på én konto må oppdages annerledes enn en angriper som prøver ett vanlig passord mot tusen brukere.

Målet er ikke bare færre forsøk. Innloggingen skal:

• gjøre gjettede og lekkede passord lite nyttige
• oppdage angrep som fordeles over mange IP-er og kontoer
• unngå at angriperen kan låse offeret ute med vilje
• gi legitime brukere en sikker vei tilbake
• bevare nok data til å forstå og stanse hendelsen

Hvilket angrep ser dere?

Rate limiting per konto bremser målrettet gjetting, men password spraying kan ligge under hver kontogrense. En ren IP-grense kan omgås med distribuerte nettverk og kan blokkere mange ansatte bak samme bedriftsnett.

Prioriter autentisering som ikke kan gjenbrukes

Et passord kan tastes inn på feil nettsted og gjenbrukes av en angriper. WebAuthn-baserte passnøkler og sikkerhetsnøkler binder autentiseringen til riktig tjeneste og gir phishing-resistens som vanlige passord og engangskoder ikke har.

For administratorer, e-post, økonomi, registrar og andre kritiske kontoer bør virksomheten prioritere phishing-resistent MFA eller passnøkkel når leverandøren støtter det. Les hvordan passnøkler fungerer og innføres .

Andre faktorvalg har fortsatt verdi, men ulik risiko:

• En sikkerhetsnøkkel eller riktig implementert passnøkkel er phishing-resistent.
• TOTP fra autentiseringsapp beskytter mot gjenbrukt passord, men koden kan fortsatt phishes i sanntid.
• Push med tydelig kontekst og nummermatching er bedre enn en enkel «godkjenn»-knapp, men må beskyttes mot fatigue.
• SMS kan være bedre enn bare passord, men er utsatt for blant annet sosial manipulering, SIM-bytte og svak gjenoppretting.

Ikke fjern en eksisterende andre faktor før den sikrere metoden er innført, testet og har en reservevei. En teoretisk sterk løsning hjelper ikke hvis ansatte omgår den fordi gjenoppretting ikke virker.

CISA anbefaler phishing-resistent MFA for virksomheter og peker på nummermatching som et mellomsteg for push-løsninger.

Passordpolicy som støtter vernet

For tjenester som fortsatt bruker passord:

• tillat lange passord og mellomrom
• la brukere lime inn fra passordbehandler
• sammenlign nye passord mot vanlige, forventede og kjente kompromitterte verdier
• ikke krev bestemte blandinger av store bokstaver, symboler og tall som bare skaper forutsigbare mønstre
• ikke krev periodisk bytte uten mistanke, hendelse eller annet konkret behov
• lagre passord saltet med en egnet, kostbar passordhash og en kostfaktor som kan økes over tid
• aldri logg, send eller lagre passord i klartekst

NIST SP 800-63B-4 krever minst 15 tegn når passordet brukes som eneste faktor i systemer som følger standarden. Når passordet bare er én del av flerfaktor, er minimum åtte. Standarden forbyr andre tvungne komposisjonsregler og krever blocklist mot vanlige, forventede og kompromitterte passord.

NIST-kravene gjelder bestemte amerikanske føderale identitetssystemer og er ikke automatisk norsk lov eller riktig risikonivå for alle tjenester. De er likevel et bedre teknisk utgangspunkt enn den gamle oppskriften med åtte tegn, symbolkrav og tvungent bytte hver 90. dag.

Et unikt passord fra en passordbehandler reduserer credential stuffing fordi lekkasjen fra én tjeneste ikke kan brukes direkte på en annen. Blocklist reduserer sannsynligheten for at brukeren velger en verdi angriperen prøver tidlig.

Begrens forsøk på flere dimensjoner

En innloggingsgrense bør minst vurdere:

1. Per konto eller autentikator: Stopper mange forsøk mot samme mål på tvers av IP-er.
2. Per kilde eller enhetssignal: Oppdager én klient som prøver mange kontoer.
3. Per nettverk eller risikogruppe: Fanger koordinert trafikk uten å behandle alle land eller operatører likt.
4. Globalt og per endepunkt: Beskytter samlet kapasitet og leverandørkvoter.
5. Per handling: Passord, engangskode, push, gjenoppretting og ny faktor trenger egne tellere.

Ikke bruk rå e-post eller brukernavn som offentlig rate-limit-nøkkel eller i unødvendige logger. Bruk intern konto-ID eller en egnet avledning. Stol bare på klient-IP-headere når den kontrollerte proxyen faktisk setter dem og origin ikke kan omgås.

Bruk gradvis friksjon

En mulig trapp er:

Ventetid kan økes fra sekunder til minutter etter mønster og risiko. Legg til jitter slik at angripere ikke kan synkronisere nøyaktig, og slik at responstid ikke blir et enkelt signal om kontostatus.

En permanent kontolås etter tre eller fem feil lar hvem som helst nekte offeret tilgang. Hvis en autentikator må deaktiveres etter en øvre grense, må en annen sterk faktor eller dokumentert gjenoppretting kunne brukes. Sett lavere operative grenser og forsinkelser lenge før et absolutt tak.

NISTs grense på 100 sammenhengende mislykkede forsøk per autentikator/konto er et øvre tak i den standarden, ikke en anbefaling om å tillate 100 raske forsøk. NIST åpner for lavere grenser, økende ventetid, bot-utfordring og risikobasert vurdering for å redusere både gjetting og angriperstyrt kontolås.

Bruk den generelle rate limiting-guiden for algoritmer, proxyhåndtering, 429 og distribuerte tellere.

CAPTCHA og Turnstile er et lag, ikke identitet

En bot-utfordring kan gjøre automatisering dyrere og beskytte innloggingskapasitet. Den viser ikke at brukeren har rett til kontoen, og dyktige angripere kan passere eller sette bort utfordringen.

Aktiver utfordring adaptivt ved misbruk hvis det gir bedre brukeropplevelse enn å vise den til alle. Serveren må validere token, forventet hostname, handling, utløp og engangsbruk etter leverandørens modell. Et klientmerke alene gir ingen sikkerhet.

Passord, faktor og kontogrense må fortsatt håndheves på serveren etter at utfordringen er godkjent.

Unngå brukeropplisting

Følgende svar avslører kontostatus:

• «Ukjent e-postadresse» mot «Feil passord»
• ulik HTTP-status for eksisterende og ukjent konto
• synlig ulik responstid fordi bare eksisterende konto kjører passordhash eller sender melding
• passordreset som bekrefter mottaker før e-post er sendt
• registrering som uten videre sier at en bestemt person har konto

Bruk et generisk svar som «Innloggingen kunne ikke bekreftes» og «Hvis adressen er registrert, sendes en melding». Det betyr ikke at loggene skal være generiske: internt må dere skille ukjent bruker, feil passord, faktorfeil, sperret autentikator og risikobeslutning.

Jevn ut behandlingsflyten der det er praktisk. Ikke legg inn lange kunstige forsinkelser som blir en egen ressursangrepsflate. Mål faktisk timing fra flere nettverk og kontoer.

Beskytt MFA mot fatigue og ombinding

For push-basert MFA:

• begrens antall forespørsler per konto, enhet og kilde
• vis tjeneste, omtrentlig sted, tidspunkt og handling der det er forsvarlig
• bruk nummermatching eller annen brukerinteraksjon fremfor enkel godkjenning
• la brukeren rapportere et uventet forsøk og stans nye forespørsler
• ikke send en endeløs serie push-varsler automatisk
• logg hvem som startet binding av ny faktor og hvordan den ble godkjent

En angriper med passordet kan forsøke å registrere en ny faktor, endre telefonnummer eller generere gjenopprettingskoder. Slike livssyklushandlinger bør kreve nylig sterk autentisering og varsles gjennom en eksisterende kontrollert kanal.

Gjenoppretting må være minst like sterk

Kontogjenoppretting er ofte den egentlige innloggingsveien for en angriper. Kontroller:

• at reset-token er tilfeldig, kortlivet, engangs og bundet til riktig handling
• at nye tokenforespørsler ikke sender ubegrenset e-post eller SMS
• at token ikke havner i logger, analyse eller referrer
• at gammel økt og relevante reset-token kan tilbakekalles etter passordbytte
• at bytte av faktor, e-post eller telefon har strengere kontroll enn vanlig profilendring
• at support ikke kan fjerne MFA bare på grunnlag av offentlig foretaksinformasjon
• at brukeren varsles om vesentlige endringer gjennom en tidligere kjent kanal

Sikkerhetsspørsmål med svar som kan finnes, gjettes eller kjøpes, er ikke en sterk autentiseringsfaktor. Hvis de fortsatt finnes i en eldre løsning, må forsøk begrenses og svarene lagres som hemmeligheter, men planen bør være å erstatte dem.

Sikre økten etter vellykket innlogging

Sterk innlogging hjelper ikke hvis sesjonen er svak.

• bruk Secure, HttpOnly og riktig SameSite på session-cookie
• roter økt-ID ved innlogging og rettighetsendring
• sett absolutt og inaktiv levetid etter risiko
• krev ny eller sterkere autentisering for betaling, ny faktor og andre kritiske handlinger
• gi brukeren oversikt og mulighet til å avslutte andre økter der produktet støtter det
• tilbakekall økter ved bekreftet kontoovertakelse
• ikke lagre langlivede tokens i nettleserlagring uten en eksplisitt trusselvurdering

Oppdag «impossible travel» og ukjente enheter som signaler, ikke absolutte bevis. VPN, mobilnett og IP-geolokasjon kan gi falske avvik.

Logger og varsler som kan brukes

Logg minst:

• tidspunkt med tidssone og hendelsestype
• pseudonymisert eller intern konto-ID
• resultat og årsakskode
• faktor og autentiseringsnivå, uten hemmelig output
• kontrollert kilde-/nettverksinformasjon og enhetssignal der det er lovlig og nødvendig
• hvilken rate-limit- eller risikoregel som slo inn
• binding, endring og fjerning av autentikator
• opprettelse og bruk av gjenoppretting

Ikke logg passord, engangskoder, reset-token, session-cookie eller private nøkler. Begrens tilgang og oppbevaring etter formål.

Varsle på mønstre:

• samme passordmønster eller kilde mot mange kontoer
• samme konto fra mange kilder
• høy andel feil etterfulgt av én suksess
• vellykket innlogging etter langvarig spraying
• ny faktor, ny gjenopprettingskanal eller nye økter rett etter et avvik
• stor økning i reset- eller push-utsending

Et varsel per mislykket innlogging skaper støy. Samle hendelser i et forståelig angrepsbilde med ansvarlig oppfølging.

Test uten å bare telle feil

Testplanen bør dekke:

1. mange passord mot samme konto
2. ett passord mot mange kontoer
3. samme lekkede legitimasjon fra mange IP-er
4. mange legitime brukere bak samme IP
5. IPv6- og mobilnett som skifter adresse
6. brukeropplisting gjennom tekst, status, størrelse og timing
7. kontolås og trygg vei tilbake uten svak supportomgåelse
8. gjentatt MFA-push, OTP og reset-utsending
9. vellykket innlogging etter feil og korrekt nullstilling av relevante tellere
10. sesjonsrotasjon, tilbakekalling og kritisk step-up

Test også hva som skjer når rate-limit-lager, e-postleverandør eller risikomotor er utilgjengelig. Definer på forhånd hvilke handlinger som skal feile lukket, og hvilke som kan fortsette med kompenserende kontroll.

Hva dette betyr for Vymo

Vymo.no har ingen kundepålogging, selvbetjent registrarportal eller publisert administrasjonskonto med MFA. Bestillingsskjemaene er ikke et autentiseringssystem. De bruker opprinnelseskontroll, servervalidert Turnstile, Brønnøysund-kontroll, feltgrenser og rate limiting for å redusere automatisert innsending.

Det betyr at Vymo ikke skal bruke denne artikkelen til å antyde funksjoner som passnøkkel, kontolås, øktoversikt eller flerfaktor i et produkt vi ikke tilbyr på nettstedet. Virksomheter som kjøper e-post eller bruker tredjeparts innlogging må kontrollere hvilke autentiserings- og gjenopprettingsfunksjoner den konkrete leverandøren faktisk har.

For Vymos egne interne kontoer gjelder samme prioritering som for andre virksomheter: sterk, helst phishing-resistent autentisering på e-post, Cloudflare, kodeplattform og andre administrative kontrollpunkter, med dokumentert reserve og gjenoppretting.