Grønt lys for NemID på Javascript: Login fra mobilen klar om et år
Da NemID blev lanceret i sommeren 2010, var smartphones blevet et hit og Apples iPad var blevet lanceret nogle måneder tidligere. Men den nye officielle login-tjeneste for danskerne krævede Java og fungerede derfor kun i en desktop-browser.
Det vil Digitaliseringsstyrelsen nu lave om på, efter et årelangt tilløb med flere undersøgelser og senest et proof-of-concept. Her blev en løsning med NemID via Javascript testet, og konklusionen var, at det godt kunne lade sig gøre.
»Vi er blevet enige med DanID og bankerne om at sætte gang i et forprojekt og afdække de sidste udfordringer, og så der kan tages beslutning om et endeligt udviklingsprojekt. Vi har fået lovende resultater i forhold til at bygge NemID-klienten i Javascript, selvom det er en helt anden teknologi end Java,« siger Charlotte Jacoby, souschef i Digitaliseringsstyrelsens kontor med ansvar for digital signatur, til Version2.
Foreløbig er teknikken i at bruge Javascript blevet testet, men med forprojektet, der forventes at vare fire måneder, skal den nye NemID-løsning også vurderes i forhold til økonomi og sammenhængen med hele økosystemet omkring NemID.
Ved at bruge Javascript, der i modsætning til den eksisterende Java-løsning godt kan køre i mobiltelefonens eller tablettens browser, vinker man samtidig farvel til Java, som længe har været udråbt som en sikkerhedsrisiko, på grund af løbende sikkerhedshuller og en besværlig opdateringsproces.
»Javascript-løsningen er ikke målrettet mobile platforme, men vil køre på alle platforme, der kan køre Javascript, altså også en pc. Vores ønske er at kunne afløse Java-versionen helt, med samme funktionalitet, som vi har i dag,« siger Charlotte Jacoby.
Ifølge den nyhed, Digitaliseringsstyrelsen har forfattet om projektet, er det meningen, at den længe ventede Javascript-baserede NemID-løsning er klar i løbet af 2013 eller i begyndelsen af 2014. Charlotte Jacoby understreger dog, at der er en del usikkerhed om, hvornår projektet er i mål.
»Når forprojektet er gennemført, skal vi tage nogle beslutninger - er det sikkert nok, er det funktionelt nok, har vi penge til det? Hvis alt er godt, så går vi i gang, og så håber vi at have en færdig løsning i 2013 eller starten af 2014. Det er bestemt vores ønske, men tidsplanen er endnu meget usikker, fordi der kan komme udfordringer, vi endnu ikke kender,« siger Charlotte Jacoby.
Netop økonomien har tidligere været en stopklods for en mobil udgave af NemID. En undersøgelse af forskellige alternativer konkluderede tilbage i foråret 2012, at prisen ville blive væsentligt højere end de 8 millioner kroner, staten havde sat af til hele projektet.
Meldingen er nu, at der skal rejses flere penge til den nye udgave af NemID, hvis det skal lykkes. Men til gengæld kan projektet gennemføres uden et tidskrævende udbud, fordi udviklingsarbejdet er et tilkøb til en eksisterende aftale.
Kritik af Java-løsning fra begyndelsen
Allerede ved lanceringen af NemID i 2010 var der hård kritik af, at man kun kunne bruge NemID fra ’gammeldags’ computere, mens login via mobile platforme var umuligt. Forklaringen var, sagde IT- og Telestyrelsen, der dengang havde ansvaret for NemID, at systemet var blevet designet i 2007, hvor smartphones ikke var almindelige.
Daværende videnskabsminister Charlotte Sahl-Madsen meldte i begyndelsen af 2011, at man arbejdede på en løsning til mobile enheder, men projektet løb ind i problemer. I mellemtiden gik bankerne solo og gjorde det muligt at bruge netbank via mobilen, men OCES-delen af NemID - den til at logge ind på offentlige hjemmesider - brugte en anden teknologi end bankernes login, så det var ikke muligt umiddelbart at følge i deres fodspor.
Derfor blev der sat gang i nye undersøgelser af mulighederne, og sat otte millioner kroner af til formålet, og planen var at tage en endelig beslutning i begyndelsen af 2012, om hvilken løsning der var den bedste.
Men undersøgelserne viste, at det var mere kompliceret end som så, og at otte millioner kroner langt fra var nok. Derfor måtte Digitaliseringsstyrelsen udskyde projektet igen i løbet af foråret 2012.
Beslutningen bliver at gå videre med en Javascript-baseret løsning, som bliver udviklet og testet i efteråret 2012 som et proof-of-concept. Det er den løsning, som styrelsen nu vil teste i bredere forstand og - om alt går vel - udvikle til en endelig løsning.
- Digitaliseringsstyrelsen giver ’go’ til NemID på mobile enheder
- Nets klar med NemID på Javascript om et år - trods manglende 'go' fra det offentlige
- Norske banker dropper Java til login for at skåne brugerne for opdateringer
- Mozilla sender Java, Adobe Reader, Flash og Silverlight i skammekrogen
- Norsk BankID skeler til danske Javascript-planer - men satser på apps
- Denne artikel
- Alarm: 4 millioner NemID-brugere truet af kritisk Java-hul
- Ny plan for mobil NemID kommer til januar – og så skal det gå stærkt
- NemID med Java på vej ud? Styrelse tester løsning i Javascript
- Her er statens bedste bud på mobil NemID-løsning
- 8 millioner kroner til NemID på mobilen var ikke nok
- NemID til mobilen bliver udskudt: Sværere end forventet
- Ekspert: NemID uden mobiladgang er pinlig og tåbelig
- 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.
Fortsæt din læsning
- Sponseret indhold
V2 Briefing | 17. april | GENERATIV AI: Sådan bruger du det professionelt
Kunstig Intelligens22. marts
- Sortér efter chevron_right
- Trådet debat
Hvorfor lavede man ikke bare en løsning baseret på Javascript til at begynde med, i stedet for først at udvikle en version i Java for derefter blot at lave en ny version i Javascript. Det virker som dobbeltarbejde. Er der en fornuftig grund til at man ikke bare lavede det i Javascript til at begynde med?
Et par ting er blevet blandet lidt sammen, så jeg vil prøve at komme en forklaring.
NemID kan to ting. Login og signering. Login, også kaldet Single-Sign-On (SSO), er den ene del, og så signering af dokumenter med OCES-certifikater.
Login består i at man har et brugerid (CPR), et kodeord og så et sæt engangs-nøgler (papkort). For at kunne logge ind et sted, kræves ikke at man har adgang til den lokale disk, men blot at brugeren kan indtaste disse tre dele. Dette system bruges til at logge ind i banker, og også offentlige myndigheder såsom Skattevæsnet.
For at en bank eller anden kan logge folk ind, skal denne have adgang til engangsnøglerne. For tiden ligger disse hos NemID, men de kunne godt spredes ud, så man undgik single-point-of-failure.
Man-in-the-middel-attacks er et stort emne, for det kan gøres i mange forskellige led. Der er dog den ting at den implementering man har nu med Java, her bliver javakoden hentet fra et andet domæne end banken, og her kan man så snyde med DNS-opslag (/etc/hosts). Det kan nemt undgås med javascript ved at hente scripts direkte fra banken, og ikke et tredje led. Sådan virkede det med Jyske Bank tidligere.
Der er nogle banker der har skrevet en netbankløsning til din smartphone, og det løser ganske rigtigt dit problem. Men det kræver at du har tillid til at banken ikke implementere alt muligt andet malware i denne løsning. Så det er en dårlig løsning. Det er meget bedre med et API såsom javascript.
Jeg tog en kopi af Jyske Banks javascript-løsning inden de stoppede med den, og de ligger her Jyske Bank Javascript, hvis nogen skulle være interesseret i at se det. Jeg fik desværre ikke nogle screen-shots der viser login forløbet, så det er lidt rodet at se på filerne.
Signering (underskrivning) af dokumenter er lidt mere komplekst. Dette kræver at man har en privat nøgle, og at denne er blevet godkendt af andre. I NemID regi hedder det OCES, og der er ikke så mange mennesker der har det, for de har ikke rigtigt noget at bruge det til. For at kunne underskrive en et dokument (som er en fil), kræves at man sin "private nøgle" (det er også en fil), og så et program der kan blande disse to filer. Et meget brugt system er PGP (RFC 2440). I NemID regi ligger denne private nøgle hos DanID, og det er blevet meget kritiseret af dem der mener at private nøgler skal genereres og opbevares af borgeren, ikke af nogen andre. For at kunne signere et dokument, kræves et program der kan mere end Javascript teknisk kan - læse den private nøgle fra den lokale disk. Signering af dokumenter kunne nok indbygges i browsere og HTML, men der er ikke lige nogen standard for det nu. Så mit forslag lige nu er PGP (GnuPG), indtil der dukker noget bedre op.
Hvor om alting er, så er der en del problemer der er skabt ved at have tvungen brug af Java hos borgeren, og ikke bare et standard script-sprog som javascript (ECMA-script). Jyske Banks javascript virkede ikke med tekst-browseren "links", men ellers virkede næsten alle andre browsere, også smartphones.
Jeg tog en kopi af Jyske Banks javascript-løsning inden de stoppede med den, og de ligger her Jyske Bank Javascript, hvis nogen skulle være interesseret i at se det. Jeg fik desværre ikke nogle screen-shots der viser login forløbet, så det er lidt rodet at se på filerne.
Takker ærbødigst.
Jeg har lige skimmet filerne hurtigt. Det er imponerende pæn kode i forhold til den krævede browserkompatibilitet der var nødvendig på det tidspunkt.
Det bliver en god reference når vi ser hvad NemID finder på.
Well, nu gennemgik jeg så lige min access.log og der var et enkelt IP-nummer der sprang i øjnene: 91.102.27.1Det bliver en god reference når vi ser hvad NemID finder på.
$ host 91.102.27.1 1.27.102.91.in-addr.arpa domain name pointer dmz.nets.no.
Så hvis DanID finder på noget JavaScript der ligner, så ved vi hvor de har det fra ;-)
Det var dog nok bedre om DanID bare spurgte Jyske Bank om at få deres sidste kildekode, og så en præsentation af login-systemet. Efter 12 år skal JB's kildekode måske nok lige have et review, men mig bekendt er JB aldrig blevet hacket, så helt ringe her det ikke været.
...et MITM angreb som det vi så demonstreret her på Version2 ?
At man kan "udvikle" sådan en løsning, mon de slet ikke har opdaget der findes andre programmeringssprog, for eksempel c++, at det er muligt at lave en løsning der overhovedet ikke er afhængig at diverse forskellige librarys, altså en rent stand alone løsning, det er ikke engang svært.. Man skal så bruge forskellige versioner til forskellige systemer, men - hvad så, de tjener så mange penge at der er rigeligt råd til den slags.
At man kan "udvikle" sådan en løsning, mon de slet ikke har opdaget der findes andre programmeringssprog, for eksempel c++, at det er muligt at lave en løsning der overhovedet ikke er afhængig at diverse forskellige librarys, altså en rent stand alone løsning, det er ikke engang svært..
Man skal så bruge forskellige versioner til forskellige systemer, men - hvad så, de tjener så mange penge at der er rigeligt råd til den slags.
Og hvordan havde du tænkt dig at afvikle C++ kode i en browser?
Løsningen skal baseres på teknologier der er tilstede i ALLE BROWSERE på ALLE PLATFORME! Det eneste programmeringssprog der opfylder dette krav er JavaScript/ECMAScript. Og sikkerheden skal baseres på åbne standarder (SSL/TLS måske krydret med diverse digest algoritmer).
Så kan vi efterfølgende tage diskusionen om hvorvidt det er en god idé at privatnøgler opbevares centralt. Men det er en separat diskussion. Grunden til at den oprindelige OCES certifikatløsning blev skrottet til fordel for NemID var, at fru Jensen ikke kunne finde ud af at opbevare og sikre sin pivatnøgle.
Og hvordan havde du tænkt dig at afvikle C++ kode i en browser?
Native Client klarer det med Chrome på PC og Android. Du kan for eksempel køre Quake direkte i din browser ved at finde den i Chrome Store.
Men Apple er nok ikke helt tændte på åbne den ladeport for at omgå deres App Store.
at det er muligt at lave en løsning der overhovedet ikke er afhængig at diverse forskellige librarys
Hvornår har du sidst lavet et C++ program, der ikke er afhængig af forskellige libraries? (stdio, socket, osv osv).
Og hvordan vil du rulle det ud på en iPhone, hvor native apps skal kodes i Objective-C? Eller Android, der bruger Java?
/ Carsten
Forkert. Du kan sagtens skrive c++ kode til iOS og køre det uden problemer. Kompileren på iOS har ingen problemer med c++ og c kode flettet ind i Objective-C kode. Android har ndk, som gør det muligt at køre c++ kode inde i et program. Så det du siger er ikke helt rigtigt Carsten.
Min NoScript er lige kommet medd følgene temmelig ildevarslende besked efter at jeg fulgte et link ovre på ing.dk til den her artikel. Samme meddelelse fremkommer også når jeg går ind til artikel via version2.dk forsiden.
NoScript skriver:
NoScript har filtreret et potentielt forsøg på cross-site scripting (XSS) fra (<a href="http://www.version2.dk/">http://www.version2.dk/</a>).
Tekniske detaljer kan ses i konsollen.
Hvad har det med denne artikel at gøre?
noget helt andet, det er meget normalt med plugin's kommer med falske advarsler
Fx adblock er ikke helt glad for tinypic.com fordi de hoster billeder på forskellige subdomains
.. lad os lige få armene ned.
Det her gør ikke noget for at adskille stat og kirke ^^^ bank.
Det gør ikke op med det fundamentale problem at NemID er en stor MIM konstruktion.
Det gør ikke op med det problem (kva NemIDs MIM konstruktion) at der er et centralt overvågningspunkt der kan misbruges.
Det ændrer ikke på at hele opbygningen har et single point of failure.
Det gøre ikke op med at borgeren stadig ikke har kontrol over egne nøgler.
Det gør intet for at forebygge identitetstyveri.
Java er kun en lille del af problemet.
Det gøre ikke op med at borgeren stadig ikke har kontrol over egne nøgler.
Christian sådan helt af professionel interesse: Hvis nu Single-signon blev lavet udelukkende med HTML + Javascript (og så SSL osv). Hvordan skal brugeren så selv kunne gemme sin nøgle? Det kan i hvert fald ikke være på en fil på harddisken eller usb, for den vil javascript jo ikke kunne tilgå.
/ Carsten
Ønske til alle browsere: Standardiseret og sikker håndtering af nøglefiler, der virker ens (samme API) på alle platforme.Hvis nu Single-signon blev lavet udelukkende med HTML + Javascript (og så SSL osv). Hvordan skal brugeren så selv kunne gemme sin nøgle? Det kan i hvert fald ikke være på en fil på harddisken eller usb, for den vil javascript jo ikke kunne tilgå.
Egentlig mærkeligt at det ikke findes i bare en basal form - men der er måske nogle teknikaliteter der besværliggør det? Eller nogle modsatrettede interesser?
Men der må da kunne laves noget der er bedre end at NemID har alle de "private" nøgler? Måske er Danmark det eneste land i verden der har valgt denne usikre løsning?
Min tyske kollega bruger dette mystiske device (omkring 1:13 i videoen kan man se hvordan man skal holde den op til skærmen så den kan aflæse blinkende felter):http://www.youtube.com/watch?v=U7PnC1S-j4I
Det virker som en temmelig klodset løsning, men til gengæld har han ikke sin private nøgle liggende hos andre.
Det har jeg ikke umiddelbart nogen patentløsning på.Christian sådan helt af professionel interesse: Hvis nu Single-signon blev lavet udelukkende med HTML + Javascript (og så SSL osv). Hvordan skal brugeren så selv kunne gemme sin nøgle? Det kan i hvert fald ikke være på en fil på harddisken eller usb, for den vil javascript jo ikke kunne tilgå.
Generelt mener jeg at SSO er en misforståelse, det er også derfor jeg plæderer for en adskillelse af stat og bank.
Herudover så skal vi også skelne mellem SSO og så digitale signaturer, hvilket desværre er blevet fuldstændigt udvandet.
Og som jeg også siger, IMO er Java (uagtet jeg er helt enig i der er problemer med Oracle Java) ikke nødvendigvis det største problem i hele debatten omkring adgang til offentlige services og bank, der er mange andre problemer i hele konstruktionen der er meget større, og som udgør en voldsom trussel over for den personlige integritet, hvorfor fidlen omkring Java vs JavsScript kun er at fjerne fokus fra de virkeligt alvorlige problemer.
Man skal vel starte et sted?
Og hvis DanID er så inkompetente som de har givet udtryk for gennem hele forløbet, så er det nok bedst at vi fodrer dem med fornuft i små bitte bidder så de ikke bliver kvalt i det.
DanID skal behandles på samme måde som sild i gamle dage. Ned i en tønde, salt over og så først åbnes når man har brug for dem (og det har man ikke). Kvælning er ikke en bekymring jeg deler. Hvis det var min planet var de blevet strittet af for længst...
Ikke enig.Man skal vel starte et sted?</p>
<p>Og hvis DanID er så inkompetente som de har givet udtryk for gennem hele forløbet, så er det nok bedst at vi fodrer dem med fornuft i små bitte bidder så de ikke bliver kvalt i det.
Faktisk mener jeg at der er et behov for at trække en kraftig streg i sandet, og sige stop.
Små bidder betyder jo bare at der de næste 20 år bliver ved med blive skrevet checks ud til DanID, mens vi stadig hopper på stedet uden der sker en bønne.
Og samtidig mister landet mere og mere konkurrenceevne, fordi vi gøder et Kafkask system af spagettikode, og væver os ind længere og længere ind i edderkoppespindet.
De burde seriøst finde den bedste javascript programør i landet, give ham en million og et halvt år, og så nyde at det bliver gjort ordenligt fra starten.
Som altid med noget fra NemID skal deadline nok udskydes 2-3 år, inden vi ser noget til det.
Det var da os på tide, men jeg har da brugt nemID på min mobile netbank i 6 måneder?
Sydbank kræver i hvert fald en nøgle ved hver overførsel. Men det jo så også i et APP, men så vidt jeg ved uden om JAVA ?
Siden javascript er læseligt for alle og enhver, vil NemID lægge javascriptklientens kildekode offentligt tilgængeligt så communityet kan dobbeltjekke sikkerheden og komme med feedback?
Siden javascript er læseligt for alle og enhver, vil NemID lægge javascriptklientens kildekode offentligt tilgængeligt så communityet kan dobbeltjekke sikkerheden og komme med feedback?
Der er ingen essentiel forskel på obfuskeret ECMA-script og på compileret Java eller deres gif-filer. Der er ikke nogen grund til at koden på den nye implementation vil være mere eller mindre læselig end på den gamle Java-løsning.
Bedre sent end aldrig, men måske burde man skæve til andre muligheder end DanID. De har vel ligesom vist hvad de dur og ikke dur til. Med snævertsynethed kommer man næppe langt - og dog for der ser jo ud til at DanId har raget nogle flere millioner til sig, og det er vel det, det går ud på, når man driver forretning.
Jeg undrer mig voldsomt over at 8 millioner ikke skulle være nok til både at undersøge og implementere en javascriptløsning. Det er velafprøvede teknologier.
Der må være noget vi ikke ved.
Kan Version2 spørge ind til hvad de overordnede krav for klienten er, siden det kræver en længere undersøgelse om hvorvidt javascript overhovedet kan dække kravene?
Kan Version2 spørge ind til hvorfor javascript overhovedet er påkrævet når den eneste brugerinteraktion er indtastning i tekstfelter, en funktionalitet som har været velafprøvet siden 90'erne?
Mon ikke der skal skelnes mellem login og signering (af dokumenter). Login delen burde kunne laves med ret simpel html forms + JavaScript for langt mindre end 8 millioner og langt hurtigere end slutningen af 2013.
Dokument signering (som nok ikke bruges at ret mange danskere endnu) er nok en noget mere kompliceret sag. Så lav login delen først.
Redigering: Same origin er nok også en udfordring men det klares jo allerede i OAuth/OpenID...
Kravet om "Fuld adgang til brugerens computer" bliver svært med Javascript!
Jeg undrer mig voldsomt over at 8 millioner ikke skulle være nok til både at undersøge og implementere en javascriptløsning. Det er velafprøvede teknologier.
Det er nemt at svare på: Staten har noget IT, som Staten gerne vil have lavet. Startpris er minimum 4 millioner kr. Ellers er det ikke statsligt nok... ;-)
/ Carsten
Netop økonomien har tidligere været en stopklods for en mobil udgave af NemID. En undersøgelse af forskellige alternativer konkluderede tilbage i foråret 2012, at prisen ville blive væsentligt højere end de 8 millioner kroner, staten havde sat af til hele projektet.
8 millioner kr er 2kr per bruger. Hvis jeg kunne betale 2kr for at min mor ikke behøvede at installere og vedligeholde en Java-installation, så var det den bedste deal ever. Jeg ville endda gerne betale 4kr.
Det burde være tydeligt for enhver at de fordele danskerne samlet får med en ECMA-script udgave af NemID LANGT overstiger udgiften til at implementere den.
8 millioner kr er 2kr per bruger. Hvis jeg kunne betale 2kr for at min mor ikke behøvede at installere og vedligeholde en Java-installation, så var det den bedste deal ever. Jeg ville endda gerne betale 4kr.</p>
<p>Det burde være tydeligt for enhver at de fordele danskerne samlet får med en ECMA-script udgave af NemID LANGT overstiger udgiften til at implementere den.
Helt enig.
Og jeg er sikker på at DanID kan spare MANGE PENGE på support.
Det kunn være spændende at se en opgørelse fra DanID over hvor stor en andel af NemID support omkostningerne der relaterer til problemer med at installere, opgradere og eksekvere Java applet'en.
Woop woop! Så blev jeg jo helt glad i dag. :-)
"har vi penge til det?"
Har vi penge til at lade være?
/ Carsten
Jeg kunne godt tænke mig at se hvordan det skal implementeres.
Er der nogen der ved hvordan man ville lave en sådan type løsning?
Hej! jeg kan ikke forklare dig hvordan det fungere men jeg er bor i Sverige og jeg kan logge ind på alle myndigheder med mit bank Id som er detsamme som jeres NemId og det er både på min Iphone og Ipad.
Nok fordi jeres løsning er nyere, den er jo netop lavet med inspiration fra nemid, som er fra 2003 ..
Er der nogen der ved hvordan man ville lave en sådan type løsning?
Som omtalt i artiklen har Nets DanID lavet et proof of concept.
Version2 har søgt aktindsigt i dokumentet, men har fået afslag med henvisning til den såkaldte generalklausul i offentlighedsloven (§ 13, stk. 1, nr. 6), der refererer til "private og offentlige interesser, hvor hemmeligholdelse efter forholdets særlige karakter er påkrævet."
Vh Morten, Version2.
hemmeligholdelse efter forholdets særlige karakter er påkrævet.
Undskyld - jeg skal lige samle mig selv op fra gulvet (faldt ned af stolen af grin).
DanID: Hej Digitaliseringsstyrelse, vi har et stort problem
DS: Hvad er det?
DanID: Nu skal vores POC jo laves i Javascript, som alle kan læse. Så vi er lidt bange for, at dygtige IT-folk ser, hvad det er for noget skrammel-kode vi har lavet.
DS: Ikke noget problem. Vi knalder en "§ 13, stk. 1, nr. 6" ned over det hele.
DanID: TAK!
Jyske Bank's net-løsning virkede med javascript før der kom NemID. Både med papkort og de beskeder man ser, var JBs løsning næsten den samme, så jeg tror næsten den kan "plankes" og rettes lidt til, og så virker den.Jeg kunne godt tænke mig at se hvordan det skal implementeres.
Det kunne være interessant at høre Jyske Banks kommentar til dette.
Er der nogen der ved hvordan man ville lave en sådan type løsning?
Hvad mener du? Det er vel standard ligefrem web-programmering, og ikke rocket science? Kig eventuelt på hvordan OpenID er implementeret.
Eller mener du om de samtidigt ville lave en central login-side ala OpenID, så NemID ikke længere var sårbar over for MitM?
Er der nogen der ved hvordan man ville lave en sådan type løsning?
Well for det første ville jeg nok slet ikke bruge javascript - andet end til at lave hurtig bruger-feedback om, hvorvidt det indtastede er gyldigt (client-side validation).
Jeg ville blot lave "simple" HTML formularer og transportere alle data via SSL. Eftersom nøglen på pap-kortet er en engangsnøgle, så hjælper det ikke at sniffe data. Kun "man-in-the-middle" angreb er muligt - og det gør hverken fra eller til om det er den gamle java-løsning eller den nye her.
/ Carsten
Jyske Bank lage flere lag oven på I deres løsning. Bl.a DES-kryptering (oven på SSL), samt hashing at pap-kort-koden. Banken ved godt hvad papkoden er til en given entry, og hvis de hash'er med samme metode, så er der lidt mere sikkerhed dér.Jeg ville blot lave "simple" HTML formularer og transportere alle data via SSL. Eftersom nøglen på pap-kortet er en engangsnøgle
Bl.a DES-kryptering (oven på SSL), samt hashing at pap-kort-koden.
Ja jeg var også lidt for hurtig til at svare - se mit svar nr. 2 :-)
/ Carsten
et første ville jeg nok slet ikke bruge javascript
Og det ville jeg så nok alligevel lidt. Eftersom man kan bruge sit CPR-nummer som brugerid, er der nok en vis idé i at SHA-1'e alle tre felter (brugerid, password, papkort-ngøle) med et salt, som leveres fra NemID serveren fra gang til gang.
/ Carsten
Og det ville jeg så nok alligevel lidt. Eftersom man kan bruge sit CPR-nummer som brugerid, er der nok en vis idé i at SHA-1'e alle tre felter (brugerid, password, papkort-ngøle) med et salt, som leveres fra NemID serveren fra gang til gang.
Pas på! Det mønster er ikke altid sikkert. Lad ++ være (infix) concat. Og lad os antage at en angriber ved hvordan klienten laver sin SHA1 sum. Hvis du laver
Salt ++ User ++ Pw ++ KeyId
så har du lige fejlet krypto 101. Problemet er at en MitM angriber kender Salt og derved har han known plaintext. Angriberen er også nødt til at kende User for du skal identificere dig overfor serveren. Tilbage skal han bare gætte Pw og KeyId. KeyId er kun 9999 mulige og fordi du kører en naiv SHA1 kan angriberen checke millioner af forsøg hvert sekund. Og hvis du laver dedikeret hardware i GPU'er, så er tallet helt anderledes. Vi snakker 2.8 milliarder checks per sekund for en standard PC. Dit Pw holder ikke længe.
SHA1 har derudover kendte teoretiske problemer der gør at du muligvis kan finde en kollision temmeligt hurtigt.
Der er en grund til at NemID bruger SRP. Der er en grund til at man har HMAC schemes. Og der er en grund til at man har key derivation functions. Ingen af dem er naive, og det er der en grund til.
Eftersom man kan bruge sit CPR-nummer som brugerid
Det kunne være en del af fremtidige krav, at dette ikke længere er en mulighed.
Ja tak. Og tak. Alt kommer til den der kan vente...