DanID: Derfor bruger vi en signeret Java-applet

10. august 2010 kl. 10:0440
Den Java-applet, NemID bruger, kan læse alt på din computer, siger IT-politisk Forening. Det afviser DanID, som her forklarer grunden til den signerede Java-applet.
person
Artiklen er ældre end 30 dage
person

»Store huller i ny digital signatur« lyder det på forsiden af avisen Børsen tirsdag, med udgangspunkt i en kritik fra IT-Politisk Forening. Brugen af signeret Java-applet, når man skal logge ind med NemID, er en fejl, mener Niels Elgaard Larsen fra foreningen, for dermed får DanID fuld adgang til folks computer, lyder kritikken.

Læs også: NemID's Java-hul: Din bank kan snage i alt på din harddisk

DanID afviser blankt, at NemID's Java-applet indeholder funktioner, der kan bruges til at snage på folks computere. Men hvorfor overhovedet bruge en signeret applet, med så omfattende rettigheder, i stedet for en almindelig, som kører i sandbox og dermed er 'lukket inde'?

Det spørgsmål har DanID's udviklerteam besvaret skriftligt. Ifølge DanID ligger årsagen til valget af den signerede applet primært i, at man ville sikre kompatibilitet med ældre versioner af Apples Mac OS og med tidligere versioner af Java. For at minimere muligheden for misforståelser, bringer Version2 her svaret uredigeret:

Artiklen fortsætter efter annoncen

Ældre version af Mac OS understøtter ikke Liveconnect, som bruges til integration med brugerens browser. Liveconnect er koder, som binder browser og applet sammen og gør det muligt for DanID applet at kalde Javascript.

I ældre Mac OS versioner eksisterer Liveconnect ikke, og det er derfor nødvendigt at implementere applet-til-browser ved at applet etablerer en netværksforbindelse til service-udbyderen. Etablering af netforbindelse til serviceudbyderen kræver, at applet er signeret . Denne understøttelse er den samme som i Digital Signatur (OpenOCES).

DanID-applet benytter popups, for eksempel ved signering. Når applet laver et popup-vindue, vises en advarsel nederst i vinduet: ?Warning, applet window?. Denne advarsel vises ikke, hvis applet er signeret.

DanID-applet skal understøtte vedhæftede bilag. Disse bilag skal brugeren kunne gemme på disk. Al disktilgang fra applet til disken kræver, at applet er signeret. DanID applet's understøttelse for bilag er den samme som i Digital Signatur (OpenOCES).

Artiklen fortsætter efter annoncen

Jobs

Dine job
Vis alle

DanID-applet har indbygget egen load og caching af appletkomponenter. Tests har vist, at den indbyggede caching af Java-applet i Java's egen plugin er upålidelig og inkonsistent på tværs af Java-versioner, operativsystemer og browsere. Denne loader kræver, at DanID-applet er signeret.

DanID-applet benytter samme loader-mekanisme som findes i Digital Signatur (OpenOCES).

DanID-applet gemmer en fejllog på brugerens disk, som indeholder information, som gør det muligt for DanID-support at fejlsøge og udbedre fejl i applet. Denne fejllog er krypteret, så angribere ikke får adgang til informationer i loggen. Fejlloggen indeholder ikke personfølsom information. Disktilgang fra applet kræver, at applet er signeret.

Hvad mener du? Er det gode grunde til at bruge en signeret Java-applet?

Emner
40 kommentarer.  Hop til debatten
Denne artikel er gratis...

...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.

Køb abonnementFå prøveabonnement

Jobs

Dine job
Vis alle

Fortsæt din læsning

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
1
Claus Bruun
10. august 2010 kl. 10:25

Så for at implementere dokument signing i denne forkvaklede løsning hives sikkerheden på alm sso ned i knæ højde.

Jeg kunne godt tænke mig at kunne vælge SSO only mode via SSL og serverside uden applet overhovedet.

  • more_vert
    • insert_linkKopier link
29
Stig Larsen
10. august 2010 kl. 17:28

Måske ser vi nu den virkelige årsag bag Dan-ID, at installere en bagdør på alle computere.

  • more_vert
    • insert_linkKopier link
4
Jesper Lund
10. august 2010 kl. 10:40

Ifølge DanID ligger årsagen til valget af den signerede applet primært i, at man ville sikre kompatibilitet med ældre versioner af Apples Mac OS og med tidligere versioner af Java.

Hvis DanID havde valgt en løsning der ikke krævede installation af software på brugerens computer, kunne kompatibilitet med ældre versioner af java være ligegyldig.

Jeg tror at jeg vil lave en virtual machine (sandboxing) som alene bruges til netbank logon når nu det fantasiske NemID kommer til mig..

  • more_vert
    • insert_linkKopier link
7
Allan Ebdrup
10. august 2010 kl. 10:46

Ja og uden brug af Java ville nemId også virke på devices som iPad, PS3 osv. Hele argumentet om at nøglefilerne skal ligge centralt fordi det skal være nemt at logge ind overalt, går lidt fløjten når man så vælger en løsning, der ikke virker på alle devices.

De kunne altid lave en mulighed for at køre en applet, hvis der var brug for vedhæftede filer (men det må da kunne løses også uden java)

  • more_vert
    • insert_linkKopier link
6
Claus Bruun
10. august 2010 kl. 10:43

@Jesper

Men kommer vi så ikke til at lave en VM til banken, een til sundhed etc.

  • more_vert
    • insert_linkKopier link
10
Jesper Lund
10. august 2010 kl. 10:56

Men kommer vi så ikke til at lave en VM til banken, een til sundhed etc.

OCES delen bliver fravalgt når jeg bliver tvunget til at oprette NemID [1]. Min private nøgle skal kontrolleres af mig, og mig alene, og det udelukker OCES delen af NemID.

Det vil i øvrigt heller ikke hjælpe en pind med flere lokale VM'er da samkøringen mellem de forskellige logons sker på den (for dig) usikre centrale server.

[1] NemID er to helt separate løsninger: et netbank logon og noget som ITST kalder "digital signatur" (OCES delen). De har samme brugergrænseflade, baseret på OTP papkort, men så hører lighederne også op. NemID til netbanken er relativt uskyldig, selv om det ikke er så smart med et single sign-on hvis man har flere netbanker. Men OCES delen er en ubeskrivelig katastrofe, så den kommer jeg ikke til at benytte mig af.

  • more_vert
    • insert_linkKopier link
21
Jesper Mørch
10. august 2010 kl. 12:20

OCES delen bliver fravalgt når jeg bliver tvunget til at oprette NemID [1]. Min private nøgle skal kontrolleres af mig, og mig alene, og det udelukker OCES delen af NemID.

Som jeg har forstået det, har DanID alligevel adgang til din private OCES-nøgle. Du har bare ikke fået adgang til den hvis du fravælger OCES.

Jeg har tænkt mig at opsige min netbank, når det nærmer sig at mit registreringsnummer skal overgå til NemID. På den måde kan jeg håbe på at DanID ikke når at få oprettet et OCES-certifikat til mig før jeg afmelder det hele.

  • Indrømmet, jeg beholder min digitale OCES-signatur, som trods sine dårligdomme er klasser bedre end det hø PBS har strikket sammen. Den udløber først i maj-juni 2012, og til den tid har vi formentlig oplevet så massive problemer med NemID at de allerede har skullet forklare sig flere gange i f.eks. DRs Kontant. Den mediebevågenhed bør gøre, at man som almindelig borger her i landet ikke tvinges til at benytte NemID for at tilgå den offentlige forvaltning.
  • more_vert
    • insert_linkKopier link
13
Claus Bruun
10. august 2010 kl. 10:59

Men får man kun appletten, hvis man vælger OCES delen til ?

  • more_vert
    • insert_linkKopier link
15
Jesper Lund
10. august 2010 kl. 11:11

Men får man kun appletten, hvis man vælger OCES delen til ?

Nej, du undgår ikke appletten da UI er det samme for de to varianter af NemID. Men ved at fravælge OCES delen undgår du at der er en permanent "privat" nøgle uden for din (ene)kontrol. Netbank delen er, så vidt jeg har forstået teknikken, baseret på nogle temporære keys som kun eksisterer under den enkelte netbank session (altså reelt et password + OTP logon, uden at prætendere at være en "digital signatur", hvilket er fair nok).

  • more_vert
    • insert_linkKopier link
16
Jacob Pind
10. august 2010 kl. 11:19

deres loader er ovenikoebet obfuscate hvilket besvaerlige goere en analyse af hvad helvede den endlige laver.

  • more_vert
    • insert_linkKopier link
14
Per Michael Jensen
10. august 2010 kl. 11:09

Men får man kun appletten, hvis man vælger OCES delen til ?

DanID-applet benytter samme loader-mekanisme som findes i Digital Signatur (OpenOCES).

Hvad tror du?

  • more_vert
    • insert_linkKopier link
8
Søren Hilmer
10. august 2010 kl. 10:49

Las os se sourcen, i stedet for en lang forklaring. Så kan vi selv afgøre om den applet laver noget, vi ikke bryder os om.

  • more_vert
    • insert_linkKopier link
27
Jesper Louis Andersen
10. august 2010 kl. 14:12

Søren Hilmer rammer plet: Kildekode på applet'en så vi selv kan oversætte den. Jeg stoler mere på en kæde der ender i GCC end jeg stoler på DanID pt.

Iøvrigt er eet af de store problemer at standarden for NemID ikke mig bekendt er åben. Jeg vil kunne implementere alternative udgaver af standarden og kunne benytte dem mod DanIDs servere, tak. Det ville være i borgerens interesse med noget konkurrence på det område.

  • more_vert
    • insert_linkKopier link
30
Kai Birger Nielsen
10. august 2010 kl. 18:44

Jeg tror ikke at du får kildeteksten fra dem. Jeg spurgte efter orienteringsmødet i Århus og fik at vide at de ikke ville gøre det nemt for phishere at lave noget, der lignede på en prik.

Det er sikkert også derfor de ikke kan nøjes med en https form :-)

  • more_vert
    • insert_linkKopier link
28
Niels Dybdahl
10. august 2010 kl. 16:47

Hvorfor er gamle Mac-versioner vigtigere end mobiltelefoner?

  • more_vert
    • insert_linkKopier link
17
Dennis Krøger
10. august 2010 kl. 11:26

Så længe vi ikke kan køre med en udgave vi har compiled selv, er det umuligt at være sikker på at den source vi får at se, svarer til det der rent faktisk bliver kørt.

  • more_vert
    • insert_linkKopier link
18
Henrik Stig Jørgensen
10. august 2010 kl. 11:42

Så længe vi ikke kan køre med en udgave vi har compiled selv, er det umuligt at være sikker på at den source vi får at se, svarer til det der rent faktisk bliver kørt.

Nej, det ville det alligevel være. En signed applet har fuld adgang til alle JFC-classes; DanID kan til enhver tid kalde Runtime.exec() eller bootstrappe nye jars gennem URLClassloader.

Men hvorfor denne fokus på privacy på lokalmaskinen når det nu forholder sig sådan, at NemID også kan bruges af DanID til at tømme din bankkonto, sælge din elektroniske patientjournal eller din straffeattest til højestbydende, eller bedrage andre med din identitet. Er dette trods alt ikke værre end den java-applet?

  • more_vert
    • insert_linkKopier link
20
Claus Bruun
10. august 2010 kl. 12:04

@Henrik

Det er bestemt også vigtigt - om ikke vigtigere, men diskussionen gik her på appletten, og hvis ikke engang det kan laves rigtigt sætter det det andet endnu mere i perspektiv...

  • more_vert
    • insert_linkKopier link
19
Jakob Hansen
10. august 2010 kl. 11:59

Der burde være en måde hvorpå man kunne sandboxe plugins til browseren, fx java plugins. Det løser selvfølgelig ikke det oprindelige problem, men så kunne man nemmere styre og se hvad NemID foretog sig på ens computer. Måske findes der allerede sådan en løsning?

  • more_vert
    • insert_linkKopier link
22
Niels Dybdahl
10. august 2010 kl. 12:38

Der burde være en måde hvorpå man kunne sandboxe plugins til browseren, fx java plugins. ... Måske findes der allerede sådan en løsning?

Den findes også: Nemlig undlad at signere appletten. Så kører appletten automatisk i en sandbox og den får ikke adgang til noget på den lokale PC bortset fra skærm og tastatur.

Den løsning burde være valgt fremfor en signeret applet når der ikke er nogen tvingende grund til ikke at køre i en sandbox.

Jeg har iøvrigt lige prøvet Jyske Netbank på min Androidtelefon. Jyske Netbank har hidtil kørt med en lignende papkorts løsning og den virker fint på mobiltelefonen. Hvad er argumentet for at DanIDs løsning ikke gør det?

  • more_vert
    • insert_linkKopier link
24
Erik Martino Hansen
10. august 2010 kl. 13:07

Bortset fra lokal logging ned i en fil kan det hele vel skrives i Javascript. Dermed kunne man undgå en masse support og have bedre understøttelse af mobile enheder.

  • more_vert
    • insert_linkKopier link
25
Klaus Skelbæk Madsen
10. august 2010 kl. 13:39

Hvad ville du bruge JavaScript til? En HTML form der poster over en SSL forbindelse burde være rigeligt?

  • more_vert
    • insert_linkKopier link
31
Erik Martino Hansen
10. august 2010 kl. 19:43

https form's gør det også nemmere at lave "man in the middle" angreb. Mange sites ikke har certifikater udstet af en rigtig CA, det gør at brugere blive vænnet til at acceptere hjemmelavede certifikater.

Accepterer moderne browsere stadig fusker certifikater fremstillet ved MD5 kollisioner?

http://www.phreedom.org/research/rogue-ca/

  • more_vert
    • insert_linkKopier link
32
Stig Albjerg
10. august 2010 kl. 22:52

Da display på mit Active Card til Danske Bank for en måned siden fejlede, fik jeg gennem banken en NemID. Det har ikke været muligt for Danske Banks og DanIDs supportere at få NemID til at fungere på min PowerPC Macintosh med Mac OS 10.4.11. Den ældre Mac blev for nogle dage siden endelig erklæret for uegnet til NemID, og i formiddags ankom et nyt Active Card med posten. Det sætter DanIDs erklæring om hensyn til ældre Macintosh i et noget tvetydigt lys, synes jeg.
Efter forgæves forsøg med indlogning på NemID, fandt jeg tilfældigt en fil med navnet danid.log på 80K i mit user directory på grund-niveau. Filens oprettelses- og redigerings-tidspunkter stemte med forsøg på at logge på NemID. Efter endnu et par forsøg for nogle dage siden voksede filen til 120K. Filen var/er ikke gjort usynlig. Den er ikke læsbar for mennesker. Jeg blev ubehagelig tilpas, da jeg fandt den fil, som tydeligt demonstrerede hvad "Trust" til en Java applet indebærer. Den tyder også på, at programmørerne ikke har styr på (ældre) Mac maskiner. I øvrigt kræver Active Card til Danske Bank også, at man siger "Trust" til en Java applet. Det har jeg med let ubehag gjort masser af gange de seneste år. Jeg har aldrig forstået hvorfor det skulle være nødvendigt med den applet til Active Card - og har aldrig fået en rimelig forklaring fra Danske Banks venlige supportere. (Adgang med Active Card virker ikke, med mindre Java applet får fuld adgang). Jeg forstår heller ikke, at en applet med fuld maskin-adgang skal være nødvendig for at kunne være med i NemID. Hvis Big Brother ikke har skumle hensigter, er det overordentlig stupidt med det krav.

  • more_vert
    • insert_linkKopier link
38
Henrik Mikael Kristensen
13. august 2010 kl. 17:47

Efter forgæves forsøg med indlogning på NemID, fandt jeg tilfældigt en fil med navnet danid.log på 80K i mit user directory på grund-niveau. Filens oprettelses- og redigerings-tidspunkter stemte med forsøg på at logge på NemID.
Efter endnu et par forsøg for nogle dage siden voksede filen til 120K.
Filen var/er ikke gjort usynlig. Den er ikke læsbar for mennesker.
Jeg blev ubehagelig tilpas, da jeg fandt den fil, som tydeligt demonstrerede hvad "Trust" til en Java applet indebærer.

Den kan jeg slå: Jeg har også en danid.log fil på 20 kb i mit homedir på min Snow Leopard Intel Macbook, dateret den 1. juli 2010. Filen er ikke menneskeligt læsbar, har 33 nummererede entries som er base 64 encodede binaries og ligger bare og flyder synligt i Finder.

Det der gør [i]mig[/i] utilpas, er at jeg har ikke forsøgt at bruge NemID overhovedet, og jeg kan ikke få datoen til at passe med aktivitet med hverken netbank eller andre ting.

Edit:

http://groups.google.com/group/dk.edb.sikkerhed/browse_thread/thread/9b8e130e77f3303b#

  • more_vert
    • insert_linkKopier link
39
Axel Hammerschmidt
13. august 2010 kl. 18:50

Jeg har heller ikke Nem-id pt, men jeg har brugt noget der ligner til at komme på min pensionskasses hjemmeside. Det forgik på næsten samme måde som med Nem-id: jeg loggede på over en netbank konto hos Jyske Bank.

Kan det muligvis ikke være der - eller et lignende tilfælde - din danid.log fil stammer?

Jeg vil undersøge mine computere for, om filen findes osse hos mig. Jeg kan ikke lige huske hvilken computer jeg brugte til DIP.

  • more_vert
    • insert_linkKopier link
40
Jesper Kristensen
13. august 2010 kl. 21:04

Kære DanID i bytter om på årsag og virkning, og så blander i fuldstændigt irrelevante ting ind i billedet.

Jeres 6 begrundelser:

1: Kommunikation mellem Java og JavaScript på Mac. Årsag og virkning - der bruges ikke en signeret Java-applet på grund af dette problem. Dette problem eksisterer på grund af at i bruger en signeret Java-applet.

2: Popups. Igen årsag og virkning - uden Java ville det ikke være et problem at lave popups. Desuden er en "Warning, applet window" noget mere harmløs end den store farlige "Java Security Warning" i viser nu.

3: Adgang til bilag. irrelevant - Der skal ikke håndteres nogen som helst form for bilag ved login til en hjemmeside. Hvis en eller anden service baseret på NemID har brug for at håndtere bilag kan det implementeres uafhængigt. Det kan implementeres i en signeret Java-applet hvis i er dovne, eller det kan implementeres sikkert med lidt HTML-snilde.

4: Java load og caching. Igen årsag og virkning - I har ikke brug for alt muligt underligt Java-load hvis i ikke bruger en signeret Java-applet.

5: Baseret på Digital Signatur / OpenOCES. irrelevant - bare fordi andre har lavet noget klamp før jer betyder det ikke at i også skal gøre det. De forrige løsninger havde dog en legitim grund til at få adgang, nemlig for at læse den private nøgle. Alt andet de brugte adgangen til burde de heller ikke have gjort.

6: Fejllog. Igen årsag og virkning - Hvis i ikke brugte Java og alle mulige system-specifikke ting, var der ikke så meget der kunne gå galt og ingen grund til at have en fejllog. Der er desuden masser af andre måder at lave en fejllog på, der ikke kræver adgang til disken.

Og så er problemet heller ikke (hovedsageligt) hvad i bruger adgangen til. Problemet er at i spørger efter den.

Jeres rigtige login-skærm ligner et phishing-attack så godt (med sikkerhedsadvarsler og arbitrære domænenavne), at man ikke har nogen som helst chance for at opdage, hvis man støder på et rigtigt phishing-attack mod NemID.

  • more_vert
    • insert_linkKopier link
41
Flemming Riis
13. august 2010 kl. 21:27

21:11:57,7495541 java.exe 1988 CreateFile C:\Users\FR\danid.log SUCCESS Desired Access: Generic Write, Read Attributes, Disposition: OpenIf, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: 0, OpenResult: Opened 21:11:57,7495960 java.exe 1988 QueryStandardInformationFile C:\Users\FR\danid.log SUCCESS AllocationSize: 221.184, EndOfFile: 217.652, NumberOfLinks: 1, DeletePending: False, Directory: False 21:11:57,7496049 java.exe 1988 WriteFile C:\Users\FR\danid.log SUCCESS Offset: 217.652, Length: 606, Priority: Normal 21:11:57,7496368 java.exe 1988 CloseFile C:\Users\FR\danid.log SUCCESS

Må da håbe at man over tid at de selv sletter loggen :) samt jar cache som de heller ikke rydder op i (ved ikke om det egentelig er jvm ansvar)

  • more_vert
    • insert_linkKopier link
36
Axel Hammerschmidt
11. august 2010 kl. 17:14

Gælder selvfølgelig i det tilfælde Windows XP.

  • more_vert
    • insert_linkKopier link
37
Axel Hammerschmidt
13. august 2010 kl. 17:12

Og så bør man springe Step 3 over i den opskrift om Group Policy, så man under alle omstændigheder ikke åbner for Mærsk-virus.

  • more_vert
    • insert_linkKopier link
34
Niels Dybdahl
11. august 2010 kl. 07:54

Kan man ikke blot eksplicit angive i applet'en hvad man vil have adgang til (fremfor hele disken) og så ellers tilbyde folk en Java policy file som sikrer at DanID ikke kan lave andet end logge til en bestemt fil m.m?

Nej det synes jeg ikke er ok. Som andre har påpeget er logning ikke nødvendig på den lokale PC. Det kan gøres på serveren.

Man kan også løse problemet med de gamle Macer ved at lade "normale" brugere logge på med en usigneret applet (sandbox) og så lade gamle Macer få en alternativ login med en signeret applet.

Men så kommer spørgsmålet med mobiltelefoner som ikke kan køre javaappletter. Så vidt jeg har forstået er hovedårsagen til at der vælges en javaapplet fremfor en javascript løsning (som jyskenetbank pt har til deres lignende løsning) at det skal være sværere for phishere. Jeg synes ikke at det er betryggende hvis beskyttelsen mod phishere ligger i at det er "svært" at efterligne et design på en brugerflade. Jeg håber at DanID i det mindste har skrevet grundreglen mod phishere på loginsiden (log aldrig ind via et tilsendt link). Hvis phisherne kopierer alt fra loginsiden, så advarer de mod sig selv, hvis ikke, så afviger de en del fra det oprindelige design.

  • more_vert
    • insert_linkKopier link
26
Henrik Pedersen
10. august 2010 kl. 13:46

DanID vil jo bare gøre det mere besværligt en det er i forvejen, så hvorfor ikke gøre det besværligt i form af en (for brugernes private oplysninger) sikker metode som javascript?

  • Yup jeg har intet til overs for dem...
  • more_vert
    • insert_linkKopier link
23
Henrik Schmidt
10. august 2010 kl. 13:00

Det, som de har svaret på er hvorfor appletten skal være signeret. Altså signeret vs. ikke-signeret applet.

Det, der er interessant er hvorfor de overhovedet har brug for en applet. Hele idéen med NemID er at flytte mekanismen fra folks egne computere til NemID's servere.

En signeret applet var et nødvendigt onde med digital signatur fordi den private nøgle lå på brugerens computer. Det gør den ikke længere, så hvorfor skal NemID have adgang? Pga. en log-fil? Kan de ikke lave den på server siden?

Helt ærligt, NemID, kom ind i kampen.

  • more_vert
    • insert_linkKopier link
9
Claus Bruun
10. august 2010 kl. 10:52

Enig - det her er så vigtigt for samfundet at OS bør være et krav - man må vel antage, at der ikke er noget at skjule...

  • more_vert
    • insert_linkKopier link
12
Claus Bruun
10. august 2010 kl. 10:56

@Version2

Kunne I ikke følge op på, om DanID vil offentliggøre sourcen til appletten - og hvis ikke, gå dem på klingen hvorfor ?

  • more_vert
    • insert_linkKopier link
2
Jesper Udby
10. august 2010 kl. 10:37

Hvis det er nødvendigt fra en browser at tilgå (læse) filer på brugerens harddisk (uden disse sendes over linien), så skal der enten en signeret applet til, eller noget ligeså gustent (windowsspecifikt) plug-in til.

Og det er der ikke noget nyt i, sådan har (de fleste) internetbanker fungeret siden sidst i 90'erne...

  • more_vert
    • insert_linkKopier link
3
Claus Bruun
10. august 2010 kl. 10:39

Men der var en grund - din keyfil var på den lokale disk! I den nye løsning er alt på DanID's servere + papkort, hvorfor der ikke behøves noget på den lokale maskine udover SSL

  • more_vert
    • insert_linkKopier link
5
Jesper Udby
10. august 2010 kl. 10:43

Glimrende pointe.

Men spørgsmålet der blev stillet var:

Hvad mener du? Er det gode grunde til at bruge en signeret Java-applet?

Og hvis man (jeg ved ikke af hvilken grund) har behov for at tilgå filer på brugerens harddisk via en java-applet, så skal den være signeret...

  • more_vert
    • insert_linkKopier link
11
Nils Bøjden
10. august 2010 kl. 10:56

Og det må man så sige at de påstår at de har:

"DanID-applet gemmer en fejllog på brugerens disk, som indeholder information, som gør det muligt for DanID-support at fejlsøge og udbedre fejl i applet"

Hvorfor man ikke sender disse info når det er nødvendigt fra en cache kan man så spekulere på. Kun ved at have tilgang til NemID design specseller tilgang til koden, har man mulighed for at se og gennemskue de rationaler som ligger til grund for design.

For øvrigt vil vi ikke få adgang til koden, da DanID også ved tidlige lejligheder har påberåbt sig brugen af "Security by Obscurity". Her tænker jeg bla. på de processer man har til at håndtere DDOS angreb.

  • more_vert
    • insert_linkKopier link