…med eksempler du kjenner
Mange tenker at “MFA” eller “tofaktorautentisering” betyr at vi er trygge. Men phishingresistent autentisering er et hakk opp, og nå spør flere tilsyn og kunder etter nettopp dette. – fordi phishingresistent autentisering er bedre enn vanlig MFA eller tofaktorautentisering.
Slik forstår du forskjellen – med eksempler du kjenner.
- Vanlig MFA (2FA/MFA) kan fortsatt lures med phishing
- Phishingresistent autentisering er laget for å tåle phishing
Under er forskjellene forklart – enkelt og praktisk – uten bruk av teknisk språk.
1) Enkel tofaktorautentisering (2FA) – «kode på SMS»
Dette er den klassiske varianten mange kjenner.
- Du logger inn med brukernavn og passord
- Du får en SMS eller en e-mail med engangskode
- Du taster koden inn, og kommer inn
Dette er en ekstra lås. Bra.
Men: Hvis du blir lurt til å logge inn på en falsk side, kan du også bli lurt til å taste inn SMS-koden der. Angriperen kan bruke den i sanntid.
2) Vanlig MFA – «godkjenn i app» (typisk Microsoft/LinkedIn)
Her kjenner mange igjen mønsteret.
- Du logger inn med brukernavn og passord
- Så kommer «Bekreft innlogging» i Authenticator-appen – eventuelt må du taste en engangskode fra appen
- Du må åpne mobilen (Face ID / pinkode) og trykke «Godkjenn»
Dette er ofte bedre enn SMS, fordi mobilen er låst og appen er knyttet til deg.
Men: Dette kan også lures i enkelte situasjoner.
- du lures til å «godkjenne» noe du tror er ekte
- du får mange push-varsler («push fatigue») og trykker OK for å bli kvitt dem
- du skriver inn engangskode på feil sted (phisingside)
Altså: MFA kan stoppe mye, men ikke alt.
3) Phishingresistent autentisering – «det virker bare på riktig sted»
Phishingresistent autentisering betyr i praksis at selv om du blir lurt til å klikke på en falsk side, skal ikke innloggingen kunne gjenbrukes av angriperen.
To eksempler gjør dette lett å forstå.
Eksempel A: BankID (det folk flest stoler på)
BankID er et godt bilde på phishingresistent «tankesett». Du identifiserer deg gjennom en løsning som er knyttet til deg, og det er vanskeligere å «kopiere» prosessen til en falsk nettside og få samme effekt.
Poenget for legfolk er at det du godkjenner er sterkere knyttet til riktig løsning enn en enkel kode du kan taste inn hvor som helst.
Eksempel B: Phishingresistent autentisering i jobbverden (passkeys / sikker nøkkel)
I arbeidsverden handler dette ofte om passkeys eller sikkerhetsnøkler. Innloggingen er «låst» til riktig tjeneste, ikke bare en kode.
Konsekvensen er at angriperen ikke får brukt «innloggingen din» på en falsk side og så logge inn i en ekte tjeneste med samme bekreftelse.
En enkel huskeregel
Hvis «faktoren» kan tastes inn som en kode (SMS eller engangskode), kan den ofte også lures ut.
Hvis innloggingen skjer ved at du bekrefter på en måte som bare fungerer mot riktig tjeneste, er du nær phishingresistent nivå.
Hvorfor dette betyr noe akkurat nå
Når Datatilsynet spør kommuner om dette i sitt brevtilsyn, er det fordi angrep i dag ofte starter med phishing mot ansatte, sosial manipulering mot helpdesk/leverandør eller konto-overtakelse der «helt vanlig MFA» ikke stopper angrepet.
Derfor blir «phishingresistent» et eget nivå opp i modenhet.
Hva vi bør gjøre nå (uten å bli tekniske)
Her er en enkel oppfordring som fungerer både for kommuner og virksomheter.
1) Spør din IT-leverandør / IKT-samarbeidspartner om dette
Be om et klart svar på:
- Hvilke av våre systemer støtter phishingresistent innlogging i dag
- Hva er planen for å innføre det i de viktigste systemene
- Hvilke brukergrupper bør få det først, basert på risiko
2) Prioriter etter risiko
Start med:
- admin-kontoer og IT-drift
- e-post/identitet (Microsoft 365 / Google)
- fjernaksess/VPN og systemer med sensitive data
Avslutning
MFA er et stort steg opp fra passord. Men når trusselbildet handler om phishing, blir spørsmålet mer og mer aktuelt.
Har vi MFA som faktisk tåler phishing?
Ta praten med IT-leverandør denne uken. Be om en plan for phishingresistent autentisering, og start der risikoen er størst.
Relatert lesning
Phishingresistent innlogging henger tett sammen med leverandørstyring og tydelige roller. Les også fagartikkelen vår om databehandleravtalen – døråpneren til gjensidig forståelse av personvernet.
