Myndighed bag MitID efter kritik af sikkerheden: »Det er den måde systemet virker på«
Som Version2’s undersøgelse viser, kan man med helt simple angreb dels tvinge MitID til at afsløre brugernavne i titusindvis og dels blokere for brugernavnenes adgang til MitID efterfølgende.
Læs også: Sikkerhedseksperter forundrede: MitID står åbent for sabotage
- emailE-mail
- linkKopier link

Fortsæt din læsning
- Sponseret indhold
V2 Briefing | GENERATIV AI: Sådan bruger du det professionelt
Kunstig Intelligens22. marts
- Sortér efter chevron_right
- Trådet debat
Jeg er ikke helt med på, hvorfor denne issue ikke kan genskabes for NemID, som det påstås i artiklen: Hvis I udvælger de samme 17 personer med NemID, taster deres CPR-nummer i brugernavn og forsøger med tilfældige koder 200 gange i timen over et døgn - så bliver der også spærret for deres NemID. Og det er uendeligt mange gange lettere at chikanere tilfældige personer på den måde med NemID, da man her ikke blot vil spærre for login; nej, man vil spærre for selve deres NemID efter x antal mislykkede forsøg. Og Version2 skulle bruge en nat på at finde 10000 brugernavne til MitID. Til NemID er brugernavnet vores CPR-nummer, hvilket jo nærmest er offentlig tilgængelig information. Det er baseret på en matematisk formel, så kan man i Excel på 5 minutter beregne sig frem til alle danske CPR-numre = så har man gættet sig til samtlige 4.8 mio. brugernavne i NemID på 5 minutter. Med det in mente, så er MitID da væsentligt bedre designet.
Pu-ha, man tør næsten ikke bruge MitID efter læsning af artiklen.
Jeg gør følgende: Alle de steder hvor NemID stadig er en mulighed, vælger jeg den. I min bank er det ikke muligt, og her bruger jeg så MitID så lidt jeg nu behøver, og åbner altid MitID appen inden jeg går på banken - så ved jeg, at der ikke hænger et gammelt loginforsøg som måske kunne give en angriber en login mulighed.
Men altså - det burde jo ikke være nødvendigt med de forholdsregler i en moderne identifikationsløsning.
Det bliver interessant at se, hvordan man vil løse problemet, som for mig at se er et grundlæggende arkitektur problem, som går tilbage til design fasen. Man skal have fat i en systemarkitekt som også har dybt indblik i datasikkerhed på forsvarsniveau. Omskolede humanister fra Statens IT er altså ikke nok - hvilket den nuværende løsning synes at bærer præg af.
Dermed gik vi videre for at bevise, at brugerne kan lukkes ned i større skala. 17 frivillige indgik i forsøget og blev lukket ned af en anden lille kodestump, der konstant indtastede deres korrekte brugernavne. Så længe den gør det, kan de rigtige indehavere ikke logge ind, og deres MitID-app vil konstant vise dem en anmodning om at swipe. Hvis de swiper, lukker de angriberen ind.
Det havde været interessant at se et billede af den anmodning. Hvem er den fra? Jeg er enig i mange af kritikpunkterne, men hvis jeg som bruger ikke kan genkende anmodningens herkomst, ville jeg ikke swipe.
Hvis man ikke havde læst det var vicedirektøren i Digitaliseringsstyrelsen som udtalte sig, så ville man da tro det var Nets som forsvarede sin løsning til sidst mand.
»Jeg vil anbefale at man undlader at forsøge at lave opskrifter til, hvordan man kan chikanere brugere. Det er ulovligt og det vil være meget problematisk hvis man forsøger at opfordre til DDoS-angreb.«
Hold nu op hvor er det en pinlig samtale... Jeg er med på at man som ansvarlig gerne vil forsvare sig lidt. Men det her er jo sådan en ledelsesstil, som desværre underminere en tillid og tro på et demokratisk retfærdig samfund... Hårde ord, men det er simpelthen ikke iorden. Anerkend fejlene og fokuser på at få dem rettet istedet.
Selvom det ikke er samme skala (og måske helt sammenligneligt), så får jeg minder hen til filmen "The Pentagon Wars", hvor James Burton får til opgave af Kongressen at observere afprøvningen af flere nye våben under udvikling i Pentagon, herunder The Bradley Fighting Vehicle-projektet - som var under udvikling i 17 år med en pris på 14 milliarder dollars. Han finder ud af at testene der laves er utilstrækkelige, der manipuleres og sker korruption. Ledelserne er ligeglade fordi enhver, der forsøger at gennemføre ærlige test, til sidst bukker under for presset for at opnå sin næste forfremmelse. Hvis der kan proklameres nul fejl, så bliver man jo forfremmet.
Det er ikke en fejl, det er en feature.... ~ »Det er den måde systemet virker på«
Så kan DDOS vel oversættes til DirekteDumtOgSløset når/hvis et så simpelt angreb lykkedes.
Nuvel, nu er det (nok) muligt at undgå borgerservice hvis/når ens 'simple' brugernavn bliver ramt ved at ringe til mitID telefon support.... indtil de bliver lagt ned når 'opskriften' bliver misbrugt af nogle med rigtig dårlige intentioner :ø(
Komisk-A(lie), inkompetente og dyrt betalte kommunikations folk.... Men, her går det godt (så længe det..) og så længe folk husker deres nye komplicerede brugernavn, men det er jo deres problem. (så, sælg sælg sælg mens det stadig har værdi)
Hvis sikkerheden ligger i at "vælge et kompliceret brugernavn" er #Digitaliseringsstyrelsen godt nok gået galt i byen... ALT LOGIK hænger sammen med et brugernavn som er unik, samtidigt med et "KOMPLICERET PASSWORD" og med øget sikkerhed ved digital godkendelse/certifikat ved login. Få nu det password på! Kombination øger sikkerheden med en meget høj faktor...
Det virker som en mærkelig sikkerhed når den kan omgås.
Til gengæld er det næsten umuligt for en dansker i udlandet at få MitId. Uden dansk telefonnummer og måske et udløbet pas(ældre pas) skal man ned på Borgerservice, som ikke findes i udlandet. Et nyt pas kan også være besværligt at få.
Havde det så bare være en "klassisk" bug, så det kunne være løst hen over en weekend. Men en designfejl er straks værre og her er mit beskedne up-front forslag: Vi scanner jo passet, så I har allerede brugerens fulde navn, så hvad med at putte noget AI i løsningenog sikre at hele eller dele af brugerens fulde navn IKKE kan indgå i MidID navnet?
»I MitID er adgangskoden indlejret i MitID appen, til forskel fra NemID nøgleappen, hvor adgangskoden lå uden for appen. Når man indtaster koden i app’en, er man bedre beskyttet mod fx keyloggermisbrug, som vi kender fra ”bibliotekssagerne” med NemID, hvor kriminelle via. en såkaldt ’keylogger’ kunne aflure brugernes adgangskode, når brugeren tastede den ind på en selvbetjeningsløsning på en hjemmeside. MitID app’en er samtidig bedre beskyttet med en centralt valideret kode end en lokalt (på telefonen) valideret kode, som tilfældet er i NemID. Det gør det teknisk sværere at angribe MitID på mobilen.«
Kan nogen lære Hr. Lebech forskellen på en simpel 6 cifret usikker pinkode som MitID app'en benytter, og en reel adgangskode. Samt belære ham lidt om at i MitID med nøgleviser / chip dvs. uden app, ligger indtastning af adgangskode på det website/app hvor man logger ind med MitID dvs. at det er åbent for keyloggermisbrug som man kender fra NemID. Ja ja.... det rammer kun den brøkdel af befolkningen der benytter nøgleviser eller chip, men det er stadig muligt.
nå, er det kun mig, der bruger PC/tablet??
Det var godt nok en grundig dokumentation for inkompetencen i Digitaliseringsstyrelses ledelse. Egl synes jeg, det er ubehageligt, når folk på den måde udstiller sig selv i offentligheden, men det er nok svært at forestille sig, at den slags problemer kan imødegås, med mindre man får ryddet op i ledelsen. Hvis han f.eks. nogensinde selv har brugt MitId, ville han nok ikke påstå "at en anmodning udløber automatisk efter kort tid:" - eller også har han en forståelse af begrebet "kort tid", der ikke rigtigt harmonerer med et nogenlunde acceptabelt sikkerhedsniveau. Er der nogle, der har testet, hvor lang tid man kan vente med at godkende en anmodning? Jeg har ikke testet grænsen, men har flere gange ventet flere minutter uden problemer.
Det var godt nok en grundig dokumentation for inkompetencen i Digitaliseringsstyrelses ledelse.
Ja, det må man sige. Lidt af det jeg faldt over under vejs:
»Typisk benytter eksempelvis virksomheder, antenneforeninger med flere den samme IP-adresse for al udgående trafik. Der skal derfor tages højde for, at flere forskellige brugere benytter samme IP-adresse. Derfor er grænsen sat med dette for øje. Grænsen er dog dynamisk og kan hurtigt ændres, hvis risikobilledet ændres.«
Man kan ikke tælle fejlforsøg via IP adresser. De skal tælles via sessioner, og derfor er sessionsbegrebet omgærdet af særlig sikkerhed i alle browsere. Og der skal kun være 1 forsøg pr. session. Taster man forkert, må man starte en ny session. Antallet af samtidige sessioner fra samme IP adresse skal begrænses til en vis procentdel af det antal potentielle brugere som benytter samme adresse. Hvis ikke man tæller pr. session kan man netop ikke ændre grænsen - uanset risikobilledet. Så svaret er skudt pænt ved siden af.
»Angrebet giver mulighed for individuel chikane. Det er dog muligt løbende at blackliste IP-adresser. Jeg ved ikke, om det er sket i det tilfælde, du nævner endnu.«
Og hvad gør man så hvis angrebet kommer fra en IP adresse som er NAT'et sammen med tusindvis af reelle brugere? Bum.
»Det er ikke et angreb, vi eller bankerne har set i praksis.
Hvis man står med ryggen til ser man ingenting, og derfor sker det ikke. Den udtalelse er der vist lidt Komiske Ali over.
Det er selvfølgelig også noget, man hele tiden vil overveje. Det har en konsekvens med højere sikkerhed. Stiller man meget høje krav til brugernavnene, vil man udelukke en gruppe brugere.
Når man har valgt at brugernavnet skal holdes hemmeligt, og at det skal gøres obskurt for at højne sikkerheden, så var det måske en glimrende idé netop at udelukke den gruppe brugere som ikke kan finde ud af det.
Bekymringen for denne slags angreb er en generel problemstilling. At lave opskrifter på, hvordan man laver DDoS-angreb er ikke godt, og det er ulovligt.
Opskrifterne på DDoS angreb findes i ti-tusind vis allerede, og russiske statshackere er ganske uimponeret over dansk lovgivning. Det gør vel bare deres arbejde mere spændende. Med den logik der lægges for dagen her, kan vi ende i en situation hvor det offentliges ansvar ophører, fordi man som bruger ikke lavede et brugernavn som var obskurt nok til at det ikke kunne hackes. Man skal måske overveje at kalde det et password, og ikke vise det i klartekst på skærmen, så i det mindste brugeren selv er klar over, at han skal holde det hemmeligt.
Har det angreb, jeg har lavet, trigget nogle alarmer i jeres system? »Nu er det ikke os der driver løsningen.
Så det er ikke Digitaliseringsstyrelsens ansvar? Hvis ikke Digitaliseringsstyrelsen har systemejerskabet til MitID hvem har så? Der er vist noget som ikke er på plads her.
Denne slags mærkelige pladder-svar får mig til at tænke tilbage på de mange mærkelig svar vi i tidens løb modtog fra Telestyrelsen, hver gang der blev stillet kritiske spørgsmål til noget. Dengang var det forretnings- og politik spørgsmål som blev affejet med mærkelige og ligegyldige svar, som indikerede ringe systemforståelse. Men det her er kritisk national infrastruktur, som potentielt har betydning for rigets sikkerhed, så den slags svar fungerer ikke her.
Man kan ikke tælle fejlforsøg via IP adresser. De skal tælles via sessioner, og derfor er sessionsbegrebet omgærdet af særlig sikkerhed i alle browsere.
Browsersessioner baseret på session cookies har ingen værdi fra et DoS-mæssigt syspunkt, da en angriber blot kan vælge at starte en ny session for hver forespørgsel.
Og nej, man kan heller ikke nødvendigvis tage udgangspunkt i IP-adresser til rate limiting af DoS-angreb - trafik fra NAT'ede IP-adresser ligner et DoS-angreb, hvis threshold sættes tilstrækkeligt lavt.
Og så er vi tilbage ved, at det er hundesvært at skelne legitim brugertrafik fra DoS-trafik, hvis angriberen har gjort sig bare den mindste smule ulejlighed.
200 forkerte opslag fra samme IP-adresse i timen lyder umiddelbart som en realistisk grænse - der kan snildt være flere tusinde brugere bag samme IP-adresse på mobilnettene.
Browsersessioner baseret på session cookies har ingen værdi fra et DoS-mæssigt syspunkt, da en angriber blot kan vælge at starte en ny session for hver forespørgsel.
Se: https://www.radware.com/cyberpedia/application-security/cookie-challenge/
I et målrettet DoS-angreb vil angriberen kunne kode sin bot til at medsende session cookie - og smide den væk, når login fejler, hvorefter man forsøger igen. Hvis målet er at lægge MitID ned, vil man nok gerne ofre den ekstra halve kodetime, det tager, at få sin klient til at håndtere en cookie challenge.
Hvis det havde været let at skelne maskiner fra mennesker, havde der ikke været noget behov for CAPTCHAs.
Den udløber efter fem minutter. Vores script sender derfor en ny lige inden da. Scriptet kan også se, om brugeren annullerer anmodning. I så fald sender det en ny med det samme.
Så hvis Rusland nu planlage en fysisk aktion i Danmark og gerne ville flytte mest mulige PET/Politi/FE væk fra deres daglige opgaver, så finder man 100.000 personers MitID brugernavn og meget gerne brugernavnet på alle i folktinget så angriber man MitID løsninge og skaber opstandelse. Når så Rusland kan se at nu har de ro, så gennemføre de deres fysiske aktion i Danmark.
En løsning som MitID må IKKE fortælle om brugernavnet findes. i oprettelse øjeblikket skal man som borger angiver fx 10 ønskede brugernavne, systemet kommer så tilbage og præsentere dig for 2 eller 3 af dem du ønskede, et af de præsenterede skal man så vælge. De andre 7-8 brugerid kan være en blanding af allerede taget ID'er eller bare tilfældigt fra valgte.
"Myndighed bag MitID efter kritik af sikkerheden: »Det er den måde systemet virker på«"
Nå sådan - det er helt med vilje? så er vi mere rolige.....