It-sikkerhedstekst ST10 Beskyttelse af login imod forsøg på at gætte adgangsgivende faktorer Denne tekst må kopieres i sin helhed med kildeangivelse. Dokumentnavn: ST10 Version 1 Maj 2016
Beskyttelse af login imod forsøg på at gætte adgangsgivende faktorer Persondata skal beskyttes imod at blive tilgået, ændret, slettet eller på anden måde behandlet af uautoriserede personer. En uautoriseret person er en fysisk person, der ikke har en autorisation (officiel tilladelse) til at behandle de specifikke persondata. Samtidig skal de autoriserede personer (personer der har officiel tilladelse) kunne behandle de specifikke persondata. Udelukkelse af de uautoriserede personer sker normalt ved at implementere en fysisk og/eller elektronisk barriere. En fysisk barriere kan fx være, at persondata findes på et computernetværk, og dette net udelukkende kan tilgås, hvis man har fysisk adgang til en aflåst bygning. En elektronisk barriere kan fx være et login. Uden tilstrækkelig omtanke vil en elektronisk barriere i form af et login kunne forceres ved at man prøver sig frem, indtil man finder den adgangsgivende faktor. Et sådant login vil ikke beskytte persondata imod at blive behandlet af uautoriserede personer. Denne tekst handler om beskyttelsen imod, at adgangsgivende faktorer anvendt i login, kan findes ved at prøve sig frem. Teksten beskriver risici og giver råd og eksempler på modforanstaltninger. "Brute-Force-angreb" på login ENISA 1 beskriver Brute Force som "A trial-and-error method used to obtain information such as login credentials, automated software is used to generate a large number of consecutive guesses as to the value of the desired data." 2 I denne tekst betegnes angreb ved anvendelse af den omtalte "trial-and-error" metode som "Brute-Force-angreb". Et Brute-Force-angreb kan gå ud på, at man prøver sig frem til den adgangsgivende faktor i et login. Angrebet kan fx udføres ved at afprøve alle mulige udgaver af en adgangskode til et login, indtil den rigtige kode er fundet, og der derved kan foretages login. Men man kan også starte med eller udelukkende afprøve de mest sandsynlige udgaver af koden, fx de koder som statistisk set vælges ofte. Brute-Force-angreb på et login kan også anvendes ved andre typer af adgangsgivende faktorer, end adgangskoder. Angrebet er typisk automatiseret, men kan også ske manuelt. 1 European Union Agency for Network and Information Security. 2 Side 55 i "Threat Landscape and Good Practice Guide for Internet Infrastructure - January 2015" Catalogue number: TP-05-14-012-EN-N ISBN: 978-92-9204-098-7 DOI: 10.2824/34387 1
Foranstaltninger imod Brute-Force-angreb Eksempel 1: Figur 1 illustrerer et scenarie hvor Birthe kan foretage login og se sin egen sygejournal. Der er tale om et to-faktor-login 3. Andre end Birthe har mulighed for at forsøge at prøve sig frem til den rette kombination af bruger-id, adgangskode og engangskode, og dermed skaffe sig adgang til Birthes sygejournal. Figur 1 Som modtræk til Brute-Force-angreb, er det relevant at overveje følgende: 1. Begrænsning af hvorfra der kan udføres Brute-Force-angreb på login. I eksempel 1 svarer det til, at man ikke kan prøve sig frem til de adgangsgivende faktorer i Birthes login, med mindre det sker fra fx et specifikt netværk eller en pc med et specifikt certifikat installeret. 2. Foranstaltninger imod at et Brute-Force-angreb på login resulterer i uautoriseret login. I eksempel 1 svarer det til, at hvis nogen prøver sig frem til de adgangsgivende faktorer, så forsøges det standset, inden det resulterer i uautoriseret login til Birthes sygejournal. 3. Foranstaltninger imod at et Brute-Force-angreb på login resulterer i manglende adgang for de autoriserede brugere. I eksempel 1 svarer det til beskyttelse imod, at Birthe afskæres fra at foretage login og se sin egen sygejournal. Disse tre typer af modtræk er uddybet i de følgende afsnit. Overskrifterne har et rødt nummer, der refererer til ovenstående liste. 3 Se teksten "ST1 Flere faktorer i login". 2
1. Begrænsning af hvorfra der kan udføres Brute-Force-angreb på login Ved at begrænse adgangen til en login-funktion kan man gøre det sværere at udføre Brute- Force-angreb på dette login. Hvis man fx fysisk isolerer det netværk, hvorfra der kan foretages login, vil en ondsindet person, som ikke har fysisk adgang til netværket (ikke kan koble sig til netværket med et fysisk kabel), være forhindret i lave Brute-Force-angreb på login. Fysisk isolering af netværk er dog ikke særligt udbredt, så typisk vil en sådan begrænsning ske med andre midler. Eksempler på andre begrænsninger er, når login udelukkende kan foretages fra enheder (pc, smartphone, osv.), som: har en foruddefineret netværksadresse, og/eller har et specifikt personligt certifikat installeret. Hvor godt sådanne begrænsninger beskytter imod, at et Brute-Force-angreb kan finde sted, afhænger blandt andet af følgende: Hvorvidt man implementerer én begrænsning eller flere begrænsninger i kombination. I hvilken kontekst begrænsningen implementeres, fx om det kombineres med sikring og overvågning af det netværk, hvor login-funktionen befinder sig. Hvor svært det vil være at omgå begrænsningen, fx hvor svært det er at stjæle det nødvendige certifikat. Eksempel 2: Medarbejdere i en virksomhed har et login til virksomhedens interne it-systemer. Login-forsøg kan kun foretages fra en pc, der i forvejen er koblet til virksomhedens netværk. En pc kan opnå adgang til virksomhedens netværk via en firewall eller via fysisk adgang til netværksstik i virksomhedens lokaler. Såfremt pc'ens adgang til netværket sker via firewall, afkræves der først en validering af, om et specifikt certifikat er installeret på den pc, der forsøger at få adgang til netværket. Certifikaterne udstedes af virksomheden under kontrollerede forhold, der beskytter imod tyveri af certifikaterne. For at beskytte adgangen til itsystemerne via netværksstik i virksomhedens lokaler, sikres dørene til virksomheden ekstra godt med låse og alarmer. Eksempel 2 viser, hvorledes flere foranstaltninger i kombination kan gøre det sværere for en ondsindet person at udføre et Brute-Force-angreb, fordi selve login-funktionen er svært tilgængelig. 2. Foranstaltninger imod at et Brute-Force-angreb på login resulterer i uautoriseret login Når login-funktionen skal beskytte imod et succesfuldt Brute-Force-angreb, handler det primært om at øge sandsynligheden for, at angrebet opdages og stoppes, inden det ender i et succesfuldt login. Derfor kan det kan have en it-sikkerhedsmæssig betydning, hvis man gør det mere tidskrævende at udføre Brute-Force-angreb, idet der så er mere tid til at opdage og stoppe angrebet. At gøre et Brute-Force-angreb mere tidskrævende kan fx handle om at forsinke det enkelte login-forsøg eller øge antallet af mulige udgaver af den adgangsgivende faktor. Man kan endvidere gøre sværere for den ondsindede person at automatisere Brute-Force-angrebet. Typiske foranstaltninger til sikring imod, at et Brute-Force-angreb på login resulterer i uautoriseret login, er beskrevet i afsnit 2a-2g. 3
2a. Foranstaltninger der indebærer forsinkelser i login Man kan gøre det mere tidskrævende at gennemføre et Brute-Force-angreb ved følgende tiltag: Login-funktionen laves, så hvert forgæves login-forsøg resulterer i, at der går længere og længere tid, inden det er muligt at foretage et nyt login-forsøg. 4 Efter et antal forgæves login-forsøg spærres adgangen helt. Det er herefter nødvendigt for brugeren at kontakte brugeradministrationen, som manuelt skal åbne adgangen, før der kan udføres flere login-forsøg. 2b. Foranstaltninger der indebærer spærring af brugeradgang Et tegn på Brute-Force-angreb er fx, når samme bruger-id afgives i login gentagne gange, men i kombination med forskellige forkerte faktorer. Men en ondsindet person kan også forsøge sig med forskellige faktorer i kombination med forskellige bruger-id'er. Begge dele fordrer, at der på et tidspunkt reageres og brugeradgangen spærres for flere forsøg. Eksempel 3: En virksomhed har 1000 it-brugere med hver deres bruger-id. Der gives 5 forsøg på at afgive en adgangskode tilknyttet en specifik bruger-id, hvorefter adgangen med denne bruger-id er spærret i ti minutter. Genåbning efter de ti minutter sker automatisk. En ondsindet person vil have 5000 forsøg på at gætte en korrekt kombination af bruger-id og adgangskode. Når brugeradgangene efter ti minutter ikke længere er spærret, er der yderligere 5000 forsøg. Den ondsindede person har med andre ord rig mulighed for at prøve sig frem, på trods af spærringen. Her følger nogle eksempler på tiltag, som er relevante at overveje: a) Adgangen for en bruger-id spærres, såfremt denne bruger-id er blevet anvendt i sammenhæng med en forkert faktor et vist antal gange, uden der ind i mellem har været et succesfuldt login. b) Adgangen for en bruger-id spærres, såfremt denne bruger-id er blevet anvendt i sammenhæng med en forkert faktor et vist antal gange samlet set (altså uafhængigt af, om der er ind i mellem har været et succesfuldt login). Dette kan anvendes til at detektere længerevarende Brute-Force-angreb, som sker ind i mellem den autoriserede brugers succesfulde login. c) Enheder (pc, smartphone, osv.) eller netværksadresser spærres, såfremt der fra disse sker et vist antal forgæves login-forsøg med skiftende bruger-id'er uanset om det er valide eller ikke-valide bruger-id'er. d) Automatisk alarmering og menneskelig indgriben ved spærret bruger-id, enhed eller netværksadresse. e) Automatisk genåbning af spærret bruger-id/enhed/netværksadresse kan kun ske et begrænset antal gange. f) Manuel genåbning af en spærret bruger-id/enhed/netværksadresse sker ved henvendelse til en brugeradministrator. Det er på forhånd beskrevet, præcist hvor godt og hvorledes 4 Denne metode betegnes af nogen med det engelske begreb "Tarpitting". 4
den fysiske person, der henvender sig til brugeradministratoren, skal identificeres, inden der må genåbnes. 5 Hvor mange forgæves login-forsøg, der bør tillades før spærring af brugerid/enhed/netværksadresse (punkt a, b og c), afhænger af, hvor mange gange der sker automatisk genåbning (punkt e). Jo flere gange der kan ske automatisk genåbning, desto flere forgæves login-forsøg tillades samlet set. Hvor mange forgæves login-forsøg, der bør tillades samlet set, afhænger af, hvor mange potentielle udgaver der kan være af faktoren. Sandsynligheden for at gætte faktoren inden for det tilladte antal forgæves adgangsforsøg er umiddelbart større, jo færre potentielle udgaver der kan være af faktoren. Eksempelvis kan koder bestående af otte cifre, store eller små bogstaver have 218.340.105.584.896 kombinationer 6, mens en PIN-kode bestående af fire cifre maksimalt har 10.000 kombinationer. 2c. Organisatoriske foranstaltninger Forsinkelse i login, spærring af brugeradgang og involvering af brugeradministrationen for genåbning af bruger-id, er eksempler på tiltag, som kan øge sandsynligheden for, at den autoriserede bruger og/eller brugeradministrationen i tide opdager forsøg på uautoriseret adgang. Det forudsætter imidlertid, at brugere og/eller brugeradministratorer er blevet instrueret i at være opmærksomme på indicierne for et igangværende Brute-Force-angreb. Det er værd at bemærke, at intelligent udførte Brute-Force-angreb muligvis kan ske ubemærket af brugeren, fx hvis forsøg på login sker på en måde, der aldrig medfører, at brugeren bliver berørt af den automatiske spærring af bruger-id. 2d. Foranstaltninger vedrørende adgangskoder og engangskoder Et Brute-Force-angreb kan starte med en afprøvning af forudsigelige koder, så som "Sommer2016", "qwerty1234" eller "5tgbnhy6". 7 Det kan resultere i succesfuldt login efter ganske få login-forsøg, og dermed kan de tidligere beskrevne tiltag være utilstrækkelige. På den anden side kan man ikke bare stramme sikkerheden ved at spærre brugeradgangen efter ganske få forgæves login-forsøg, fordi det kan få negative konsekvenser for de autoriserede brugere. I stedet bør man så vidt muligt forhindre anvendelsen af forudsigelige koder. Når adgangskoden vælges af brugeren selv, kan man beskytte imod forudsigelige adgangskoder, ved til en vis grad at styre valget af kode. Login-funktionen kan fx kræve, at brugeren vælger en adgangskode, der opfylder følgende krav: Koden har en vis minimumslængde. Koden indeholder forskellige typer af tegn cifre, store bogstaver, små bogstaver, specialtegn (fx: # % & = + * ). Der er et maksimum på, hvor mange gange det samme tegn kan indgå i koden. 5 Se afsnittet "Glemt faktor" i teksten "ST7 Overdragelse af faktorer ved udstedelse af et personligt login til en identificeret fysisk person". 6 Antallet af kombinationer er fået ved at sige 62 opløftet i 8 (62 8 ). Dette er afhængigt af antallet af tegn i det anvendte alfabet/talsystem. Antallet af kombinationer kan ydermere begrænses af regler, som skal sikre kompleksitet i koden, fx hvis der er en regel om, at det samme tegn højst kan indgå to gange. 7 "qwerty1234" og "5tgbnhy6" er eksempler på tegn, der ligger i rækkefølge på et standard tastatur, og derfor ofte anvendes i den fejlagtige tro, at det er en kode, som er svær at gætte. 5
Koden er ikke identisk med bruger-id. Koden er ikke identisk med en tidligere anvendt kode. Koden fremgår ikke af en liste over almindelige ord eller gængse dårlige adgangskoder. Brugerne bør altid informeres om, hvad der kendetegner en god adgangskode, og hjælpes med råd om hvordan man vælger en kompleks kode, som kan huskes i hovedet. Engangskoder kan være mål for Brute-Force-angreb på samme måde som personlige adgangskoder. Engangskoder er normalt genereret af et it-system, men kan alligevel være forudsigelige, også selv om de ser tilfældige ud. Derfor bør det sikres, at it-systemet genererer helt tilfældige engangskoder, så en kode ikke kan forudsiges, fx ud fra kendskab til de forrige koder eller ud fra kendskab til it-systemet, som genererer engangskoderne. 2e. Foranstaltninger vedrørende bruger-id Én eller flere adgangsgivende faktorer afgives typisk i sammenhæng med en bruger-id, og denne bruger-id kan spille en rolle i, hvor svært det er at lave Brute-Force-angreb. En ondsindet person kan eventuelt benytte it-systemets funktionalitet til at danne en liste over valide bruger-id'er 8, og det kan gøre det videre Brute-Force-angreb nemmere. En liste over valide bruger-id'er kan eventuelt opbygges, hvis it-systemet reagerer forskelligt ved login-forsøg med validt og ikke-validt bruger-id. Hvis dette undgås, kan man derved gøre det sværere at udføre Brute-Force-angreb. 2f. Foranstaltninger ved flere faktorer/trin i login Et login kan kræve én eller flere faktorer afgivet i ét eller flere trin. For at beskytte imod Brute- Force-angreb, er det relevant at vurdere risici og mulige modforanstaltninger i forhold til hver faktor og hvert trin i login. Eksempel 4: Et login består af to faktorer afgivet i to trin: Trin et: Afgivelse af den ene faktor beståede af en personlig adgangskode. Trin to: Afgivelse af den anden faktor bestående af en engangskode fra en kodeviser 9. Et to-faktor-login kan øge sikkerheden, ved at visse trusler kun kan ramme den ene af de to faktorer 10. Det er også tilfældet i eksempel 4, fordi: 11 Malware på en pc kan give uvedkommende mulighed for at opsnappe den personlige adgangskode og engangskoden, mens de indtastes. Malwaren kan imidlertid ikke opsnappe fremtidige engangskoder fra kodeviseren, og dermed giver de opsnappede informationer ikke i sig selv mulighed for at foretage login i fremtiden. En bortkommet/stjålet kodeviser kan give uvedkommende adgang til fremtidige engangskoder, men ikke til den personlige adgangskode med mindre adgangskoden fx er skrevet på kodeviseren. 8 Denne teknik betegnes af nogen med det engelske begreb "Username harvesting". 9 En kodeviser kan også gå under betegnelser som nøgleviser, kodegenerator, token, electronic keyring, med videre. I eksemplet her hentydes til en fysisk enhed, der ved tryk på en knap afgiver en engangskode. 10 Se teksten "ST1 Flere faktorer i login". 11 "Malware" er en fællesbetegnelse for ondsindet software, som fx virus, orme, trojanske heste, med videre. 6
Hvis man i eksempel 4 udelukkende laver modforanstaltninger imod Brute-Force-angreb på det første trin i login, kan en ondsindet person benytte malware for at få fat på adgangskoden til det første trin, og derefter udføre et Brute-Force-angreb imod det andet trin. Eksempel 4 viser, at hvis ikke man har undersøgt og vurderet risici i forhold til alle faktorer og trin i et login, kan noget eller hele fordelen i at kræve flere faktorer i login være illusorisk. 2g. Foranstaltninger imod automatiseret, distribueret og langvarigt Brute-Force-angreb Et Brute-Force-angreb kan benytte mange computere, der er spredt over hele verden, i såkaldte botnet 12, eller det kan foregive at komme fra forskellige computere/netværksadresser. Angrebet kan desuden være langvarigt og langsomt, således at login-forsøg foretaget af ondsindede personer sker ind i mellem den autoriserede brugers succesfulde login. Når et Brute-Force-angreb bliver spredt tidsmæssigt, og det kommer fra (eller foregiver at komme fra) forskellige computere/netværksadresser, kan simple modforanstaltninger komme til kort. Tilstrækkelig beskyttelse kan kræve en mere "intelligent" overvågning af forgæves loginforsøg, hvor man detekterer mistænkelige mønstre ved at se på tværs af bruger-id'er, enheder (pc, smartphone, osv.), netværksadresser, tidspunkt på døgnet, med videre. Mønstre kan eventuelt sammenholdes med "normale" anvendelsesmønstre. Fx vil det være et unormalt mønster, hvis der forsøges login med samme personlige bruger-id, men fra fem forskellige ipadresser forskellige steder i verden, indenfor én time. Der findes filtre, som specifikt er designet til at frasortere datatrafik, som ser ud til at komme fra Botnet. Ydermere kan man forsøge at bremse muligheden for automatiseret Brute-Force-angreb ved ind i mellem at kræve indikation af, at der sidder en fysisk person foran den computer, hvorfra login-forsøget sker. Efter et antal forgæves login-forsøg kan der kræves anvendelse af CAPTCHA 13. Det kan fx være en forvrænget tekst, som vises på skærmen, og som skal gengives ved indtastning på tastaturet. Imidlertid er der udviklet software, som evner at give korrekt respons på mange typer af CAPTCHA, hvorfor dette område hele tiden udvikles. Fx er der lavet nye former for test: CAPTCHA kan laves med fotos, hvor brugeren skal vælge kattene ud fra forvrængede fotos af både hunde og katte. It-systemer kan forsøge at vurdere, om der sidder en person foran computeren ved at studere, hvordan der tastes i tastaturet, eller hvordan musen føres. Endeligt kan det muligvis hjælpe at variere login-funktionens respons på forgæves login-forsøg. Det kan være svært at automatisere et Brute-Force-angreb, hvis det er svært at forudse, hvilken respons login-funktionen giver, når et login-forsøg afvises. 12 Botnet består af kompromitterede computere, som (uden ejerens viden) kan blive styret af én person/organisation og blive anvendt til diverse ondsindede formål. 13 CAPTCHA er en forkortelse for "Completely Automated Public Turing test to tell Computers and Humans Apart". 7
3. Foranstaltninger imod at et Brute-Force-angreb resulterer i manglende adgang for de autoriserede brugere Samtidig med at et login beskyttes imod Brute-Force-angreb, er det relevant at vurdere, hvordan det sikres, at de autoriserede brugere fortsat kan foretage login. It-systemer kan ikke skelne mellem en uautoriseret person, der forsøger at finde faktoren ved at prøve sig frem, og en autoriseret person, der har glemt faktoren eller kludrer i forsøget på at afgive faktoren. It-systemer kan altså ikke skelne mellem autoriseret og uautoriseret adgangsforsøg. It-systemer kan skelne mellem godkendt og afvist login-forsøg (succesfuldt og forgæves adgangsforsøg). Begge dele kan udføres af både autoriserede og uautoriserede personer. Flere af de modforanstaltninger til Brute-Force-angreb, som er beskrevet tidligere i denne tekst, må nødvendigvis bygge på en registrering af forgæves og eventuelt succesfulde adgangsforsøg, men registreringen kan ikke angive, om det var en uautoriseret person eller en computer, som foretog adgangsforsøget. Denne begrænsning kan medføre, at beskyttelsen imod Brute-Forceangreb får en negativ effekt på de autoriserede personers adgange, og det er relevant at indrette beskyttelsen efter dette. Hvis man automatisk spærrer adgangen for en bruger-id ved gentagne forgæves adgangsforsøg, men den ondsindede person prøver sig frem med alle bruger-id'er, kan man ende med, at alle autoriserede personer forhindres i at foretage login. Det kan være det egentlige formål med angrebet at forhindre autoriserede personer i at kunne foretage login, snarere end at opnå uautoriseret adgang. Derfor er det også relevant at kunne spærre i forhold til andet end bruger-id, fx spærring af enheder eller netværksadresse. Dette er medtaget i listen i afsnittet "2b. Foranstaltninger der indebærer spærring af brugeradgang" (punkt c til f). Den dataansvarliges kontrol med login Beskyttelse imod Brute-Force-angreb på login kan være en særlig udfordring, når login sker udenfor den dataansvarliges direkte kontrol (kontrol i realtid). Eksempel 5: Et login sker ved anvendelse af et personligt certifikat installeret på en pc eller en USB-enhed, og brugeren "åbner for" anvendelse af dette certifikat ved at indtaste en kode. Indtastning af koden foregår lokalt på pc'en/usb-enheden og dermed umiddelbart udenfor den dataansvarliges direkte kontrol. Den dataansvarlige kan ikke registrere eller reagere på tegn på Brute-Force-angreb, når koden indtastes (i realtid). I eksempel 5 kan man gøre flere ting for at kompensere for denne situation, fx: Der anvendes personligt certifikatet (knyttet til én bruger-id) pr. enhed (pc/usb). Derved kan et Brute-Force-angreb udelukkende påvirke én brugers adgang (pr. enhed). Man kan derved måske begrænse konsekvensen ved et succesfuldt Brute-Force-angreb. Dette tiltag vil ikke nødvendigvis nytte noget, hvis alle brugerne har samme adgang til de samme data. Enheden, som indeholder certifikatet, er låst inde, når den ikke anvendes, og kan udelukkende tilgås fysisk af den autoriserede person (indehaveren af det personlige certifikat). 8
Enheden, som indeholder certifikatet, kan udelukkende tages i anvendelse gennem et personligt login på enheden selv. Derved kan enheden ikke umiddelbart benyttes af andre end den autoriserede person (indehaveren af det personlige certifikat). Hvis enhedens login ikke kan omgås, og samtidig er beskyttet imod Brute-Force-angreb, vil adgangen til certifikatet inkludere en beskyttelse imod Brute-Force-angreb. Efter login til certifikatet afkræves en anden faktor 2. trin i login og dette trin i login kontrolleres centralt fra, hvor det er beskyttet imod Brute-Force-angreb. Den samlede løsning Det er relevant for den dataansvarlige at forstå risikoen for Brute-Force-angreb i kontekst af et specifikt login. Effektive modforanstaltninger til et Brute-Force-angreb forudsætter, at man har vurderet risici og muligheder i forhold til hver enkelt faktor, i forhold til hvert trin i login og i forhold til den samlede login-funktion. Beskyttelse imod Brute-Force-angreb kræver typisk, at man er nødt til at kombinere flere tiltag for både at beskytte persondatas fortrolighed (beskyttelse imod uautoriseret adgang) og samtidig sikre tilgængeligheden for de autoriserede brugere. Disse tiltag kan være af både teknisk, fysisk og organisatorisk karakter. En fyldestgørende risikovurdering forudsætter, at man i denne har inkluderet al relevant teknisk funktionalitet og alle relevante organisatoriske processer (fx i brugeradministrationen), der har indflydelse på, hvordan login-funktionen kan anvendes. En fyldestgørende risikovurdering indbefatter dermed også eventuel funktionalitet til genudstedelse af faktor og "husket login": Genudstedelse af faktor En mulig indgang til data er systemer, hvor brugerne automatisk kan få genudstedt den adgangsgivende faktor, fx ved at svare på spørgsmål i stil med "Hvad er din mors pigenavn" eller "Hvad mærke var din første bil". Disse systemer til genudstedelse af faktor kan eventuelt også være mål for Brute-Force-angreb, og det kan tilmed være den nemmeste vej igennem et login 14. "Husket login" Visse login-funktioner giver brugeren mulighed for at undgå at skulle afgive den adgangsgivende faktor ved hvert login. Sådanne login-funktioner kan have betegnelser som fx "Husk mit login" eller "Keep me logged in". I nogle login-funktioner kan brugeren end ikke fravælge, at "login huskes". Der kan fx være tale om, at faktorerne opbevares lokalt på den enhed, der benyttes ved login (fx på pc eller smartphone). Den enhed, hvorpå faktoren lagres, kan være mål for Brute-Forceangreb. Ved vurdering af sikkerhedsniveauet i et sådant login er det relevant at vurdere sikkerheden i adgangen til enheden og den lagrede faktor. Det være sig både, hvis uvedkommende har fysisk adgang til enheden, men også adgang til den lagrede faktor via anden software (fx apps eller malware) på enheden. 14 Flere udfordringer vedrørende sådanne systemer er beskrevet i teksterne "ST1 Flere faktorer i login" og "ST7 Overdragelse af faktorer ved udstedelse af et personligt login til en identificeret fysisk person". 9
Tilbagevendende vurdering Den teknologiske udvikling gør, at effekten af de implementerede modforanstaltninger kan mindskes over tid (se afsnittet "2g. Foranstaltninger imod automatiseret, distribueret og langvarigt Brute-Force-angreb"). Derfor er der grund til med jævne mellemrum at genoverveje login-funktionen og beskyttelsen imod Brute-Force-angreb. Afhængigt af de implementerede modforanstaltninger kan antallet af brugere influere på, hvilke muligheder der er for misbrug. Hvis der er 1000 it-brugere, og der gives 5 forsøg på indtastning af en adgangskode, før en brugeradgang spærres, svarer det til 5000 forsøg i alt. Med 200.000 brugere giver det 1 million forsøg. Det betyder, at hvis der kommer væsentligt flere brugere til it-systemet, så kan det være relevant at genoverveje foranstaltningerne imod Brute-Forceangreb. www.datatilsynet.dk dt@datatilsynet.dk (+45) 3319 3200 10