NemID gør Danmark ekstra sårbar for kritisk Java-hul
Acros Security har opdaget et nyt, kritisk hul i Oracles Java Runtime Environment (JRE). Hullet gør det muligt at videredirigere brugeren til en anden lokation, som f.eks. et remote share eller en angribende server, hvilket kan føre til plantning af binær kode på et sårbart system.
JRE er særlig interessant i dansk sammenhæng, fordi det er den virtuelle maskine, som NemID baserer sig på. Og med flere end 3 millioner danske NemID-brugere er udbredelsen ekstra høj set i forhold til andre lande.
»I forbindelse med danskernes kommunikation med det offentlige via NemID er JRE mere udbredt end andre steder. Dén store udbredelse sammenholdt med beskaffenheden af sårbarheden gør, at vi betragter det her som kritisk,« siger it-sikkerhedsekspert Peter Kruse fra sikkerhedsfirmaet CSIS til Version2.
Umiddelbart vurderer han dog ikke, at de it-kriminelle har øjnene oppe for det faktum, at danskere i højere grad er eksponeret for sårbarheden end andre, men alt andet lige gør det danskerne til nemmere ofre.
»De fleste, der udnytter Java JRE, gør det i exploit kits og skyder med spredehagl. Og med de detaljer, der er frigivet, så vil det ikke være vanskeligt at omsætte proof of concept'et til rigtig angrebskode. Lur mig, om ganske få dage, så er hullet med i et metasploit-kit,« siger Peter Kruse.
CSIS anbefaler i en mail til sine kunder, at man udviser forsigtighed med at aktivere indhold fra kilder, man ikke har eksplicit tillid til. Oracle vil højst sandsynligt korrigere problemet snarest muligt, hvilket vil kræve, at en ny version af Java JRE klargøres og frigives. En oplagt fix på problemet er at forhindre hotspot konfigurationsfiler fra at blive indlæst fra den aktive arbejdsmappe, skriver CSIS.
Hos Nets DanID, der står bag NemID, er man ikke nervøs for den nyopdagne sårbarhed i den teknologi, som NemID baserer sig på.
»Vores sædvanlige råd til brugerne er, at man altid skal holde programmerne på sin PC opdaterede, så man altid benytter de seneste programversioner. Det er der ikke noget nyt i, og det gælder også for Java. Men på spørgsmålet om, hvorvidt denne sårbarhed i Java udgør en specifik trussel for NemID-brugerne, så er svaret, at man netop har introduceret NemID, der benytter sig af tofaktor-sikkerhed, for at øge sikkerheden mod angreb, hvor brugerens PC er blevet kompromitteret. Vi mener altså ikke, at denne Java-sårbarhed udgør en fare for NemID-brugerne,« skriver kommunikationsmedarbejder i Nets DanID, Michael Juul Rugaard, i en mail til Version2.
- emailE-mail
- linkKopier link
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
Tophistorier
For at deltage i debatten skal du have en profil med adgang til at læse artiklen. Log ind eller opret en bruger.
- Sortér efter chevron_right
- Trådet debat
For lidt over 1 år siden advarede jeg Nemid imod at java var et stort sikkerheds problem.. Men man reagerede med foragt og arrogance.
Jeg håber i er blevet klogere nu efter i har fundet jer på "forsiden" af diverse medier.
Pinligt.
For at udnytte denne exploit skal du:Jeg tror som flere andre ikke at selve sikkerheden omkring NemID er i fare, men adgangen til de systemer som benytter NemID kan som jeg læser dokumentationen få problemer, hvis ikke NemID får rettet deres kode, inden den dag Oracle lukker hullet i JRE'en.
- finde en applet du kan få til at løbe OOM, eller selv kunne plante en applet der løber OOM.
- plante en .hotspotrc fil.
- plante en malicious .exe fil.
- starte JVM'en fra frisk, så den indlæser .hotspotrc filen - det er jeg ikke sikker på sker i en browser hvis der allerede kører en JVM instans. Og det er ydermere vigtigt at du får plantet alle dine filer det rigtige sted (current working directory for JVM'en).
Udover at finde et sikkerhedshul (eller kraftig social engineering) så du kan få plantet filerne, skal din malicious.exe (og eventuelle malicious.class, hvis du ikke kan exploited bug i en eksisterende) naturligvis slippe igennem whatever anti-malware der er på systemet.
Det er ikke den exploit jeg umiddelbart kommer til at miste mest nattesøvn over :)
Sune Marcher:
Lige netop denne exploit er, ud fra de nuværende oplysninger, ekstremt besværlig at misbruge - næsten et non-issue. Du har dog en pointe med Java generelt, der har været ret mange uheldige sikkerhedshuller, og som nævnt tidligere har de fleste browsere ret lame opførsel når det kommer til unsigned applets.</p>
<p>Hvis du ikke har behov for Java til andet end NemID sites, så er der dog ret mange forskellige løsninger hvor du kan slippe for at have Java enabled by default - og man burde egentligt have en separat browser/profil til at deale med netbank, det offentlige osv.</p>
<p>Det hjælper self. ikke hr og fru Jensen, men for computerkyndige burde det være et non-issue.
Jeg kører selv NemID i en virtuel maskine kun til NemID og Java, så jeg kan godt beskytte mig selv. Det er mere på fru Jensen's vegne jeg er forarget over DanID's design-valg.
Henrik Rathje :
Nemlig.. Jeg skrev inden nemid blev rullet ud til Danid og spurgte hvorfor de insisterede på en signeret applet.. Det tog MANGE mails mm at få et svar. Svaret var: jo for så kan vi undgå at browseren advarer brugeren om at der kører en applet(det lille udråbstegn i statusbaren).. LOL.. oh jeg grinede meget den dag ;-)
Jeg tror bare, at DanID svarer hvad de har lyst til, for at få dig til at gå væk. Jeg har også spurgt dem, og har fået andre 3 forskellige grunde...
- For at kunne lægge en logfil
- For at kunne cache
- For at kunne køre anti-virus
Henrik Mikael Kristensen:
Givet, at NemID kan ændre designet på loginvinduet til hver en tid, behøver en phisher ikke at være nøjagtig i fremstillingen af et falskt NemID login vindue. Men hvilke værktøjer har den almindelige bruger for at checke meget nemt, at man sidder foran et autentisk NemID login vindue?
Det har jeg spurgt DanID om. Svaret er, at Fru Jensen bare skal læse HTMLen, finde det sted hvor appletten er inkluderet, downloade appletten, og derefter manuelt checke signaturen på appletten.
Intet kunne jo være simplere!
NemID er en dårlig vittighed. Hvem laver et single sign-on, hvor man skal indtaste sit password på diverse hjemmesider, men hvor brugeren ikke har nogen reel mulighed for at vide om man faktisk sender sit password til DanID.
Nemlig.. Jeg skrev inden nemid blev rullet ud til Danid og spurgte hvorfor de insisterede på en signeret applet.. Det tog MANGE mails mm at få et svar. Svaret var: jo for så kan vi undgå at browseren advarer brugeren om at der kører en applet(det lille udråbstegn i statusbaren).. LOL.. oh jeg grinede meget den dag ;-)
Jeg tror som flere andre ikke at selve sikkerheden omkring NemID er i fare, men adgangen til de systemer som benytter NemID kan som jeg læser dokumentationen få problemer, hvis ikke NemID får rettet deres kode, inden den dag Oracle lukker hullet i JRE'en. (https://blog.acrossecurity.com/2011/07/binary-planting-goes-any-file-type.html)
Fra et brugersynspunkt er mit issue, at applet'en sjældent opfører sig konsistent på en dårlig netforbindelse. Man får en ikke-fungerende applet, en frossen applet eller værst, en applet der godkender user/pass, men hvor der så ellers sker nul og nix i adskillige minutter på skærmen.
Når man så endelig kommer videre, fatter modparten (f.eks. skat.dk) det ikke, og man bliver direkte bedt af skat.dk om at logge ind igen. Det er bare forkert, for et simpelt reload af skat.dk logger mig ind. Af user-feedback mekanismer er mangel på konsistens noget rigtigt møg at smide efter brugeren, men givet NemID's ledløse "don't mind the man behind the curtain" opbygning er det nok svært at efterkomme.
Desuden: De fleste aner intet om java-applets eller naturen i, hvordan website plugins skal indlæses og godkendes. For dem, er det noget hokuspokus, der foregår i browservinduet, og hvad er det egentligt, der skal godkendes?
Givet, at NemID kan ændre designet på loginvinduet til hver en tid, behøver en phisher ikke at være nøjagtig i fremstillingen af et falskt NemID login vindue. Men hvilke værktøjer har den almindelige bruger for at checke meget nemt, at man sidder foran et autentisk NemID login vindue?
Lige netop denne exploit er, ud fra de nuværende oplysninger, ekstremt besværlig at misbruge - næsten et non-issue. Du har dog en pointe med Java generelt, der har været ret mange uheldige sikkerhedshuller, og som nævnt tidligere har de fleste browsere ret lame opførsel når det kommer til unsigned applets.Men hvis DanID tvinger mig til at have java-appletten installeret, og exploiten kan misbruges i andre sammenhænge, så er det vel (burde være) DanID's problem at min computer bliver kompromiteret via diverse sikkerhedshuller i Java.
Hvis du ikke har behov for Java til andet end NemID sites, så er der dog ret mange forskellige løsninger hvor du kan slippe for at have Java enabled by default - og man burde egentligt have en separat browser/profil til at deale med netbank, det offentlige osv.
Det hjælper self. ikke hr og fru Jensen, men for computerkyndige burde det være et non-issue.
Det kan godt være, at exploiten ikke er et problem for NemID-appletten specifikt. Det lyder da sandsynligt.
Men hvis DanID tvinger mig til at have java-appletten installeret, og exploiten kan misbruges i andre sammenhænge, så er det vel (burde være) DanID's problem at min computer bliver kompromiteret via diverse sikkerhedshuller i Java.
...eller også har de rent faktisk læst hvad lige netop denne exploit kræver for at blive brugt? Version2 artiklen er ret så unøjagtig :)Det er utroligt arrogant af DanID.
Hos Nets DanID, der står bag NemID, er man ikke nervøs for den nyopdagne sårbarhed i den teknologi, som NemID baserer sig på.
Det er utroligt arrogant af DanID.
De siger at de har valgt Java for at kunne bruge de extra privilegier som en usigneret applet har til at lede efter virus på min computer[1]. Men deres valg af Java gør samtidig min browser utroligt sårbar, da Java-pluginnen er måske det mest usikre program man kan installere [2].
Men hvis bare deres anti-virus forhindrer flere angreb på NemID, end der kommer ekstra angreb på NemID pga de computer som bliver inficeret via Java-pluginnen, så er DanID vel glade. At det er mig som slutbruger som har størstedelen af omkostningerne ved et gennemsnitligt angreb, da de jo er få angreb som direkte går efter NemID, det er DanID vel ligeglad med.
For det er bankerne som er NemID's kunder, og som betaler DanID, ikke mig. Så min computers sikkerhed er ikke vigtig for DanID, bare de kan minimere antallet af successfulde angreb på NemID.
[1] Ifølge et svar jeg har fået fra DanID ved henvendelse.
[2] se fx https://krebsonsecurity.com/2010/10/java-a-gift-to-exploit-pack-makers/
Ak, havde glemt hvor retarderede default installs af IE og FireFox er. Chrome gør den fornuftige ting og spørger om lov. Men alle kører ikke Chrome, og mange der gør vil nok give permanent tilladelse og så er vi lige vidt.En usigneret applet genererer ingen popup, og vil fuld ud være i stand til at send de indtastede oplysninger videre til en server, som så kunne bruge dem til at tale med danid's server.
Tak for reminder :)
Sune Marcher:
Ved faktisk ikke om du kan loade en ny applet ind via DOM'en, men hvis du gør ryger den igennem vanlige Java security checks - popup med "vil du køre det her?". Du får ikke meget ud af at kyle den ud... eller, du kan self. fake login udseendet og derved få fat i user/pass, men det kan du ikke bruge til så meget uden papkortet - yay for to-faktor.
Men som tidligere fremhævet mange gange af IT-politisk forening, så har appletten jo slet ikke brug for at være signeret, men tilhørende sikkerheds-check. En usigneret applet genererer ingen popup, og vil fuld ud være i stand til at send de indtastede oplysninger videre til en server, som så kunne bruge dem til at tale med danid's server. Og ved at lade den nye applet interaktivt at spørge om 2-faktor-koden, så kan du komme forbi den også.
Fair pointe, jeg kan heller ikke gennesmskue hvordan appleten ville beskytte mod dét scenarie - nogen med mere viden må kommentere på det.At man ikke kan kommunikere med appletten fra javascript er vel ikke noget, der giver en reel fordel, hvis man kan snyde brugeren til at indtaste sine oplysninger i noget, som ligner appletten?
Eneste ting jeg lige umiddelbart kan se er at hvis SRP-tunnelen er for krævende til at kunne implementeres via JavaScript, kræver det at brugeren kan exploites til at køre mere end blot JS eller der er en ekstern server involveret.
Ved faktisk ikke om du kan loade en ny applet ind via DOM'en, men hvis du gør ryger den igennem vanlige Java security checks - popup med "vil du køre det her?". Du får ikke meget ud af at kyle den ud... eller, du kan self. fake login udseendet og derved få fat i user/pass, men det kan du ikke bruge til så meget uden papkortet - yay for to-faktor.</p>
<p>Som jeg ser det ligger appletens sikkerhed i at du fra JavaScript ikke (bør kunne) kan manipulere med applet'en - dens kommunikation med NemID serverne er ikke et browser XHR kald du kan manipulere.
Jeg er helt enig i, at to-faktorsikkerheden er det, der rent faktisk giver noget her, men jeg kan ikke se noget i vejen med, at man udskifter appletten med noget andet, der sender alle oplysninger til 3. part inklusiv engangspassword. Dvs. at brugeren ikke kommunikerer direkte med banken, selvom det ser sådan ud. Det kan 3.part så gøre i stedet og sende challenges direkte tilbage til brugeren. Hvis browseren/maskinen er kompromitteret har man naturligvis tabt, men selv hvis der "kun" er tale om injected javascript kan jeg ikke se, at man får noget ekstra ud af appletten. At man ikke kan kommunikere med appletten fra javascript er vel ikke noget, der giver en reel fordel, hvis man kan snyde brugeren til at indtaste sine oplysninger i noget, som ligner appletten?
Ved faktisk ikke om du kan loade en ny applet ind via DOM'en, men hvis du gør ryger den igennem vanlige Java security checks - popup med "vil du køre det her?". Du får ikke meget ud af at kyle den ud... eller, du kan self. fake login udseendet og derved få fat i user/pass, men det kan du ikke bruge til så meget uden papkortet - yay for to-faktor.Hvorfor? Det kan vel ikke være specielt svært at smide appletten i DOM'en ud til højre og erstatte den med sin eget applet, flash objekt eller for den sags skyld ren javascript, der sender oplysningerne et andet sted hen?
Som jeg ser det ligger appletens sikkerhed i at du fra JavaScript ikke (bør kunne) kan manipulere med applet'en - dens kommunikation med NemID serverne er ikke et browser XHR kald du kan manipulere.
For at være ærlig, så synes jeg ikke det klart fremgår af artiklen præcis hvad SRP'en beskytter mod :)Som jeg forstår det, så snakker de decideret om, at bryde SSL krypteringen
True, men det får du ikke så meget ud af, uden papkortet. Hvis du derimod sad som MITM på en authenticated forbindelse...I øvrigt kan serveren vel altid snyde folk til at aflevere brugernavn/password/engangskode udenom NemID?
100% enig - og jeg ville generelt gerne have noget mere transparency mht. NemID.Jeg savner simpelthen beskrivelse af et konkret trusselsbillede, hvor man får noget ud af denne teknik. Er det hvis SSL en dag bliver brudt? Er der en konkret svaghed, som man får lukket?
(udover at det er sværere at manipulere med en applet, hvis din attack vector er injected javascript/whatever).
Hvorfor? Det kan vel ikke være specielt svært at smide appletten i DOM'en ud til højre og erstatte den med sin eget applet, flash objekt eller for den sags skyld ren javascript, der sender oplysningerne et andet sted hen?
Men det kan vel hjælpe mod MITM angreb - disse er ikke helt trivielle når SSL er involveret, og vil i de fleste tilfælde kræve at brugeren trykker "jatak, voldtag min bankkonto" når browseren siger SSL-certifikatet er ugyldigt. Men hr og fru Jensen har det med at trykke 'jaja', og man må gå ud fra at en nationwide sikkerhedsløsning er relativt high-profile target - så det er måske ikke en dum idé med den ekstra SRP tunnel, selvom det er irriterende for folk med iPads? (og sølvpapirs-hat brigaden) :)
Som jeg forstår det, så snakker de decideret om, at bryde SSL krypteringen - ikke om at kommunikere med nogle andre via SSL, end dem man troede man kommunikerede med. I øvrigt kan serveren vel altid snyde folk til at aflevere brugernavn/password/engangskode udenom NemID?
Jeg savner simpelthen beskrivelse af et konkret trusselsbillede, hvor man får noget ud af denne teknik. Er det hvis SSL en dag bliver brudt? Er der en konkret svaghed, som man får lukket?
Jeg går ikke ud fra de havde smidt, formodentligt, en masse udviklerpenge efter det, hvis det ikke var nødvendigt.Er der nogen begrundelse for det, eller er det bare en påstand?
Nogen med kryptografisk baggrund må kunne svare mere konkret på hvad det skal beskytte imod - går ikke ud fra det giver ekstra beskyttel mod MITB (udover at det er sværere at manipulere med en applet, hvis din attack vector er injected javascript/whatever).
Men det kan vel hjælpe mod MITM angreb - disse er ikke helt trivielle når SSL er involveret, og vil i de fleste tilfælde kræve at brugeren trykker "jatak, voldtag min bankkonto" når browseren siger SSL-certifikatet er ugyldigt. Men hr og fru Jensen har det med at trykke 'jaja', og man må gå ud fra at en nationwide sikkerhedsløsning er relativt high-profile target - så det er måske ikke en dum idé med den ekstra SRP tunnel, selvom det er irriterende for folk med iPads? (og sølvpapirs-hat brigaden) :)
https://www.prosa.dk/aktuelt/prosabladet/artikel/artikel/nemid-svarer-p…...
Tak for linket. Som jeg forstår det siger DanID, at SSL ikke er tilstrækkeligt til at beskytte imod potentiel aflytning og ændring af kommunikationen mellem brugeren og autentifikationsserveren. Er der nogen begrundelse for det, eller er det bare en påstand?
"Hullet gør det muligt at videredirigere brugeren til en anden lokation, som f.eks. et remote share eller en angribende server, hvilket kan føre til plantning af binær kode på et sårbart system."
Forkert. For at exploite problemet skal du have kunnet plante kode på det lokale system - for eksempel ved omdirigering. Hullet er reelt nok, og ville måske kunne bruges i forbindelse med privilege escalation, men hvis du kan plante kode på en maskine er der muligvis større problemer end lige det her.
For en lidt mere fornuftig dækning af exploiten, se her: https://www.h-online.com/security/news/item/Java-vulnerability-demonstrates-file-planting-1277163.html
Mht. NemID bashing, så er der mening bag applet-galskaben: https://www.prosa.dk/aktuelt/prosabladet/artikel/artikel/nemid-svarer-paa-haard-kritik/?tx_prosamag_pi1[pageid]=4109 . TL;DR er "ekstra sikkerhed mod MITM via SRP-kanal, vi forsøgte med JavaScript men det var for langsomt".
De taler forbi hinanden. Det er meget sørgeligt at leverandøren prøver at berolige brugerne på den måde. Jeg ved godt at man ikke skal overdrive risikoen, men alligevel, DanID bør ikke være ligeglade med at deres software-grundlag (Java) bliver udsat for exploits, også selv om selve bank-transaktionerne ikke bliver truet.
Et sjovt lille sommer projekt kunne være at sætte en service sammen der emulerer en browser med en JRE, specfikt myntet på NemID logins. Denne lille service skal så fungere som proxy/man-in-the- middle, der oversætter requests imellem den officielle side og et custom HTML interface. Det har jeg før haft held med da min bank brugte SDC's gamle skod Java løsning.
En sådan officiel portal (nemmereid.dk?) vil være ganske ilde set af DanID pg.a. phishing, men til privat brug er det væl næppe ligefrem ulovligt. Nogen advokater til stede?
Baggrunden for at lave login med en Java applet forestiller jeg mig kan være tilsvarende: Med ren html kan man igen risikere at et script (igen under antagelse af at maskinen man benytter er kompromitteret) sender brugernavn+password til tredjepart. Så er der selvfølgelig stadigvæk en udfordring i at omgå pap-kortet.
Umidbart tror jeg mere bagrunden ligger i at det ved projekt start var planen nemid skulle overholde direktiv+lov om digital signatur, mens det efter at budgetter og tidsplaner begyndte at skride blev omdefineret således at man kun endte med at levere et single sign-on system. det forklare hvorfor appletten ikke forbliver pænt inden i sin sandbox.
Du har selvfølgelig ret i den observation, og så falder idéen ligesom til jorden, og det er vel -- i princippet -- også muligt at fake signaturen på en applet når man i forvejen har kompromitteret pågældende maskine.
[quote]...at forhindre hotspot konfigurationsfiler fra at blive indlæst fra den aktive arbejdsmappe...[quote]
Nogen der kan forklare en aldrende Java programmør, hvad disse konfigurationsfiler er for nogle? Og nu vi er i gang, hvad er en "aktiv" arbejdsmappe?
@Adam: Men hvis maskinen, man sidder ved er kompromitteret, og kan lave om i browserens hjemmesider, så kan man jo bare smide appletten ud a DOM'en og tilføje ens egen.
...og ups, jeg kom til at anmelde dig. Jeg klikkede forkert, og man kan ikke af-anmelde :(
@Henrik: Jo, jeg kan prøve.
De bekræftigelses-sider jeg tænker på er dem man eksempelvis får i sin netbank for at bekræfte en overførsel. Jeg kan ikke finde den artikkel jeg har i tankerne, men idéen er at det man indtaster i en konto-overførsels formular (eller lignende) kan være forskelligt fra det data der rent faktisk sendes til serveren, hvis man sidder ved en maskine der er kompromitteret, og kører noget funky javascript på netbank-siden. Men ved at vise det indtastede data i java applet'en gør man denne slags angreb betragteligt sværere.
Baggrunden for at lave login med en Java applet forestiller jeg mig kan være tilsvarende: Med ren html kan man igen risikere at et script (igen under antagelse af at maskinen man benytter er kompromitteret) sender brugernavn+password til tredjepart. Så er der selvfølgelig stadigvæk en udfordring i at omgå pap-kortet.
@Adam: Kan du ikke give et konkret case, hvor man får et bedre sikkerhedsniveau med udgangspunkt i en trussel. Hvad mener du med bekræftelses-sider? Hvis det er bekræftelsen af, at man er logget ind, hvorfor ville nogen så fuske med det?
Iøvrigt så er det et helt alvorligt spørgsmål, hvis nogen skulle være i tvivl. Jeg er ikke ude på at skyde DanID noget i skoene.
Bl.a. fordi de med java kan lave bekræftelses-sider der ikke er lige så nemme at fuske med, som html kan vha. JS+dom.
Desuden bruger de jo stadigvæk SSL.
I min verden halder den forskel i sammenhæng med programmeringssprog kun om formen af det fortolkede sprog. Eller måske næremere hvor tæt bundet mellemkoden er på det oprindelige sprog.JRE'en er ikke en fortolker, det er en virtuel maskine.
Det interessante er hvor godt køretidssystemet (om man så kalder det for det ene eller andet) er afgrænset fra resten af maskinen. Det er min opfattelse at JRE i NemID's tilfælde netop bruges på en måde hvor store dele af denne afgrænsning er slået fra (af grunde jeg dog ikke rigtigt har forstået).
"De fleste, der udnytter Java JRE, gør det i exploit kits og skyder med spredehagl".
Det skal nok passe, men hvad der er mere relevant og foruroligende, er at der er nogle få, der laver fuldstændigt målrettede og kompetente angreb.
Bagefter udtaler firmaet fra deres rygende ruin altid noget i retning med: "Ja, vi havde slet ikke regnet med et så målrettet angreb på lige vores service".
Det ville være dejligt at slippe for NemID-monopolet.
Jeg har endnu ikke forstået, hvorfor de bruger Java frem for SSL. Jeg forstår ikke, hvad de får ud af den manøvre (udover adgang til min harddisk).
Okay. Så claf efterfulgt af tekst giver åbenbart en overskrift. Suk.
Hvad er det helt konkret DanID har at være bekymrede over?
#Artikel "JRE er særlig interessant i dansk sammenhæng, fordi det er den fortolker, som NemID baserer sig på. " JRE'en er ikke en fortolker, det er en virtuel maskine.
"Hos Nets DanID, der står bag NemID, er man ikke nervøs for den nyopdagne sårbarhed i den teknologi, som NemID baserer sig på."
Det siger da vidst alt om DanID's holdning - Uanset hvad problemet er og hvor henne det ligger så er alt i bedste orden hvis man spørger DanID...!