Sikkerhedsekspert: NemID-support og Nordea giver 'helt gale' råd

Når du får en advarsel mod at køre en Java-applet i din browser, bør du aldrig sætte det flueben, der får advarslen til at forsvinde i fremtiden. Heller ikke selvom NemID's telefonsupport siger det, mener it-sikkerhedsekspert.

Supporten hos NemID kommer med anbefalinger, der strider mod god sikkerhedspraksis. Det mener it-sikkerhedseksperten Roel Schouten fra revisions- og konsulenthuset PricewaterhouseCoopers.

Reaktionen kommer oven på Version2's dokumentation af en samtale med NemID-supporten, efter at NemID onsdag fik certifikatproblemer i kølvandet på en natlig opdatering.

Læs også: DanID's support: Se bort fra sikkerhedsadvarsel

I samtalen beder supporten Version2 om at sætte flueben i "Always trust content from this publisher" og derefter klikke på "Run".

Men det er en stærkt uheldig praksis at indføre, mener Roel Schouten.

»Hvis Java-programmet i din browser ikke kender en bestemt Java-applet og advarer dig mod den, så skal du aldrig sætte flueben i "Always trust content from this publisher",« siger Roel Schouten til Version2.

Læs også: Natlig opdatering smadrer NemID-certifikat - Danske Bank skifter til nød-login

Så længe din Java-installation ikke kender rod-certifikatet og derfor kommer med en advarsel, så kan du ikke have tillid til appletten, forklarer Roel Schouten.

»Hvis du er sikker på, at du besøger en side, som du stoler på og forventer at skulle logge ind med NemID, kan du til nød køre Java-appletten. Personligt ville jeg dog lade være og afvente til problemet er løst.. Men sæt aldrig flueben, hvis der kommer en advarsel. For så løber du den risiko ikke at blive advaret, hvis nogen i fremtiden skulle prøve at kompromittere din computer vha. en ondsindet Java-applet« siger Roel Schouten til Version2.

Under onsdagens koks med NemID-certifikaterne gav Nordea følgende besked til deres netbankkunder på hjemmesiden:

'I øjeblikket er Nets DanID i gang med at forny certifikat. Det bevirker desværre lige nu, at certifikatet beskrives som ”UNKNOWN” (ukendt). Der burde stå ”Nets DanID”. Det er sikkert nok at sætte flueben i ”Always trust content from this publisher" og logge på Netbank.'

»Den er helt gal. Hvis man gør det, kan alle lave deres egen applet, som kan afvikles, uden at brugeren lægger mærke til det,« siger Roel Schouten til Version2.

Opdateret 15.05: Roel Schoutens citater er flere steder rettet til, blandt andet så det nu retteligt fremgår, at det er Java-programmet og ikke browseren selv, der kommer med en advarselsboks.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (16)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#2 Peter Mogensen

... og at ligegyldig hvor mange "sikkerheds-eksperter" vi har til at udtale sig om hvad alle IT-folk burde vide og en del af den stadig ignorerede kritik af NemID faktisk advarede imod det uhensigtsmæssige i at tvinge alle borgere til at have installeret et unødvendigt system (Java), der kræver vedligeholdelse og samtidig vænne dem til at klikke OK for at tillade en priviligeret applets - og selv når de så ligefrem står i en situation, hvor de finder det passende at rådegive folk til at ignorere advarlser og alligevel klikke OK, - at der så stadig ikke er en politiker, der har mod nok til seriøst at overveje om ikke man burde stoppe det her cirkus med at trække en pseudo-signatur ned over hovedet på borgerne, som ikke løser andre sikkerhedsproblemer end, at bankerne ønsker sig et single-sign-on system.

Først ignorerede de kritikken - så blev det for dyrt at stoppe.

  • 11
  • 2
#3 Michael Westergaard

Langt de fleste browsere, hvis ikke alle, accepterer ikke en UNKNOWN udbyder, men et konkret certifikat. Når der så er brugt et selv-signeret certifikat til NemID på grund af inkompetence, ER det en god idé at acceptere det. Certifikatet er godt nok, og det er fint at fortælle browseren det.

Det betyder, brugeren ikke i fremtiden bliver generet med advarsler på grund af, certifikatet ikke er signeret korrekt og dermed bliver blind over for den slags advarsler. Det kan ikke misbruges af nogen, da de ikke har adgang til NemIDs selvsignerede certifikat. End ikke ved at acceptere NemIDs rodcertifikat (som også er selvsigneret) skabes problemer, da 3.-part ikke kan lave et certifikat signeret med dette.

Faktisk er det farligere ikke at acceptere certifikatet permanent; gøres dette, kan en hacker lave et selv-signeret certifikat, der intet med NemIDs certifikat har at gøre, men deler navn med det. Da brugeren er vant til, der står UNKNOWN, accepteres dette og skadelig kode udføres. Browseren vil ikke lade sig snyde, da den ikke bruger navnet til noget, men derimod bruger det præcise certifikat. Brugeren, der har accepteret det korrekte certifikat permanent vil kunne fange dette, brugeren der accepterer det manuelt hver gang vil ikke.

Sikkerhedseksperten tager fejl. (og jeg bruger certifikat om både det offentlige certifikat og den private nøgle ovenfor, hvilket er noget sprogligt snavs.)

  • 8
  • 8
#4 Thue Kristensen

Disclaimer: Jeg er ikke ekspert på dette område. Nedenstående afspejler min forståelse efter noget Googling.

Bemærk at NemID-appletten stadig er signeret. Ellers ville man overhovedet ikke få "Stoler du på"-vinduet. Når man klikker "stol altid på denne udgiver", så er det det specifikke certifikat man husker, hvilket også er grunden til at man skal klikke "stol altid på ..." hver gang et certificat bliver fornyet.

Og siden det kun er DanID som har privat-nøglen, selv til det forvirrede certificat, så er det stadig nogenlunde sikkert at trykke "stol altid på" selv dialogen med publisher "UNKNOWN", hvis man er helt sikker på at det er DanID som har den private nøgle svarende til certificatet. Det er ikke alle udgivere som kalder sig "UNKNOWN" som man godkender, men kun den specifikke nøgle!

Så længe browseren ikke kender rod-certifikatet og derfor kommer med en advarsel, så kan du ikke have tillid til appletten, forklarer Roel Schouten.

Jeg kan ikke se hvorfor det er ok at køre, men ikke ok at klikke "stol altid på".

Hvis man kører den (og dermed giver den adgang til hele sin harddisk), så tror man jo at den kommer fra DanID, og at DanID derfor har den private nøgle til certificatet. Hvorfor skulle man så ikke sige "stol altid på", da DanID da må kunne finde ud af at holde certificatet's privatnøgle hemmelig? Det er vel ikke meget anderledes end det normale certificat, hvor DanID også skal holde privatnøglen hemmelig.

»Hvis du er sikker på, at du besøger en side, som du stoler på, kan du godt køre Java-appletten. Men sæt ikke flueben, hvis der kommer en advarsel. For så bliver du ikke advaret, hvis nogen i fremtiden skulle kompromittere appletten,« siger Roel Schouten til Version2.

Hvad betyder "hvis nogen i fremtiden skulle kompromittere appletten"?

Det som artiklen nok prøver at sige på en meget forvirret måde, er at man med et selv-signeret sertificat ikke kan bruge Online Certificate Status Protocol. Så hvis nogen stjæler DanID's privatnøgle i fremtiden, så har DanID ikke nogen måde at sige det til brugerne.

Hvis placeringen af revocation-listen er indlejret i certificatet, så er det endda ikke noget problem. Men jeg ved ikke om er designet sådan teknisk.

»Den er helt gal. Hvis man gør det, kan alle lave deres egen applet, som kan afvikles, uden at brugeren lægger mærke til det,« siger Roel Schouten til Version2.

Så igen siger Roel Schouten tilsyneladende at det er ok at køre appletten, men ikke ok at sige "stol altid på". Tilsyneladende ud fra den overbevisning at man så har sagt ja til at køre alle appletter hvor der står "UNKNOWN" i udgiverfeltet. Jeg tror bare at Roel Schouten er forvirret.

  • 6
  • 1
#6 Adam Tulinius

Og hvordan ved du at det rent faktisk er NemIDs applet du er ved at køre i første omgang? Jaja, https:// vil du sikkert sige, men så vil jeg tillade mig at spørge hvor stor del af befolkningen der overhovedet kender forskel på http og https.

Ang. alt det med at acceptere permanent eller ej: Ved folk hvor tit NemID skifter certifikat? Hvis de en dag har samme problem som i går, så klikker de da vel bare "jaja kør nu", eftersom det jo var det super gode tip deres troværdige bank og NemID support gav dem sidste gang.

  • 9
  • 0
#7 Rune Larsen

Michael Westergaard har ret - når NemID support fortæller, at man bør betro en given applet adgang til sit system, så bør man simpelthen gøre det. Roel Schoutens sysnpunkt er et verdensfjernt "tro ikke på nogen!" paranoia, som skader it-sikkerhed mere end det gavner. It-sikkerhed handler udelukkende om tillid - når man ved, at man sidder med en NemID support i røret, så har man en glimrende chain of trust. Måske i virkeligheden langt bedre end det der tilbydes af CA'erne...

  • 4
  • 4
#8 Michael Westergaard

Og hvordan ved du at det rent faktisk er NemIDs applet du er ved at køre i første omgang

Det er selvfølgelig problemet, men det er meget bedre at have den problematik en gang (i.e., nu, hvor alle medier taler om det) og få problemet væk (ved at acceptere dette certifikat i al fremtid) end at have problemet hver gang der logges på netbank/det offentlige og derved få ind i hukommelsen, man bare skal klikke ok. Faktisk forstærker dine argumenter bare at ekspertens råd er noget skidt.

At der er et opstartsproblem med et selvsigneret certifikat er et helt andet problem (og det ER noget snavs at køre kode med et selvcertificeret certifikat), men hvis man skal bruge sin netbank desværre den eneste mulighed (i går, jeg mener, de fiksede det i nat). Det er bare ikke det, der harcelleres imod. Chancen for, jeg får min netbank idet jeg klikker på mit bookmark til min netbank er dog større end at jeg får en side, som har ret til at få min NemID hver gang jeg får et certifikat, der siger UNKNOWN.

  • 3
  • 1
#9 Thue Kristensen

Og hvordan ved du at det rent faktisk er NemIDs applet du er ved at køre i første omgang? Jaja, https:// vil du sikkert sige, men så vil jeg tillade mig at spørge hvor stor del af befolkningen der overhovedet kender forskel på http og https.

Men det artiklen siger er jo at det til nød er ok at køre appletten, men ikke ok at at klikke i "always trust...". Det er det som Michael Westergaard (korrekt) argumenterer imod.

  • 5
  • 0
#10 Peter Makholm Blogger

Roel Schoutens anbefaling giver en enkelt rettesnor. Det er ufarligt at generalisere hans råd til andre tilfælde hvor brugeren ser samme fejlbesked. Der er ikke noget usagt, men nødvendigt, før brugeren kan genanvende rådet.

NemID's anbefaling kan, [b]måske[/b], være korrekt under nogle særlige forudsætninger. Disse forudsætninger var muligvis tilstede i går. Problemet med anbefalingen er at den jævne IT-bruger ikke har kompetance til at ekstrapolere til hvornår det ellers er den korrekte måde at løse problemet næste gang han oplever samme fejlsituation.

Her og nu vifter NemID's support måske fluen væk, men reelt set ender brugeren med et knust sikkerhedsinstinkt.

  • 9
  • 2
#11 Jens Peter Jensen

Og hvorfor ikke bare distribuere source-koden til klienten (og serveren for den sags skyld), med en kompileringsvejledning. Så vil man kunne se, hvad koden rent faktisk laver. Principelt er det kun NemID's private nøgle (eller noget ækvivalent for certifikater - jeg kender primært til pricippet med private og offentlige nøgler i assymetris kryptering), som bør være hemmeligt. Din egen private nøgle skal NemID jo naturligvis ikke have. Det vil også kunne mane enhver mistanke om en statstrojaner gennem NemID til jorden. Hvilke politikere har nosser nok til at kræve, at NemID går OpenSource?

  • 2
  • 3
#12 Sune Foldager

Din egen private nøgle skal NemID jo naturligvis ikke have. Det vil også kunne mane enhver mistanke om en statstrojaner gennem NemID til jorden. Hvilke politikere har nosser nok til at kræve, at NemID går OpenSource?

Du er klar over at NemID naturligvis har din private nøgle ikke? Hvem skulle ellers have den i den nuværende løsning som netop ikke afhænger af nogen filer på den lokale maskine? Det ville kræve et andet design, lidt ud over at open source programmet.

Ved at indtaste brugernavn og koder, authorizer du din key som det fungerer nu.

  • 0
  • 0
#13 Anonym

Man kan bare droppe den Java-applet. Den gør mest skade.

Find ud af at skabe en virksomhed eller institut, der løser NemID opgaven. Den slags hører ikke til i en privat virksomhed. Sørg for at gennemteste alle tænkelige scenarier, så man er forberedt når det går galt. Det er jo keglehat, at man ikke har en standard procedure, for den sags fejl. ( Ja fejl opstår )

SÅ svært er det heller ikke at løse den opgave. Nu kan der snart ikke være flere usaglige og dumme undskyldninger for ikke at gøre noget ved problemerne. Nu skal man se at få fingeren ud, og tage ansvar for det Digitale samfund, og de borgere der burde finde anvendelse og beskyttelse herunder.

Ansvaret ligger udelukkende hos Digitaliseringsstyrelsen. De kan rette op på manglerne i NemID, hvis de vil. Der må være andre årsager end respekt for opgaven, der skaber motiv til denne uvilje.

Hvis man vil tvinge tommelskruer på borgerne, så må det være et krav at man som minimum har styr på egne tommelfingre.

  • 3
  • 0
#14 Povl H. Pedersen

Det selvsignerede certifikat er muligvis i bredt omløb hos mange ansatte i DanID, eller der er mange der kan få kode signeret med det. Det er helt sikkert ikke omgærdet af samme sikkerhed som det officielle. Det er ihvertfald min erfaring med selvsignerede certifikater.

Og nu er der 2 issues her. Både det issue at man anvender et certifikat med lav sikkerhed.

Det væsentligste problem her er, at man vænner brugeren til, at når der står UNKNOWN i udgiver, så skal man bare klikke stol altid på denne udbyder. Det betyder at brugeren vil gøre det samme når hackeren leverer en Applet til dem. Det har de jo lært hos NemID og Nordea.

Danske Banks fallback til en anden løsning er det mest fornuftige der er lavet.

NemID burde også have lavet fallback til en ikke-java løsning, en almindelig HTML 1.0 FORM, indtil Java løsningen var kørende igen. Det ville være mere sikkert end at lære brugeren at acceptere at køre vilkårlig kode, og nok give mindre økonomiske tab. Jeg er sikker på at der snart kommer malware til NemID signered af UNKNOWN, dem NemID siger man kan stole på.

  • 2
  • 0
#15 Peter Mogensen

Det væsentligste problem her er, at man vænner brugeren til, at når der står UNKNOWN i udgiver, så skal man bare klikke stol altid på denne udbyder.

Præcis - og netop det blev der advaret kraftigt imod da det blev kendt at DanID havde valgt en priviligeret applet. At det så også heller ikke havde været nødvendigt at bringe sig selv i den her situation, hvis man ikke havde insisteret på at ville kompromiteret borgernes computere med at køre priviligeret Java-kode gør det blot endnu mere groteskt.

  • 5
  • 0
#16 Finn Aarup Nielsen

Et problem med "Stoler du på"-ja rådet er at en målrettet hacker ville kunne udnytte dette under certifikat-problemer så vidt jeg da kan forstå: Sende links til den naive bruger med link til en hacket fake-side. Supportmedarbejderen har ikke særlig mulighed for at opdage om brugeren er inde på en ordentlig side.

Et andet problem er at i fremtiden når naive brugere modtager en phishing-mail og følger links vil de søge på Internettet og der måske kunne læse på en eller anden bank-hjemmeside "Det er sikkert nok at sætte flueben". Nu er der heldigvis mange Version2 artikler som beskriver problemet.

  • 0
  • 0
Log ind eller Opret konto for at kommentere