Digitaliseringsstyrelsen giver ’go’ til NemID på mobile enheder

Nets DanID kan nu begynde udviklingen af NemID baseret på JavaScript, efter Digitaliseringsstyrelsen har vendt tommelfingeren opad. Det nye NemID vil være klar i andet kvartal 2014 og koster samlet 47 millioner kroner.

Den længe ventede understøttelse af NemID på mobile enheder ser nu ud til at blive en realitet. Digitaliseringsstyrelsen har netop meddelt, at Nets DanID vil udvikle en JavaScript-udgave af NemID, der bl.a. kan afvikles på mobile enheder, og at den vil være klar i andet kvartal 2014.

Læs også: Grønt lys for NemID på Javascript: Login fra mobilen klar om et år

Nets DanID er allerede i gang med at udvikle løsningen til bankerne - og har også arbejdet på løsningen til det offentlige inden meldingen i dag. I maj kom det frem, at bankerne allerede har takket ja til en JavaScript-løsning fra Nets DanID.

Læs også: Nets klar med NemID på Javascript om et år - trods manglende 'go' fra det offentlige

Den samlede pris for at få NemID til at virke på mobile enheder bliver 47 millioner kroner, som bankerne og den offentlige sektor hver betaler halvdelen af.

Da Digitaliseringsstyrelsen begyndte arbejdet med et alternativ til den nuværende NemID-Java-applet, blev der sat otte millioner kroner af til opgaven. Men en analyse af de forskellige muligheder, og et prisoverslag for dem, afslørede, at det ikke var nok. Prisen ville ende på mellem 15 og 30 millioner kroner. Derfor kunne styrelsen ikke leve op til den først udmeldte deadline om NemID på mobile enheder inden udgangen af 2012.

Læs også: NemID uden Java nærmer sig

Det har i flere år været muligt at bruge NemID i diverse mobilapplikationer - blandt andet i bankernes. Her er der dog ikke tale om reel understøttelse af NemID på mobilen. NemID kører i øjeblikket Java, der ikke kan afvikles på mobile styresystemer som iOS, Android og Windows Phone.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (13)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Hans Schou

Der står ikke rigtigt noget i pressemeddelelsen om det, men jeg gætter på at man også kan bruge et almindeligt EDB-apparat til NemID, og Java-udgaven dermed bliver skrottet.

Om ikke andet; det lyder godt med en løsning hvor man ikke skal installere lukket og fremmed software på sit apparat, for at få adgang til sin bank eller EPJ-data. Så hopper jeg sgu med på NemID-vognen, når det kommer.

Rene Madsen

Kan det virkelig være rigtigt at det kommer til at tage 10 mand 1 år at lave en javascript udgave af NemID login delen? Har antaget de koster 1000,-/t.

Påfaldende som Nets ligner nedenstående...

"I care not what puppet is placed on
the throne of England to rule the Empire, ...
The man that controls Britain's money
supply controls the British Empire.
And I control the money supply."

Baron Nathan Mayer Rothschild, 1777-1836

Marc Kammersgaard

Det lyder da helt vanvittigt, man kan jo nærmest bygge systemet nyt helt fra bunden til den pris, men kan selvfølgelig også være man gør det bag om scenen.

"Den samlede pris for at få NemID til at virke på mobile enheder bliver 47 millioner kroner, som bankerne og den offentlige sektor hver betaler halvdelen af."

Bankkunderne*

Martin Slot

Er der nogen system arkitekter der kan forklare mig hvordan det kan koste 47 millioner at lave det om? Lige umiddelbart lyder det til at de skal lave dele af det bagved system om, samt vælger de måske at lave noget refaktorering og ekstra funktionalitet med oveni?

Lige umiddelbart lyder det i mine ører til at de er hårdt koblet af Java og appletten. Sådan opfatter jeg det ihvertfald! Hvis overstående postulat er sandt, så er systemet dårligt skruet sammen.

Jørgen Elgaard Larsen

Er der nogen system arkitekter der kan forklare mig hvordan det kan koste 47 millioner at lave det om?

Jeg kan umiddelbart komme på fem mulige forklaringer:

1) Det eksisterende system er unødigt kompliceret og dårligt designet. At skulle
kliste en JavaScript-løsning ovenpå kræver omfattende ændringer, fordi det aldrig
er blevet overvejet fra starten af, at det kunne blive nødvendigt.

2) Der er efter alt at dømme en mainframe involveret i systemet (at dømme efter den
manglende skelnen mellem små og store bogstaver). Mainframes kan være dyre. Alene
at få sat et udviklings- og testmiljø op kan sagtens koste millioner. Dertil skal
man betale for MIPS (processorforbrug) undervejs. Og så er mainframe-konsulenter
ofte dyre.

3) Hvis man har valgt at outsource udviklingen kan det blive betydeligt dyrere end
normalt, fordi man nu både skal betale en masse indere og en masse danskere
til at holde styr på inderne.

4) Det kan skyldes, at projektet er overbemandet og underkvalificeret.

5) Det har muligvis ikke noget med udviklingsomkostninger at gøre. Lige nu er der
et voldsomt politisk pres for at afskaffe Java. DanID har monopol på at udvikle
alternativet. Prisen sættes derefter.

Personligt vil jeg tro, at grund nr. 5) er den mest sandsynlige, tilsat en uskøn blanding af de øvrige.

Morten Winther

Hvad skal man i det hele taget med javascript til nemID? Er der ikke tale om en <form><input type="text" name="engangskode"><input type="submit"></form>

Er meget spændt på at se hvor meget javascript man kan få for 47/15 mio og hvad det skal gøre? Lave et unikt fingerprint? Der må være mere?

Security through obscurity - here we go.

Jari Wiklund

Mon ikke <form> bliver udvidet til <form onsubmit="return encrypt()">, eller noget vildere. Og helst at formen bliver genereret af javascript clientside, så man er sikker på at javascript er sat til i brugerens browser.
Så kunne encrypt funktionen basere sig på noget arbejde á la det her: http://www.hanewin.net/encrypt/
Men hvordan det skal koste så mange millioner, går sgu også over min forstand. De kunne jo også have valgt at det kun er web-login/authentication, som skulle javascriptes og så lade diverse eksisterende løsninger køre videre som java løsninger.

Finn Christensen

5) Det har muligvis ikke noget med udviklingsomkostninger at gøre. Lige nu er der
et voldsomt politisk pres for at afskaffe Java. DanID har monopol på at udvikle
alternativet. Prisen sættes derefter.

Personligt vil jeg tro, at grund nr. 5) er den mest sandsynlige, tilsat en uskøn blanding af de øvrige.

Antagelig rammer du plet her. Samt du glemmer nok et væsentligt punkt 7. og en kendt vane ifm. offentlig administration/opgaver (banker har samme syge) - "vi har ingen fejl og har ingen fejltagelser".

Så nu efter så mange penge, bøvl og balladen med NemID og Java-applet, er det komplet umuligt at lave en brugbar JavaScript løsning til nogle få millioner - nogle vil tabe ansigt.

Så prisen blev talt op - først 8 mio., men så regnede de det til 15-30 mio. og endeligt havner vi på de 47 mio. Efter det første skøn er prisen nu steget 600%.

Så mon ikke hovedparten (80%) af pengene bruges til at indføje noget andet snask "nu vi alligevel er i gang" end JavaScript erstatningen for nuværende Java-applet. Det stemmer jo pænt med, at de skal rode forholdsvis længe med noget ukendt til hen i efteråret 2014.

Dvs. alle (Staten) endnu engang betaler hele regningen over skattebilletten.

Michael Nielsen

De kunne ikke sikre løsninge ved brug af java - den er ufattelig sårbar over for MITM angreb.

Med javascript, bliver det endnu nemmere at angribe brugerne, med lidt cross-site scripting, eller bare simple wrapning af scripts, da nu bliver kildekoden også synligt (altså svækker det eksisterende "security by obscurity concept")..

Det forkommer mig at det her bare åbner ladeporten mere (for transaktions sikkerheden)..

Men i det mindste slipper vi for at skulle havde java i browseren, som lukker en lade på på klient maskinerne..

Virker ikke som en fornuftig løsning til mig, da det nu forkommer mig endnu nemmere at hacke brugere..

Uh well, det er man jo ligeglade med.

Jari Wiklund

Ansvaret for at modvirke XSS, ligger hos dem der benytter sig af nemid's login, fx bankerne. Java appletten er så vidt jeg lige kan gennemskue, cirka lige så modtagelig for XSS, som en javascript løsning vil være det. Hvis nogen med held fik lagt slem kode på en banks hjemmeside, kunne man jo bare skifte <object name="DANID_DIGITAL_SIGNATUR" etc., ud med det man nu fandt nødvendigt, ved at pille ved DOM'en.
Langt de fleste ville ikke kunne se forskel, så længe XSS'eren har gjort sit arbejde godt nok.
MITM(og vel egentlig herunder CSRF) kan man nok heller ikke rigtigt beskytte sig imod, da problematikken her jo hovedsageligt handler om phishing.
Security by obscurity er og bliver ikke sikkert, det svarer til at lægge nøglen under dørmåtten.
Vi kan komme med nok så teknisk indviklede og dyre løsninger, men hvis fru Hansen ikke kan gennemskue phishing/åbner for betjenten uden at have set legitimation, hjælper det ikke ret meget.

Log ind eller Opret konto for at kommentere