henrik biering bloghoved

Myter om NemID

Af 12

Når man taler om identitetshåndtering i Danmark, bliver der ofte refereret til NemID, som de fleste jo bruger uden særlig omtanke. Selv blandt debattørerne her på Version2 hersker der derfor flere misforståelser omkring identitetshåndtering og NemID, som det er nødvendigt at få ryddet ud i, for at kunne starte en reel debat om krav til mulige afløsere for NemID.

Myte #1: NemID er en Single Sign-On (SSO) løsning

Single Sign-On er en løsning, hvor man autentificerer sig én gang på en såkaldt identity provider, hvorefter man uden gentagen autentifikation kan logge ind på flere websteder eller applikationer, såkaldte relying parties, service providers, consumers eller clients. SSO løser således også problemet med at man som bruger skal huske både et brugernavn og en separat adgangskode for hvert websted eller applikation. Mange kender princippet fra "Facebook Connect".

"Nemlog-in" - eller "Det offentlige log-in-fællesskab" er en sådan SSO-løsning, ovenikøbet baseret på internationale standarder . Med hensyn til grundlaget for god og effektiv offentlig digitalisering er Danmark derfor langt foran de fleste andre lande. Men for at øge/lette brugertilslutningen har man måtte købe sig adgang til bankernes brugerdatabase med "NemID" som foranstillet autentifikations-mekanisme. Og dét er et reelt problem.

NemID er nemlig IKKE en SSO-løsning, men derimod en fælles brugernavn og adgangskode-løsning, hvor man som bruger bliver TVUNGET til at anvende samme BrugerID og adgangskode samtlige de steder, man vil logge ind. Det kan være forsvarligt, hvis de steder, man logger ind, har dokumenteret høj sikkerhed og af brugerne opfattes som en naturlig federation. Men hvis man - som med NemID - ukritisk uddeler samme adgangskode til både offentlige myndigheder, banker, datingsider, handelssider og spillesider, er man ude i præcis det samme "hemmeligt vs. offentligt" problem, som med det "halv-offentlige" CPR-nummer, der har været hyppigt diskuteret på disse sider.

Hr og fru Jensen har med NemID ingen reel mulighed for at vurdere om de afgiver deres loginoplysninger a) til DanID, b) til det (normalt) NemID-enablede websted de besøger, c) til nogen der har hacket blot én af disse websider eller d) til en dedikeret phishing webside, der falsk skilter med NemID-login. Især med visionen om at NemID fremover skal kunne bruges gratis af virksomheder i hele Europa, er dette en veritabel bombe under sikkerheden.

Ved bred benyttelse af NemID på diverse websteder kan det derfor ikke forsvares at betragte brugernavn og den statiske adgangskode til NemID som en personlig hemmelighed.

Og det leder så direkte videre til ...

Myte #2: NemID er en to-faktor autentifikations-løsning

To-faktor autentifikation bliver oftest beskrevet som en kombination af "noget du ved" og "noget du har". Og hvis det bare var så vel, kunne vi alle autentificere os sikkert overalt med den ti-krone, vi har i lommen kombineret med vores viden om, hvem der er portrætteret på dens ene side.

Desværre er den rigtige definition af to-faktor autentifikation baseret på "noget KUN du ved" (en hemmelighed eller secret) samt "noget KUN du har" (nøgle eller token). Det er altså en forudsætning at du har værnet om begge dele, og ikke givet nogen mulighed for at opsnuse din hemmelighed eller kopiere din nøgle. Ifølge Den Europæiske Centralbank, som især bankvirksomheder bør være opmærksom på, er det udbyderens ansvar at designe autentifikationsproceduren på en sådan måde, at konfidentialiteten af autentifikationsdata beskyttes.

Så jo: NemID er formelt en to-faktor løsning, sålænge du udelukkende benytter den som adgang til Nemlog-in og til din bank. Men falder du for kampagnerne om at benytte NemID flere og mere eksotiske steder, nedgraderes NemID i sikkerhedsmæssig forstand automatisk til en én faktor løsning.

Selvbetjent sikkerhed

Nu er ovenstående jo ikke ligefrem raket-videnskab. Allerede i revision 1 til den første OpenID specifikation, blev der indsat en kraftig advarsel mod at indtaste loginoplysninger via I-frames eller pop-up's på de enkelte websteder. Og det på trods af, at OpenID på det tidspunkt kun havde til formål at give folk adgang til at kommentere hinandens blogs. Hvis Facebook Connect ligesom NemID havde benyttet fælles brugernavn og adgangskode, som skulle indtastes på alle client-sider, er jeg overbevist om, at Facebook næppe havde eksisteret idag.

Derfor skulle man tro, at også sikkerhedsorganisationen bag NemID var blevet klogere på de 3 år, der er gået siden lanceringen. Og at den ny java-fri udgave, der forventes næste år, dermed kunne blive et farvel til ikke blot java-appletten, men også til en løsning, hvor ansvaret for sikkerheden i urimelig grad læsses over på brugerne. Den centraliserede løsning blev ellers begrundet med, at man ikke kunne overlade sikkerheden til den enkelte bruger, som det var tilfældet med den tidligere digitale signatur.

Men NemID skal åbenbart fortsat understøtte "selvbetjening" ikke blot på applikationsniveau, men også sikkerhedsmæssigt.

PS: Jeg har bevidst undladt at forholde mig til myten "NemID er en digital signatur", som gennem tiden er blevet debatteret til hudløshed her på Version2 - bl.a. så sent som her - og primært er en strid om sproglige definitioner, som blot fjerner fokus fra de egentlige sikkerhedsmæssige problemstillinger ved hhv. decentral og central autentifikation.

Kommentarer (12)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Thue Kristensen

Jeg er helt enig. Og har også selv klaget til Datatilsynet over den åbenlyst absurd lave sikkerhed i NemID-systemet, et år før den første udnyttelse af hullet. Jeg kender simpelthen ikke nogen andre login-systemer/hjemmesider som er så åbenlyst usikre som NemID.

Ud over hos DanID, så ligger fejlen vel også hos Erhvervsministeriet og Datatilsynet, som har godkendt løsningen. Da jeg klagede til Datatilsynet, så var Datatilsynets behandling af klagen at sende den videre til DanID, som så gav en sludder for en sladder, hvilket Datatilsynet brugte som begrundelse til at afvise min klage. Jeg følte på ingen måde at min klage blev behandlet fagmæssigt kompetent.

Det er åbenlyst at staten ikke har nogen som har den mindste forstand på IT. Eller hvis staten har nogen som har forstand på IT, så lytter beslutningstagerne ikke til dem.

  • 15
  • 1
#3 Hans Schou

Men falder du for kampagnerne om at benytte NemID flere og mere eksotiske steder, nedgraderes NemID i sikkerhedsmæssig forstand automatisk til en én faktor løsning ...

... fordi den hemmelighed kun du kender, bliver spredt ud til alle mulige sites, og er så ikke en hemlighed mere. Tilbage er kun nøglen/token.

Og her var det så jeg rigtig godt kunne tænke mig at jeg kunne give min public SSH-nøgle til den eksotiske webside, så jeg stadig beholdt min hemmelighed hjemme (min pass-phrase til min ssh-nøgle). Og så et plugin i min web-klient der kunne håndtere min private ssh-nøgle. Findes der en standard for det?

Jeg forestiller mig noget med et plugin til web-serveren og så et andet til browseren.

  • 0
  • 0
#5 Thue Kristensen

Så jo: NemID er formelt en to-faktor løsning, sålænge du udelukkende benytter den som adgang til Nemlog-in og til din bank. Men falder du for kampagnerne om at benytte NemID flere og mere eksotiske steder, nedgraderes NemID i sikkerhedsmæssig forstand automatisk til en én faktor løsning.

Og koder på nøglekortet er det jo også meningen at du skal give til diverse eksotiske hjemmesider, som demonstreret af Version2. Så det er vel mere korrekt at kalde NemID en nul-faktor løsning?

  • 4
  • 3
#7 Henrik Størner

Og her var det så jeg rigtig godt kunne tænke mig at jeg kunne give min public SSH-nøgle til den eksotiske webside, så jeg stadig beholdt min hemmelighed hjemme (min pass-phrase til min ssh-nøgle). Og så et plugin i min web-klient der kunne håndtere min private ssh-nøgle. Findes der en standard for det?

Jeg forestiller mig noget med et plugin til web-serveren og så et andet til browseren.

Ja, det hedder X.509 klient-certifikater.

  • 3
  • 0
#8 Henrik Biering Blogger

Henrik Biering, kan du give dit input til forskellen mellem NemID til banker og OCES NemID (NemID til alt andet). Hvorfor er Nemlog-in anderledes end NemID til en A-kasse eller Den Blå Avis? Begge dele benytter OCES NemID.

Der er en teknisk forskel på NemID til banker og til alt andet. Bankerne anvender korttidsnøgler, mens NemID andre steder baserer sig på OCES certifikaterne. Men det er ikke denne forskel, der er afgørende for den sikkerhedsmodel (eller mangel på samme), jeg har taget op med dette blogindlæg.

Den afgørende forskel mellem login til de offentlige sider (med kombinationen Nemlog-in + NemID) og alle øvrige sider (inklusiv bankerne) er at brugerne for at logge ind på "offentlige" sider ALDRIG bliver bedt om at indtaste deres loginoplysninger andre steder end på https://nemlog-in.dk som kommer frem med grøn farve og navnet "Digitaliseringsstyrelsen" i browserens adresselinie.

Hvis NETS/bankerne havde lavet et lignende loginfællesskab til alle "private" tjenester, ville det være let at fortælle hr. og fru Jensen at de altid skal tjekke at der står enten "Digitaliseringsstyrelsen" eller "Nets" med grønt i deres browsers adresselinie før de indtaster deres loginoplysninger.

  • 7
  • 0
#10 Andreas Bach Aaen

Så two-factor sikkerheden i at tale med det offentlige er, at man kun deler den ene faktor med nemlog-in.dk og ikke en hel stribe offentlige sider?

Så en øget sikkerhed ville vre hvis der fantes: detprivate-loginfaelleskab.dk som man så kunne nøjes med ganke få steder at dele sine hemmligheder med.

Det har også altid undret mig, at man kører java applitten på de enkelte DanID brugeres hjemmesider. Hvorfor bliver man ikke smidt en tur forbi danid's egen service på deres egen hjemmeside lige så vel som man gør ved betalingskortsystemer, der ikke lader kortnumre og passere hen over den enkelte butiks hjemmeside?

  • 1
  • 0
#12 Hans Schou

Ja, det hedder X.509 klient-certifikater.

Tak, det bragte mig videre! Det tog noget tid, men som jeg ser det nu, er det ret simpelt at gå fra en password-basseret login-løsning, til en client side certificate-løsning.

I dette udmærkede implementereingseksempel bruges en ekstern CA til at underskrive: Using SSL Client Certificates with PHP. Det kan gøres simplere uden en CA med self-signed-certs.

Her på v2.dk er jeg alene identificeret ved en email-adr hos google og så ved v2.dk at de kan sende mail til mig, og den bliver læst. I virkeligheden er jeg jo bare en hund (On the Internet, Nobody Knows You're a Dog).

Jeg har lavet nogle eksperimenter med self-signed PKCS12 certifikater, og det burde egentlig være rigeligt for v2.dk. Man er fuldt identificeret lige så godt som det eksisterende system, men altså uden password.

Lige for at skære det ud, så er hele idéen med client side certificate at serveren v2.dk ikke har noget password der kan blive lækket, lige som det skete med Linkedin og Adobe. Alm. brugere (og jeg selv ind imellem) vælger dårlige passwords, der dermed kan blive kompromiteret. Med client side certificate kan man fx godt hacke min v2.dk-konto hvis man får fat i min private PKCS12 fil, men kan ikke få en hel liste fra v2.dk, man skal ud og hacke hver enkelt bruger og hacke dem.

(Indrømmet, jeg har ikke fået det til at virke med min Android smartphone. Firefox, Chrome og Opera virker fint)

  • 0
  • 0
Log ind eller Opret konto for at kommentere
Job fra Jobfinder
Tip redaktionen