Sikkerhedsekspert: Håbløst at basere NemID på Java

Illustration: leowolfert/Bigstock
Java, der bruges i NemID, er et af hackernes favoritbrækjern. Samtidig er Java den software, brugerne oftest udskyder at opdatere.
47

På trods af, at NemID hævder, at det aktuelle sikkerhedshul i Java ingen konsekvenser har for sikkerheden i NemID og brugen af netbank og kommunikation med offentlige it-systemer, så advarer it-sikkerhedsekspert i Secunia Thomas Kristensen om øgede risici ved brug af Java.

Læs også: NemID gør Danmark ekstra sårbar for kritisk Java-hul

»Hvis man ser på det med en sikkerhedsmands briller, er det et alvorligt problem, at basere NemID på Java. Java har vist sig at være tungt og besværligt for brugerne at vedligeholde, og folk ignorerer opdateringer af Java i lang tid, selv om der løbende kommer en meddelelse om opdatering,« siger han til Version2.

Og hackerne har også fundet ud af, at Java er en god vej ind i på brugernes maskine.

»Hvis man kigger på Microsofts seneste Security & Intelligence Report nævner den, at der er en stigning i antallet af udnyttelse af Java-sårbarheder. Og det er der en god grund til. Browsere er begyndt at komme med sandbox-funktionalitet, og der er Java en af de ting, der gør det nemmere at bryde ud af sandboxen, så hvorfor skulle man spilde sin tid og kræfter på at udnytte en sårbarhed dybt inde i Chrome eller Internet Explorer, hvis man bare kan udnytte en sårbarhed i Java og hoppe ud af sandboxen den vej, for den kører i forvejen uden for den sandbox, som browseren laver,« siger Thomas Kristensen.

Han finder det problematisk, at NemID tvinger danskere til at have installeret Java for at gå i netbanken eller for at kommunikere med det offentlige.

»Det positive er, at vi har en tofaktor-autentifikation, hvilket gør det sværere at misbruge en dansk bankkonto, men der er ikke noget problem i, når du først er inde på brugerens maskine, at lægge et lag mellem hvad brugeren ser, og hvad der reelt sker i banken. Der kunne kunne man godt vise et andet beløb og andre konto, end dem som brugeren sidder og siger ok til,« siger Thomas Kristensen.

Han tilføjer, at NemID i hans øjne slet ikke har grund til at lave en Java-løsning, men at man i stedet burde lave et web-interface. Han kalder dermed valget af Java for unødvendigt.

»Det (valget af NemID, red.) har sørget for, at software, som ligger på top 5 over hackernes favoritsoftware til at komme ind på folks maskiner, er tvunget ned i halsen på brugerne og er på deres maskiner,« siger Thomas Kristensen.

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

Jeg er helt enig med Thomas Kristensen. En Java-applet er en unødvendig stor klump funktionalitet, der ikke fungere i ret mange browsere. Jyskebank brugte tidligere Java-script (og papkort) i deres netbank, og det var meget hurtigere og virkede i langt flere browsere, uden at der skulle installeres ekstra plugins. Så Jyske netbank er blevet ringere med nemid.

Der til kommer oven i at den Java-applet som DanID sender ud, har fuld adgang til alle borgerens filer, uden at der er nogen grund til det. Det var ikke tilfældet med Jyske banks javascript løsning.

  • 28
  • 3
#2 Casper Bang

Han kalder dermed valget af Java for unødvendigt.

Hurra. Måske endelig nogen der kan komme igennem med logik til DanID.

Det er også værd at tage med, at en standard Java installation kun checker for opdateringer én gang om måneden. Det tillader altså zero-day exploits at husere i mindst en måned!

  • 23
  • 2
#3 Adam Tulinius

Det er også værd at tage med, at en standard Java installation kun checker for opdateringer én gang om måneden. Det tillader altså zero-day exploits at husere i mindst en måned!

Og hvordan er det værre end MS der som regel kun sender opdateringer ud en gang om måneden, selv med zero-day exploits? Rene browser-implementeringer, hvor IE er accepteret som klient, har altså samme problem.

  • 9
  • 3
#4 Thomas Vestergaard

Det tillader altså zero-day exploits at husere i mindst en måned!

Øh - zero-day exploits får typisk lov til at husere noget længere - siden de netop er "zero-day" i.e. har været kendte i nul dage. Ift. zero-day exploits er det langt mere interessant, hvor alvorlige de er og hvor lang tid organisationen bag det software det udnytter, er om at fremstille en patch og gøre den tilgængelig for kunderne.

Angående Javas opdateringsproces, så er der flere meget alvorligere problemer - f.eks. at blot installere den nye version ved siden af den gamle i stedet for at patche/erstatte den.

  • 7
  • 1
#6 Casper Bang

Og hvordan er det værre end MS der som regel kun sender opdateringer ud en gang om måneden, selv med zero-day exploits? Rene browser-implementeringer, hvor IE er accepteret som klient, har altså samme problem.

Når Microsoft finder virkelig grumme ting, kommer de med en såkaldt "out-of-band" patch så snart de kan. Og det forekommer mig ligeledes at Microsoft slet of ret bare installerer opdateringen uden at spørge, det gør Java installeren i alt fald ikke, den er nem at ignorere (ligesom det er min erfaring at mange Citrix løsninger kører med håbløst forældede versioner og ikke får JRE'en opdateret).

Men det korte af det lange er ikke om Microsoft eller Oracle er bedst/værst, men at man ved at bruge Java, åbner for endnu en attack vector der i langt de fleste tilfælde ikke varetages af OS'et.

  • 7
  • 1
#7 Nikolaj Brinch Jørgensen

Jeg forstår heller ikke hvorfor der ikek er lavet en TLS baseret løsning. Men det kan vel hænge sammen med, at man mener hos DanId, at man kan skrue op for sikkerheden i en Applet, hvor man selv kan bestemme cipher strength i alle browsere der understøtter Applets. Lige pt. har FireFox, Chrome og Safari problemer der, og kun Opera og IE8+ (Windows 7) understøtter f.eks. SHA256, ligesom de er de eneste som understøtter TLS 1.1 og TLS 1.2, resten er TLS 1.0. Så denne fragmentation er man da ude over med en Applet, der ikke lader det være op til enten browser eller OS, at afgøre hvor stærk en kryptering man maksimalt kan få hos klienten.

Bare et bud.

  • 4
  • 3
#8 Jens Schumacher

Du mener ikke seriøst at Java Applets ikke fungere i ret mange browsere?

Java Applets fungerer som udgangspunkt i 1 ud af de 3 browsere jeg til daglig bruger :-) det vil jeg da mene er en ret lav score. Virker i chrome på min pc. Virker ikke i browseren på min android telefon. Virker ikke på min chrome os netbook.

Det er da fint at applets kan køre i 117 andre browsere som alle har samme funktion som chrome på min pc (browsing på netop en stitionær/bærbar computer). Men jeg kan ikke se at det på nogen måde skulle være imponerende eller alsidigt hvis man sammenligner med andre web teknologier.

  • 10
  • 4
#10 Anders Mikkelsen

Men det kan vel hænge sammen med, at man mener hos DanId, at man kan skrue op for sikkerheden i en Applet, hvor man selv kan bestemme cipher strength i alle browsere der understøtter Applets.

Man får sjældent (aldrig) et sikkert kryptosystem ved at opfinde det selv.

  • 7
  • 1
#12 Hans Schou

Du mener ikke seriøst at Java Applets ikke fungere i ret mange browsere?

Ja. De værste eksempler er SmartPhones og TV-apparater lignende ting. Jeg tror Samsung havde en fladskærm i støbeskeen hvor der ikke var Java med.

Men hvorfor skulle folk dog også sidde hele familien samlet lørdag aften, og se på storskærmen at lønkontoen er gået i plus? Ja folk er sære :-)

Andre er på ferie med deres Android smartphone og vil godt lige checke deres konto fra eget EDB-apparat, eller blive skrevet op til kommunal børnepasning (de kræver også NemID).

  • 7
  • 0
#15 Thomas Alexander Frederiksen

NemID er en signaturløsning.

Nej, NemID er et single signon system. Der findes en lovmæssig definition af hvad en digital signatur er, og DanID siger endda også selv at NemID ikke er det - hvis man strammer tommelskruerne lidt inden man spørger.

  • 9
  • 2
#16 Flemming Jønsson

Det kommer jo lidt an på hvordan du definerer digital signatur. Det er muligt at NemID i ordets forstand ikke er en signaturløsning, men derfor er det jo stadig meningen at du skal bruge NemID til at underskrive dit skøde ved en hushandel f.eks. Fra http://www.tinglysningsretten.dk/tinglysning/publikationer/Documents/Pje...

DIGITAL TINGLYSNING MED NEMID FOR BORGERE I det digitale tinglysningssystem skal dokumenter underskrives digitalt, og det foregår på www.tinglysning.dk. Du kan underskrive med den nye digitale signatur, NemID, eller med den hidtidige digitale signatur, hvis du allerede har en sådan, indtil den udløber.

Så jeg holder med Anders :-)

  • 2
  • 6
#17 Gert Agerholm

Hvor lang tid har vi ikke haft at ting kun fungerede når man brugte IE. Det punkt er vi da heldigvis ved at være kommer over.

For mig at se er Java med til at fremme system uafhængigheden, så det er for mig at se positivt. Sikkerhedsproblemer skal selvfølgelig tages seriøst, men er vi ikke somme tider ved at være i en lidt underlig situation... Hvis du vil have sikkerhed kan du ikke bruge systemet på grund af sikkerheden. Den ultimative sikkerhed findes ikke. Lidt i stil med at Windows NT4 i sin tid blev klassificeret til et eller andet højt sikkerhedsniveau (jeg er ikke ekspert). Men så måtte den ikke kunne kommunikere med andet end sig selv.

Tja.......

  • 5
  • 3
#20 Nikolaj Brinch Jørgensen

Hvorfor hyle over at java skal med.......

Fordi nogen altid skal hyle over et eller andet og Java er så udbredt at det er nemt at hyle over det. Derudover gør den store udbredelse at der bruges megen tid på at finde exploits her. Der er sikkert en masse exploits i en masse runtimes, som bare ikke er nær så udbredte - med det er gæt værk, og ikke et forsvar for Java. Java er nok valgt da det er mest udbredt, og det har vist sig at Sun/Oracle har været comitted til at understøtte det på diverse platforme (ligesom 3. part - HP, Apple, IBM osv.) har støttet op, og ligeledes supporteret deres implementationer. Af alternativer kunne man have valgt Adobe Flash, men der har Adobe arrogant i flere år afvist 64-bit Linux brugere, og generelt været meget lang tid om at udkomme med bare nogenlunde implementationer til andet end 32-bit Windows. Derudover kan der have været spekuleret i fremtiden for Flash med AIR på banen, og igenpå fremtiden for AIR. Silverlight er understøttet på Mac og Windows, og ikke ander steder (der skulle komme en mono baseret udgave til Linux senere, men det er jo altså ikke noget man kunne bruge til noget i 2010 da NemId gik i luften), så der er igen en begrænset teknologi rent udbredelsesmæssigt (sikkert langt bedre end ActiveX plugins, som kun kørte på IE for Windows).

Så hvis man liste kombatanterne: 1. Java Applets. 2. Adobe Flash/AIR 3. Microsoft/Novell Silverlight/Mono

Så ville jeg også vælge Java som platform, også da det er en meget afprøvet teknologi til netop dette formål (i bankerne som jo er en stor del af interessenterne). Men hvis TLS var på bordet som nummer 4, ville jeg vælge den, så kunne enhver klient benytte sig af NemLogin (f.eks. tablets og smartphones).

Brugen af plugin teknologi til dette hænger nok også sammen med en del FUD: Det kan kun gøres sikkert med en plugin (og så kan man sælge en masse udviklingstimer), og ikke så meget med om kravene for sikkerhed rent faktisk kan løses med TLS.

  • 8
  • 4
#21 Baldur Norddahl

Hvor mange her har prøvet at implementere NemID på egen server? Det kan ikke være mange...

Jeg er enig i at NemID i praksis er en SSO. Men det er faktisk implementeret som en digital signatur. På din server er det en signatur du checker på helt vanlig vis. Det er ikke noget med at din server skal kommunikere med DanID for at verificere om brugeren er ok - du checker bare om login er underskrevet med en gyldig signatur.

Det er naturligvis at gå over åen efter vand, når det nu kun bruges til SSO. Der havde OpenAuth eller OpenID været bedre og tusind gange nemmere for alle.

De har sandsynligvis lavet system sådan fordi det skulle ligne den gamle digitale signatur på server siden. Og fordi det er planen at det engang skal udvikle sig til en egentlig digital signatur.

  • 2
  • 3
#23 Thomas Vestergaard

Det er naturligvis at gå over åen efter vand, når det nu kun bruges til SSO. Der havde OpenAuth eller OpenID været bedre[...]

Fordi der er ingen sikkerhedsproblemer med nogen af de to systemer? Mig bekendt er der i hvert fald stadig væsentlige problemer med OpenID, og OAuth har også haft alvorlige problemer tidligere.

Selvom de begge har potentiale har jeg meget svært ved at se, at de skulle være modne nok til at bruge til så kritiske ting som f.eks. tinglysning...

  • 0
  • 0
#24 Deleted User

Jeg kunne næsten fristes til at anbefale en ældgammel version af JRE, fuld af huller som div. hackere forlængst har opgivet at bruge fordi de ved at de er lukkede :-)

Nej, helt seriøst, hvis man er nervøs for sokkerheden så installer Virtualbox + enten windows eller linux, og så bruger man sin virtuelle maskine udelukkende til nem-id. Bevares det tager noget plads på harddisken, og det tager lidt tid at starte det op. Ingen af delene burde være et alvorligt problem med dagens HW-standard.

Niels

  • 3
  • 1
#25 Nikolaj Brinch Jørgensen

Bevares det tager noget plads på harddisken, og det tager lidt tid at starte det op. Ingen af delene burde være et alvorligt problem med dagens HW-standard.

Nej det er det ikke, min Windows 7 Professional starter hurtigere op i VirtualBox på min MacBook Pro (Core 2 Duo 3.06 GHz, 8 GB RAM, 500 GB 7200RPM disk) end den gør på mit mediecenter (Dual Core E6500 FSB1066 2.93GHz, 4 GB RAM, WD Green 750 GB). Og den er langt hurtigere end på min Lenovo T410 Core i5 maskine.

VirtualBox rocks!

  • 0
  • 0
#26 Nikolaj Brinch Jørgensen

Du mener ikke seriøst at DanId ikke har opfundet sit eget kryptosystem?

Nej det tror jeg bestemt ikke de har. Det er jeg bange for at jeg ikke tror de er kompetente til. Java 6 understøtter meget mere crypto-stuff end browserne, desuden er der ingen variation på Java, som der vil være med Browser + OS variationerne. Bla. MessageDigest understøttes out of the box: MD2 MD5 SHA-1 SHA-256 SHA-384 SHA-512

Fælles for browsere er kun SHA-1 og MD5. SÅ Java giver rige muligheder. På Flash f.eks. har man ikke disse muligheder, men der skal man ud og have fat i f.eks. AS3 biblioteket. Silverlight understøtter f.eks. SHA-1 og SHA-256.

Alt i alt så er JCA i Java 6, Silverlight og Flash langt overlegen, samt selvfølgelig browserne. Serudover har Java SPI så man nemt kan integrere 3. parts algoritmer (f.eks. Twofish).

  • 3
  • 0
#28 Casper Bang

Java 6 understøtter meget mere crypto-stuff end browserne, desuden er der ingen variation på Java

Det passer nu ikke helt. Java distribueres uden såkaldt "stærk kryptering" af sikkerhedspolitiske årsager, dvs. hvis du forsøger at bruge AES256 kryptering får du slet og ret en "java.security.InvalidKeyException" med mindre du manuelt har installeret "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy" i "/jre/lib/security" folderen.

  • 1
  • 1
#29 Nikolaj Brinch Jørgensen

Det passer nu ikke helt. Java distribueres uden såkaldt "stærk kryptering" af sikkerhedspolitiske årsager, dvs. hvis du forsøger at bruge AES256 kryptering får du slet og ret en "java.security.InvalidKeyException" med mindre du manuelt har installeret "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy" i "/jre/lib/security" folderen.

Hmm, ja det er rigtigt hvis du vil benytte AES-256. Men det jeg talte om var standard Java/Flash/Silverlight. Jeg har ikke nævnt AES-256 på noget tidspunkt - så din udlægning af at det jeg skriver ikke passer helt må du nok hellere tage tilbage hvor den kom fra.

  • 0
  • 0
#30 Casper Bang

så din udlægning af at det jeg skriver ikke passer helt må du nok hellere tage tilbage hvor den kom fra.

Jeg forholder mig til at du skriver der ikke er nogen variation i Java. Faktum er at 1) som jeg beskriver ovenover så er der variation ligesom med browsere 2) min Chrome og Firefox understøtter faktisk højere kryptering end Java.

  • 0
  • 0
#31 Nikolaj Brinch Jørgensen

Jeg forholder mig til at du skriver der ikke er nogen variation i Java. Faktum er at 1) som jeg beskriver ovenover så er der variation ligesom med browsere 2) min Chrome og Firefox understøtter faktisk højere kryptering end Java.

Casper, jeg beskriver at laveste fællesnævner i Java er bedre end den du får med de andre teknologier. Det synes jeg du må modbevise, hvis du vil have denne dsikussion?

Laveste fællesnævner på browsermarkedet er afhængigt af browser og OS.

Desuden kan du så ikke oplyse mig om hvad det er for en variation der er på Java 6, med hensyn til kryptografi. Der er et veludbygget kryptografi API, med tilhørende implementationer. Men jeg ser ikke at API og implementationer skulle variere over de forskellige Java 6 versioner, så er de jo netop ikke Java.

Ja Chrome og Firefox har AES-256 symmertrisk krypteringssupport, har Safari og IE? Har Opera? Har de f.eks. TLS 1.1 support?

Forsvaret for Java her er det samme som altid for Java, build once (at det så ikke altid holder er noget andet).

  • 4
  • 0
#32 Henrik Schmidt

@Nicolaj: Men hvad skal man bruge alt den farligt fine kryptering til? Man skal sende et brugernavn, password og en engangskode sikkert over internettet. SSL er det oplagte valg.

Hvad er det for en trussel, som vi omgår vha. Java og ekstra kryptering?

  • 1
  • 0
#33 Nikolaj Brinch Jørgensen

Hej Henrik,

Du har helt ret, jeg er heller ikke klar over hvorfor man ikke benytter TLS. Det var sådan set også det jeg startede med at sige, da jeg selv er træt af at min iPhone/iPad er udelukket som devices der kan tilgå NemId helvedet.

Det andet omkring Java, var blot mit bud på hvorfor der er valgt Java. Java 6 kan vel afvikles i IE 6, så også folk med meget gamle installationer kan benytte NemId uden at lave browser upgrades? Hvis du læser tråden tror jeg også du kan få det ud af det.

  • 0
  • 0
#34 Casper Bang

Nikolaj, både for browsere såvel som JRE implementationer vil der være forskelle og en søgen efter laveste fællesnævner. Apache Harmony understøtter, modsat Oracle's JRE, f.eks. AES-256 uden at brokke sig. Ja faktisk foreskriver JSR-27 så vidt jeg kan se, absolut intet omkring cipher algoritmer der skal være til rådighed via SPI'et, kun omkring max. længder på nøgler for en given cipher implementation der kan være tilstede: http://download.oracle.com/javase/6/docs/technotes/guides/security/crypt...

Så min påstand er stadig at med et max. på 128bit nøgler, er en de-facto JRE standard i form af Oracle's implementation ikke mere overlegen end laveste fællesnævner for de-facto standard browsere (MSIE 9 osv.).

  • 0
  • 0
#35 Nikolaj Brinch Jørgensen

Hej Casper,

Apache Harmony (lever vel lidt endnu, men efter at hovedorganisationen bag - IBM - har trukket sig og puttet sig ind til Oracle og OpenJDK, må det formodes at projektet afgår ved døden efter noget tid - meget trist), er ikke Java 6, og vel slet ikke Java, det er vel det striden indtil videre har gået på. NemId understøtter så vidt jeg ved Java 6. Det er rigtigt at dokumentationen kun omfatter Sun(Oracle) provided implementations, og ikke BEA(Oracle), IBM, HP, Apple osv. At det så er muligt på Java platformen at have sine egne implementationer med (f.eks. Twofish eller lignende) gør jo netop Java overlegen i forhold til browsere. Browsere er for en del af dem (IE og Safari) afhængige af hvad det underliggende OS tilbyder. Windows XP vil være laveste fællesnævner, selvom du har en sej Chrome/Firefox. Desuden er det svært at tilbyde en stærk fælles kryptering i browsere, hvor det kan lade sig gøre med Java, da man kan bruge 3. parts implementationer som man lyster.

  • 0
  • 0
#36 Casper Bang

Hej Nikolaj,

Jeg tror ikke vi er så uenige når det kommer til stykket. Så vidt jeg ved så bruger både Oracle og Apache Bouncy-Castle som provider til mange af deres cipher implementationer (ja faktisk kan man godt med nogle cowbow-tricks opnå AES-256 support på en alm. Oracle JRE med denne viden i baghånden) og det er sansynligt at DanID bare ikke har tænkt tanken længere end Sun's JRE.

Jeg forstår bare ikke, ligesom Henrik ovenover, hvorledes fordelene opvejer ulemperne, ved dén løsning DanID har valgt. Via en browsers header info, ville det bl.a. være muligt for DanID meget præcist og hurtigt at blackliste browsere når/hvis en kritisk fejl findes.

Hvad er det f.eks. af sikkerhed man får p.t. ved DanID's nuværende praksis, hvor host siden henter et unikt sekventielt challenge nr. hos DanID, for at associere dette med appletten når der kommunikeres med DanID senere ved login? Hvor svært er det lige at scrape skat.dk og hente et nyt nr. ud hvis man ønske at køre et replay angreb mod NemID login via skat.dk?

  • 1
  • 0
#37 Nikolaj Brinch Jørgensen

Jeg forstår bare ikke, ligesom Henrik ovenover, hvorledes fordelene opvejer ulemperne, ved dén løsning DanID har valgt. Via en browsers header info, ville det bl.a. være muligt for DanID meget præcist og hurtigt at blackliste browsere når/hvis en kritisk fejl findes.

Det forstår jeg heller ikke. Jeg gætter bare på hvorfor DanId har gjort som de har.

Mit gæt var en kombination af FUD omkring TLS og browsere (man kan lave temmelig god og sikker SSO med token based authentication på browsere og TLS), samt at man har foretrukket Java fordi man har satset på at man på den måde nemmere kunne styre sine krypteringsalgoritmer i et kontrolleret miljø.

Jeg ønsker mig en NemId/NemLogin med HTTPS SSO baseret på TLS, og ikke Java Applets, eller anden proprietær plugin teknologi, som altid vil afkoble nogle devices.

  • 2
  • 1
#38 Thue Kristensen

Mit gæt var en kombination af FUD omkring TLS og browsere (man kan lave temmelig god og sikker SSO med token based authentication på browsere og TLS), samt at man har foretrukket Java fordi man har satset på at man på den måde nemmere kunne styre sine krypteringsalgoritmer i et kontrolleret miljø.

Men NemID-appletten, for ikke at tale om hele siden som indeholder NemID-appletten, bliver jo i dag downloadet over TLS! Hvis man har brudt TLS, så har man alle muligheder for at lave man-in-the-middle allerede i dag, ved at erstatte login-vinduet.

Det er dog selvfølgelig ikke alle angreb på TLS som kan oversættes til et live man-in-the-middle angreb.

  • 0
  • 0
#41 Guan Yang

Så vidt jeg har forstået er NemID både en SSO-løsning, en public key krypteringsløsning og en signaturløsning (med certifikater). (Om den så opfylder lovens krav eller ej.)

Når du bruger NemID til at logge på offentlige myndigheders sites eller til at signere noget (fx post), sender NemIDs servere en krypteret kopi af din private nøgle til appletten. Nøglen er krypteret med dit kodeord. Du indtaster kodeordet i appletten, appletten dekrypterer din private nøgle og bruger den til at signere noget. Signaturen kan så bruges i dit mailprogram eller sendes tilbage til den offentlige myndighed. Dit OCES-certifikat bruges til at checke at signaturen kommer fra dig.

Når du bruger NemID som SSO på en netbank, bliver du selvfølgelig bedt om at indtaste en 4-cifret kode. Den bliver bare overført til serveren og checket. Men de skal stadig checke dit kodeord, og det er fy-fy at overføre dit kodeord til serveren. Kodeordet kan derfor kun checkes ved med samme procedure hvor den krypterede private nøgle bliver sendt til applet, applet dekrypterer med dit kodeord og signerer en nonce, og nonce-signaturen bliver sendt tilbage til serveren.

Alt dette er en forståelig grund til at bruge Java, men jeg ville mene at man med moderne browsere kunne gøre det i JavaScript.

(Jeg er 75% sikker på at det forholder sig sådan.)

  • 1
  • 0
#42 Baldur Norddahl

@Baldur : Det er ikke korrekt. Med NemID nøjes man ikke med at verificere om nøglen er korrekt, men der laves et kald til DanID's backend, for at verificere at nøglen er ok (og ikke låst eller spærret).

Ligesom med alle andre nøglebaserede systemer er det nødvendigt med en liste over tilbagekaldte nøgler. Det kan valgfrit enten laves ved at man ved hvert login spørger DanID eller ved at man en gang dagligt downloader en liste. Vælger man det sidste behøver man ikke kontakte DanIDs server ved hvert login.

  • 2
  • 2
#43 Henrik Schmidt

@Guan: Jeg tror ikke, at de sender min private nøgle til mig, da de ikke har adgang til denne. Den ligger inde i et stykke hardware der er designet til formålet.

Når det så er sagt, så er jeg fuldstændig uenig i, at det er forståeligt, at benytte mekanisme X for at udføre metode Y, når der ikke er nogen, der forstår, hvad vi får ud at at bruge metode Y.

Min holdning (som ikke-sikkerhedsekspert) er, at sikkerhedsmekanismer er fuldstændigt meningsløse, hvis de ikke beskytter mod en konkret trussel, som man både har defineret og har en holdning til. Det er ikke nok at sige: "Kryptering er godt, så at kryptere to gange er dobbelt så godt".

Jeg synes det er en skam, at DanID ikke vil ud med, hvad det er for en trussel, som de beskytter os brugere mod, ved at bruge en så relativt kompleks login procedure. Jeg har fulgt med i lang tid og har aldrigt fundet ud af, hvad formålet med proceduren er. Det virker som om, at jeg ikke er den eneste.

  • 5
  • 0
#46 Nicolai Møller-Andersen

Jeg oplever også, at Jyske Banks netbank er blevet stærkt forringet ved overgang til NEMID. Så vidt jeg kan se, virker NEMID ret godt på WinXP, udmærket men temmelig langsomt på Win7, fornuftigt på OSX - og stort set ikke på smartphones, tablets og datamater med Ubuntu og Fedora. Det må da kunne gøres bedre. Køb Jyske Banks gamle system.

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

EU-landene enige om at styrke forsvaret mod cybertrusler i 2022

3

Clubhouse optager samtaler og gemmer dine kontakter

0

Trods Brexit: Storbritannien på vej til at blive sikkert tredjeland for dataoverførsler

2
Job fra Jobfinder
Mest debatteredeMest læste
Webinars and Whitepapersopen_in_new
Whitepaper
Whitepaper
The Cisco Umbrella Advantage
Se flereopen_in_new
Jobfinder Logo
Upload dit CV
Få nye job via e-mail
Upload din jobannonce
Job fra Jobfinder