Smugkig på lukket test: Se en demo af NemID JavaScript her

4. juni 2014 kl. 06:2921
Den kommende NemID JS er tilgængelig som demo hos firmaet Asseco Denmark A/S, der bekræfter at koden bag demoen kommer direkte fra Nets.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Kan du ikke vente, til det bliver den 1. juli, hvor Digitaliseringsstyrelsen har bebudet at NemID baseret på JavaScript i stedet for Java, bliver frigivet? Så har du chancen for at smugkig på en demo af en foreløbig NemID JS-løsning på hjemmesiden PortalProtect.

Det er firmaet Asseco Denmark A/S, der står bag PortalProtect, der på produktes hjemmeside beskrives som en sikkerhedsinfrastruktur til blandt andet portaler. Hjemmesiden oplister både DanID (ejet af Nets, som står bag NemID), Nykredit og Patent- og Varemærkestyrelsen blandt sine kunder. En af de login-løsninger, som PortalProtect understøtter, er NemID, og herunder altså en demo af NemID JS. Og koden bag den demo, kommer fra Nets, forklarer adm. direktør i Asseco Denmark A/S Torben Falholt.

»Javascript-delen er noget, som udelukkende laves af Nets, vi henter deres kode og eksekverer den i vores løsning (authentication og authorization). Den hentes i en form, som ikke umiddelbart er læsbar eller meningsfuld - men altså eksekverbar,« oplyser han i en mail til Version2.

Han fortæller endvidere:

Artiklen fortsætter efter annoncen

»Vi forsøger ud fra den dokumentation som de (Nets, red.) udgiver at være på forkant med PortalProtect, så vi meget meget hurtigt kan få vores kunder til at anvende de nye funktioner - når de engang måtte blive lagt i produktion.«

Det er også den samme NemID JS demoside, datalog og internetaktivist Christian Panton har kigget på, da han med egne ord var ved at få kaffen galt i halsen på grund af brugen af obfuskering i test-versionen af NemID JS. Obfuskering vil sige, at koden er gjort bevidst kompliceret - eksempelvis for at forhindre kriminelle i at finde og udnytte sikkerhedshuller i softwaren.

En oplevelse, der har fået Christian Panton til at iværksætte et de-obfuscator projekt på webhosting-tjenesten for softwareprojekter GitHub. De-obfuscatoren er et stykke software, der har til formål at reducere kompleksiteten i NemID JS. Christian Panton fortæller, at de dele af NemID JS-koden, han har analyseret med de-obfuscatoren, har resultereret i en reduktion af kodestørrelsen på ca. 33 pct.

Løsningen kan ses her. Af PortalProtect-siden fremgår det dog, at der kræves et brugernavn og en adgangskode, der skal være oprettet i DanID's testsystem, hvis det skal være muligt at logge ind med løsningen.

Artiklen fortsætter efter annoncen

Version2 har stillet en stribe spørgsmål til Digitaliseringsstyrelsen og Nets, som blandt andet går på brugen af obfuskering i NemID JavaScript. Digitaliseringsstyrelsen henviser til Nets. Og Nets ønsker ikke at kommentere løsningen med henvisning til, at den endnu ikke er endeligt frigivet.

Fakta

NemID JavaScript er betegnelsen for den kommende udgave af NemID, som fungerer uden Java-platformen. Flere har kritiseret, at NemID i den nuværende form er afhængig af Java. Kritikken har blandt andet gået på, at sikkerhedshuller i Java i sig selv kan gøre en computer usikker, og desuden virker Java og dermed NemID typisk ikke på mobiltelefoner og tablets. Med til historien om NemID og Java hører opdateringen fra Oracle, der står bag Java, som sidste år bevirkede at NemID i tre døgn ikke fungerede hos de brugere, der havde fulgt gængs sikkerhedspraksis og opdateret til den seneste Java. Senere kom det frem, at Nets ikke havde testet om NemID ville virke med den nye opdatering fra Oracle.

Digitaliseringsstyrelsen forventer, at NemID JS, trods problemer i forbindelse med en planlagt pilottest, som planlagt bliver lanceret 1. juli.

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

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
19
5. juni 2014 kl. 18:35

Tager cirka 10s at få applet frem på Nexus 5 med Chrome. Kortere på Chromebook. Dejligt at være kbit for det java skidt.

18
5. juni 2014 kl. 18:35

Tager cirka 10s at få applet frem på Nexus 5 med Chrome. Kortere på Chromebook. Dejligt at være kbit for det java skidt.

15
4. juni 2014 kl. 14:59

Så nu bliver det umuligt for den almindelige bruger at tjekke at man sender sit password til DanID. Før kunne man da i det mindste få Java til at fortælle hvilket domæne man afvikler kode fra. Hvorfor bekymrer dette ikke DanID?

11
4. juni 2014 kl. 10:46

Jeg har en low-end smartphone. Efter 36 sekunder crasher min browser.

8
4. juni 2014 kl. 09:04

Jeg håber det her ikke er deres endelig kode, for den virker ikke på iOS devices eller for den sags skyld Safari på en mac.

4
4. juni 2014 kl. 08:35

Der er mange der konsekvent nævner at security through obscurity ikke virker. De samme mennesker brokker sig i disse threads over at koden er obfuscated så den ikke er nem at læse. Ud fra det kan jeg vel kun sige.. Goal achieved? Det kan godt være at der er en del mennesker som kan omgå obfusceringen, men ved at bruge det koster det trods alt en god investering af tid som man skal bruge på at omgå den (deobfuscere, whatever), og det synes jeg sådan set er fornuftigt. Nets bør i min mening ikke være underlagt at det skal være nemt at finde fejl for fremmede, tværtimod. Så længe det er nemt for dem selv. De idealister som tror at "fri kildetekst" automatisk betyder at 4 millioner danskere gennemgår source for fejl har ikke hørt om Heartbleed buggen. (Undskylder på forhånd for at have en "upopulær" mening på v2.. jeg ved godt det ikke er velset ikke at hoppe på flame vognen.)

10
4. juni 2014 kl. 10:18

Der er mange der konsekvent nævner at security through obscurity ikke virker.
De samme mennesker brokker sig i disse threads over at koden er obfuscated så den ikke er nem at læse. Ud fra det kan jeg vel kun sige.. Goal achieved?

Det er almen viden at obfuscation ikke på nogen måde bidrager til sikkerheden i et system, og i udpræget grad på et non-compiled sprog, det er allerhøjst et minimalt fartbump på vejen før der ligger værktøjer ala Christian Pantons på github, som skaber en forholdsvis læsbar version af koden, og hvad er det så lige man har opnået?

Men, min pointe gik ikke så meget på obfuskeringen direkte, men mere at der har siddet mennesker som skulle have forstand på sikkerhed, og besluttet at bruge tid på dette, og det muligvis bidrager til at opfylde et overordnet succeskriterie, og det skræmmer mig umådeligt.

Tag et skridt tilbage og se på at der med den nuværende version af NemID har siddet folk "på kald" 24 timer i døgnet, spoofet websider på brugeres maskiner og lavet live logins samtidigt med at folk tror de logger normalt på, og overvej om det her på nogen måde skulle sætte en stopklods for dem?

Talentløst, uambitiøst og forfærdeligt er tanker der slår mig .. Hvis din sikkerhedsmæssige kode ikke tåler dagens lys, så må antagelsen være at den nok ikke er sikker nok til at begynde med.

9
4. juni 2014 kl. 09:22

De idealister som tror at "fri kildetekst" automatisk betyder at 4 millioner danskere gennemgår source for fejl har ikke hørt om Heartbleed buggen.

  1. Mener du at INGEN havde opdaget HeartBleed fejlen før den kom frem, eller mener du at alle de store firmaer som har brugt OpenSSL havde brugt ressourcer på at forstå eller lave review koden og bare lod det passere fordi de mente at det ikke var vigtigt?

  2. Mener du at de selvsamme firmaer ville have lavet bedre kode review hvis det var deres egen kode de havde brugt?

  3. Såfremt de havde lavet kode review, ville de så have forstået problemet og rettet det uden at sige noget om det til omverdenen (måske for at undgå at firmaets renommé skulle lide skade) og dermed efterlade mange mange servere potentielt ubeskyttet i meget lang tid, eller mener du at de ville informere om problemet (og dermed måske sænke firmaets værdi) så verden potentielt kunne blive et sikrere sted at bo?

  4. Jeg tror da ikke at nogen, i hvert fald ikke undertegnede, har skrevet at 4 millioner danskere automatisk ville gennemgå source koden. Det kræver sådan set bare et enkelt ansvarligt individ der gør det... Mon ikke der findes bare een ansvarlig person derude?

  5. Hvis der er fejl i koden, vil du så helst satse på at et af de store firmaer der har benyttet sig af OpenSSL afsætter midler til og har så god forståelse for sikkerheden at de kunne finde fejlen, eller vil du helst satse på at der er bare een ansvarlig person derude som kigger koden igennem og finder fejlen før eller siden.

Nå, nok om det :-)

7
4. juni 2014 kl. 09:03

og det synes jeg sådan set er fornuftigt. Nets bør i min mening ikke være underlagt at det skal være nemt at finde fejl for fremmede, tværtimod. Så længe det er nemt for dem selv.

@Morten

  1. Mener du at det at man holder de værste opportunister væk bidrager til reel sikkerhed i systemet?

  2. Mener du at sikkerheden i et, for Danmark, kritisk system, skal være baseret på at teenagehackere har svært ved at læse koden ?

  3. Foretrækker du ikke at løsningen skal være baseret på et system hvor alle ved hvordan man gør, men ingen kan gøre det fordi det kræver flere computer ressourcer end der vil findes på jorden inden for de næste mange mange år?

6
4. juni 2014 kl. 08:44

Der er mange der konsekvent nævner at security through obscurity ikke virker.
De samme mennesker brokker sig i disse threads over at koden er obfuscated så den ikke er nem at læse. Ud fra det kan jeg vel kun sige.. Goal achieved?

What a load of c...! Hvis man obfuskerer sin kode sikrer man alt andet lige at forholdet blackHat/whiteHat stiger, hvilket er ekstremt farligt! Whitehats (folk, der bare kigger på koden for sjov uden onde bagtanker) vil nemlig ikke gide bruge tid på det, mens blackhats aldrig vil lade sig stoppe af sådan en bagatel.

5
4. juni 2014 kl. 08:42

Jeg synes din pointe er helt relevant. Det var da også først da jeg lagde meget energi i det at jeg fik analyseret Java versionen. Men jeg vil gerne lægge den energi i det, og hvad har obfuskeringen så haft af effekt? Kriminelle har endda et budget til det.

Men der er andre omkostninger end bare "åben kilde". Min browser fryser i ca. 10 sekunder imens den dekrypterer og parser en >500kb non-cacheable Javascript fil. Jeg tør ikke tænke på hvad det betyder på en medium/low-end smartphone.

12
4. juni 2014 kl. 11:52

Loader på 5 s på min maskine. Java-versionen tager 8 s, så en forbedring er det da. (Windows 8.1, IE11, Java 8)

Den crasher ikke min Lumia 925, men efter at have kigget på timeglas i 6 minutter, vil jeg sige, at "den virker ikke".

13
4. juni 2014 kl. 12:29

25 sekunder på min 925

14
4. juni 2014 kl. 14:24

Ikke dårligt. Min vil ikke. Jeg tror, serveren er overbelastet, for der sker lidt forskelligt fra forsøg til forsøg.

16
4. juni 2014 kl. 16:15

Også 25 sek. på en samsung galaxy tab 3 (tablet), og 65 sek. på en samsung galaxy xcover 2 (mobil). Lad os håbe det kun er testversionen der er så langsom, for det er jo ubrugeligt i praksis. De fleste vil jo tro der er fejl på siden og det ikke virker.

3
4. juni 2014 kl. 08:27

Det er helt håbløst at bruge krudt på at obfuscate kode hvor source er direkte tilgængelig for brugeren.

Endnu mere foruroligende er det hvis beslutningsgrundlaget for dette er sikkerhedsmæssig, for det belyser da i allerhøjeste grad kompetenceniveauet.

2
4. juni 2014 kl. 08:07

...eksempelvis for at forhindre kriminelle i at finde og udnytte sikkerhedshuller i softwaren.

Mon det nu ikke var bedre at lade koden være i klartekst så vi kan finde og luse ud i nogen af de der sikkerhedshuller der måske/måske ikke findes i koden?

Danmark er en nation bestående af dygtige mennesker med et højt uddannelses niveau, og der er givetvis masser af frivillige at tage af, så mon ikke det var en mulighed?

  1. Har man mon ikke lært at security through obscurity ikke virker?

..og at det ikke forhindrer en beslutsom black hat/organisation i at knække sikkerheden. Det kan allerhøjest holde de værste oppertunistiske mindreårige hackere væk(selvom nogen af dem er rigtigt dygtige).

  1. Man mener måske at dette stykke kritiske kode indeholder fejl som selv en amatør hacker kan finde? (selvom nogen af dem er rigtigt dygtige)

I tilgift kan obfuskering måske endda hjælpe til at fjerne vildledende* variabelnavne og efterlade algoritmen synlig så man, i nogen tilfælde, lettere kan finde fejl. Man kunne således argumentere for at man bør lave sikkerheds audit på klartekst versionen såvel som en obfuskeret version.

I det ovenstående skal "vildledende" forstås som noget som får en til at tro at koden gør noget andet end den gør.

:-)

HC

21
10. juni 2014 kl. 13:08