mboost-dp1
Den tekniske korrekte NemID implementation
... lidt til ære for Hubert.
I forbindelse med lidt crypto snak på IRC, kom vi ind på hvad der måske kan anses som en ideel løsning til authentication og signering.
1. Brugeren indtaster brugernavn og password i sin browser.
2. Browseren bruger passwordet til at signere et UID med brugerens private nøgle.
3. Det signerede UID sendes til serveren, sammen med brugernavnet
4. Serveren matcher brugernavnet og forsøger derefter at decryptere det signede UID med brugerens offentlige nøgle.
5. Serveren enten redirekter brugeren ved godkendt login, og sætter en alm. login cookie, eller melder login-fejl tilbage til brugere.
6. Ved operationer, som f.eks. kontooverførsel i en netbank bedes brugeren om at signere data'en igen.
Alting foregår på alm. HTTPS, og nøglerne er typisk PKCS#12 nøgler.
Problemet med overstående løsning er så pt. at der mangler en standardiseret mulighed for at tilnå brugerens private nøgle, som enten
a) Er gemt i operativ-systemets certifikat/nøgle-register (IE og Chrome på Windows)
b) Er gemt i browserens certifikat/nøgle-register (Firefox, Safari, Opera på Windows, alle browsere på ikke-Windows systemer.)
Løsningen ville være et HTML5 JavaScript API til formålet, sammen med et standardiseret nøgleformat (PKCS#12 er dejligt, virker både med OpenSSL, og er standard på Windows).
---
Spørgsmålet er så om jeg har overset noget her. Og hvilke måder vi kan omgå implementationen på i dag (Jeg har kig på en Silverlight 4 implementering til IE/Chrome på Windows).
En mere konstruktiv tilgang til NemID, end de normale debatter.
I forbindelse med lidt crypto snak på IRC, kom vi ind på hvad der måske kan anses som en ideel løsning til authentication og signering.
1. Brugeren indtaster brugernavn og password i sin browser.
2. Browseren bruger passwordet til at signere et UID med brugerens private nøgle.
3. Det signerede UID sendes til serveren, sammen med brugernavnet
4. Serveren matcher brugernavnet og forsøger derefter at decryptere det signede UID med brugerens offentlige nøgle.
5. Serveren enten redirekter brugeren ved godkendt login, og sætter en alm. login cookie, eller melder login-fejl tilbage til brugere.
6. Ved operationer, som f.eks. kontooverførsel i en netbank bedes brugeren om at signere data'en igen.
Alting foregår på alm. HTTPS, og nøglerne er typisk PKCS#12 nøgler.
Problemet med overstående løsning er så pt. at der mangler en standardiseret mulighed for at tilnå brugerens private nøgle, som enten
a) Er gemt i operativ-systemets certifikat/nøgle-register (IE og Chrome på Windows)
b) Er gemt i browserens certifikat/nøgle-register (Firefox, Safari, Opera på Windows, alle browsere på ikke-Windows systemer.)
Løsningen ville være et HTML5 JavaScript API til formålet, sammen med et standardiseret nøgleformat (PKCS#12 er dejligt, virker både med OpenSSL, og er standard på Windows).
---
Spørgsmålet er så om jeg har overset noget her. Og hvilke måder vi kan omgå implementationen på i dag (Jeg har kig på en Silverlight 4 implementering til IE/Chrome på Windows).
En mere konstruktiv tilgang til NemID, end de normale debatter.
#3
Det ændrer vel ikke noget ved tingene.
Brugeren indtaster det samme hver gang og browseren submitter det samme til serveren hver gang.
Hvis de er ens er det et helt normalt password.
Hvis de er forskellige så er det en password husker beskyttet af et password.
Men jeg kan ikke se nogen som helst sikkerheds fordele i forhold til et helt normalt password.
Det ændrer vel ikke noget ved tingene.
Brugeren indtaster det samme hver gang og browseren submitter det samme til serveren hver gang.
Hvis de er ens er det et helt normalt password.
Hvis de er forskellige så er det en password husker beskyttet af et password.
Men jeg kan ikke se nogen som helst sikkerheds fordele i forhold til et helt normalt password.
Ideen er jo ligeledes at man kun sender krypteret data til valideringer. Altså ens password til den private nøgle, og den private nøgle, bliver aldrig sende over HTTP(S), men forbliver 100% lokalt.
Det gør det en del sværer at stjæle brugerens password.
Så jeg forstår ikke hvordan du kan mene det ikke er mere sikkert.
Det gør det en del sværer at stjæle brugerens password.
Så jeg forstår ikke hvordan du kan mene det ikke er mere sikkert.
#9
Ja, det var min ide. Der skal jo sendes et eller andet til serveren som er crypteret med den private nøgle. Et UUID synes at være det mest pratiske.
Det kan dog godt være det skal være genereret på serveren, for at gøre man-in-the-middle attacks sværere, da et evt. opsnap af data så kun ville virke én gang.
Ja, det var min ide. Der skal jo sendes et eller andet til serveren som er crypteret med den private nøgle. Et UUID synes at være det mest pratiske.
Det kan dog godt være det skal være genereret på serveren, for at gøre man-in-the-middle attacks sværere, da et evt. opsnap af data så kun ville virke én gang.
#11
Jo da. Den vil ikke dekryptere værdien forkert, men istedet returnere fejl. Hvis nøglerne ikke matcher, så kan dekrypteringen nemlig ikke gennemføres.
Men den kan ikke teste om det er en gammel værdi. Ved at sikre at det er en ny værdi der sendes for hvert request, begrænses muligheden MITMA.
Jo da. Den vil ikke dekryptere værdien forkert, men istedet returnere fejl. Hvis nøglerne ikke matcher, så kan dekrypteringen nemlig ikke gennemføres.
Men den kan ikke teste om det er en gammel værdi. Ved at sikre at det er en ny værdi der sendes for hvert request, begrænses muligheden MITMA.
http://en.wikipedia.org/wiki/Replay_attack er hvad jeg tænkte på.
UUID'et var så tiltænkt som et session token. (Så lærte man da lidt mere jargon)
UUID'et var så tiltænkt som et session token. (Så lærte man da lidt mere jargon)
Windcape (1) skrev:Problemet med overstående løsning er så pt. at der mangler en standardiseret mulighed for at tilnå brugerens private nøgle, som enten
Jeg kan ikke forstå hvad der er galt med SSL?
Windcape (12) skrev:Jo da. Den vil ikke dekryptere værdien forkert, men istedet returnere fejl. Hvis nøglerne ikke matcher, så kan dekrypteringen nemlig ikke gennemføres.
Det er ikke en generel egenskab ved alle former for private-public key men en egenskab ved visse algoritmer.
RSA med PKCS#1 gør dog.
#UUID
Det bør nok også være random data genereret med en kryptografisk stærk random number generator fremfor traditionel UUID/GUID.
UUID/GUID er ikke tiltænkt at være kryptografisk stærkt random.
I kan nemt finde private-public key algoritmer som ikke kendte sårbarheder for known plain text attack, men skal man lave det kan man lige så godt lave det ordentligt.
Det bør nok også være random data genereret med en kryptografisk stærk random number generator fremfor traditionel UUID/GUID.
UUID/GUID er ikke tiltænkt at være kryptografisk stærkt random.
I kan nemt finde private-public key algoritmer som ikke kendte sårbarheder for known plain text attack, men skal man lave det kan man lige så godt lave det ordentligt.
Windcape (1) skrev:I forbindelse med lidt crypto snak på IRC, kom vi ind på hvad der måske kan anses som en ideel løsning til authentication og signering.
Altså nogle få nørder sætter sig lige ned og tror de kan finde på en sikkerhedsmodel som er meget bedre end hvad eksperter har brugt år på at udvikle? Eller?
Og hvad har det med NemID at gøre? Så vidt jeg kan se er løsningen afhængig af teknologi som ikke eksisterer, ikke er færdig eller ikke er udbredt nok. Muligvis en fin teoretisk debat, men hvad er debat-emnet egentlig?
Lad os bare springe over at beskrivelsen er mangelfuld og meningsløs, det er i jo allerede ved at udrede. Det kan godt være at når kommunikaionen er på plads, dukker der en teoretisk brugbar løsning op.
Er det ikke nogenlunde den måde det fungerede med den gamle Digital Signatur løsning fra TDC?
I modsætning til det nuværende NemID, vil sikkerheden kunne brydes ved at installere en trojansk hest på den computer der bliver brugt til at logge ind.
Hvorfor ikke bare bruge den nuværende NemID løsning hvor der evt. er ændret følgende:
1) Java appleten er skiftet ud med almindelig https post.
2) Man kan få lov til at få sin egen private nøgle til brug med f.eks. PGP.
3) Man kan få lov til at skifte papirkortet ud med en elektronisk dims der har flere end 200 nøgler.
I modsætning til det nuværende NemID, vil sikkerheden kunne brydes ved at installere en trojansk hest på den computer der bliver brugt til at logge ind.
Hvorfor ikke bare bruge den nuværende NemID løsning hvor der evt. er ændret følgende:
1) Java appleten er skiftet ud med almindelig https post.
2) Man kan få lov til at få sin egen private nøgle til brug med f.eks. PGP.
3) Man kan få lov til at skifte papirkortet ud med en elektronisk dims der har flere end 200 nøgler.
Nej, vi snakkede om hvilke krav der ville være nødvendige for at kunne implementere løsningsmodellen i browserne, ved HTML5.myplacedk (17) skrev:Altså nogle få nørder sætter sig lige ned og tror de kan finde på en sikkerhedsmodel som er meget bedre end hvad eksperter har brugt år på at udvikle? Eller?
Debat-emnet er udpenslet i #1myplacedk (17) skrev:Og hvad har det med NemID at gøre? Så vidt jeg kan se er løsningen afhængig af teknologi som ikke eksisterer, ikke er færdig eller ikke er udbredt nok. Muligvis en fin teoretisk debat, men hvad er debat-emnet egentlig?
Netop det at løsningen er teoretisk er problematikken.myplacedk (17) skrev:Lad os bare springe over at beskrivelsen er mangelfuld og meningsløs, det er i jo allerede ved at udrede. Det kan godt være at når kommunikaionen er på plads, dukker der en teoretisk brugbar løsning op.
Min pointe var at se om der var nogle mangler, jeg ikke havde taget højde for, og som f.eks. arne_v har påpeget i forhold til at undgå replay-attacks.
Hele pointen er hvordan NemID burde have været designet, og hvor nemt det ville have været, hvis browserne havde et JavaScript API til at tilgå deres keystore.
Jo. Netop ActiveX i Internet Explorer havde adgang til keystore (eller certifikat-storen som det hedder på windows).Emil Melgaard (18) skrev:Er det ikke nogenlunde den måde det fungerede med den gamle Digital Signatur løsning fra TDC?
Problemet var at ingen andre browsere havde, eller har, et tilsvarende API.
En korrekt implementering spørger om passwords når den private nøgle bliver brugt, dvs. man skal bruge både en trojansk hest, og en keylogger.Emil Melgaard (18) skrev:I modsætning til det nuværende NemID, vil sikkerheden kunne brydes ved at installere en trojansk hest på den computer der bliver brugt til at logge ind.
Men under alle omstændigheder er løsningen mere sikker en et alm. papkort.
En to-faktor løsning som vi ser med NemID er rigtig god, men Hubert et. al. har tit klaget over at de ikke har deres private nøgle selv.
Jeg ville nærmere sige, at den ideele løsning er:Emil Melgaard (18) skrev:Hvorfor ikke bare bruge den nuværende NemID løsning hvor der evt. er ændret følgende:
1) Java appleten er skiftet ud med almindelig https post.
2) Man kan få lov til at få sin egen private nøgle til brug med f.eks. PGP.
3) Man kan få lov til at skifte papirkortet ud med en elektronisk dims der har flere end 200 nøgler.
1) public/private key authentication med HTML5
2) stadigvæk to-faktor authentication med NemID, efter key-identification.
3) Valgfrit, for dem som vil betale selv.
På den både har folk deres private nøgle selv, og DanID er nu kun public-keys, og NemID matches.
Den politiske problematik er selvfølgelig at alle så skal lave en private key, og uploade deres public key til DanID. Men den problematik har Hubert et. al. jo altid nægtet at tage til eftertankning, så den vil jeg undlade fra teknisk diskussion.
Windcape (21) skrev:En korrekt implementering spørger om passwords når den private nøgle bliver brugt, dvs. man skal bruge både en trojansk hest, og en keylogger.
Hvordan skulle det øge sikkerheden? Hvis først computeren er compromised så har du INGEN sikkerhed i den foreslåede "løsning"
Windcape (21) skrev:Men under alle omstændigheder er løsningen mere sikker en et alm. papkort.
How figures? Du foreslår en simpel løsning kun baseret på computeren og et password. Papkortet fungerer som et ekstra lag af sikkerhed i kræft af "something you have".
Windcape (21) skrev:En to-faktor løsning som vi ser med NemID er rigtig god, men Hubert et. al. har tit klaget over at de ikke har deres private nøgle selv.
Hubert et al. må indse at man ikke kan regne med at danskerne kan passe fornuftigt på deres private nøgler. Dette gælder så vidt jeg kan se også jer, da i jo netop foreslår at gemme den på en computer der kan brydes.
Err, det var vist ikke helt hvad jeg mente. Har ikke fået nok kaffe endnu.T-Hawk (22) skrev:How figures? Du foreslår en simpel løsning kun baseret på computeren og et password. Papkortet fungerer som et ekstra lag af sikkerhed i kræft af "something you have".
Jeg mente at det var mere sikkert end et alm. password, ikke papkort.
Jeg er enig, men uden at have den tekniske debat først, kan man ikke overbevise folk om den politiske debat bagefter.T-Hawk (22) skrev:Hubert et al. må indse at man ikke kan regne med at danskerne kan passe fornuftigt på deres private nøgler. Dette gælder så vidt jeg kan se også jer, da i jo netop foreslår at gemme den på en computer der kan brydes.
NemID er i høj grad politisk. Og hvis det ikke lige var for de unødvendige java applets, så ville jeg være 100% tilfreds med løsningen.
Men derfor kan nørder vel godt diskuttere teknik,.
Windcape (23) skrev:Jeg mente at det var mere sikkert end et alm. password
Det er jeg ikke sikker på at jeg er enig med dig i.
Et NemID password kan som udgangspunkt ikke findes ved brute force, da det skal valideres af en server.
Derimod kan passwordet i din løsning findes ved brute force hvis den krypterede nøgle stjæles, og det kan man risikere at den gør hvis man har den på en USB-stick som man kommer i en kompromiteret computer. Selv hvis man ikke engang logger på med computeren.
Hvis man logger på med en kompromiteret computer, er begge løsninger lige usikre.
#24
Nej nej, jeg mente at public/private key implementationen er mere sikkert end et password. Altså, uafhænging af en to-faktor authentication.
Jeg synes helt klart at en to-faktor authentication er det helt rigtige til en offentlig løsning.
I fremtiden kunne vi jo forestille os as vores personkort (i dag, sygesikringsbevis) ville komme med sådan en to-faktor authentication -- NemID fra fødslen.
Men i en ægte to-faktor authentication, der er systemet vel principelt ikke bygget op på RSA nøgle princippet, er det?
Og så bliver hele diskussionen om private og offentlige nøgler overflødige.
Nej nej, jeg mente at public/private key implementationen er mere sikkert end et password. Altså, uafhænging af en to-faktor authentication.
Jeg synes helt klart at en to-faktor authentication er det helt rigtige til en offentlig løsning.
I fremtiden kunne vi jo forestille os as vores personkort (i dag, sygesikringsbevis) ville komme med sådan en to-faktor authentication -- NemID fra fødslen.
Men i en ægte to-faktor authentication, der er systemet vel principelt ikke bygget op på RSA nøgle princippet, er det?
Og så bliver hele diskussionen om private og offentlige nøgler overflødige.
Windcape (25) skrev:Nej nej, jeg mente at public/private key implementationen er mere sikkert end et password. Altså, uafhænging af en to-faktor authentication.
Ja, hvis begge parter kender hinandens nøgler på forhånd (eller på en sikker måde kan verificere dem). Ellers kommer ham manden i midten og napper alle oplysningerne :-(
Windcape (20) skrev:Nej, vi snakkede om hvilke krav der ville være nødvendige for at kunne implementere løsningsmodellen i browserne, ved HTML5.
Det lyder som en interessant diskution.
Windcape (20) skrev:Hele pointen er hvordan NemID burde have været designet
Det lyder som en HELT anden diskution. HTML er jo ikke klar til brug hos tilstrækkeligt mange danskere lige foreløbig.
Windcape (23) skrev:Jeg mente at det var mere sikkert end et alm. password, ikke papkort.
Så du er interesseret i en løsning som er mere sikker, end noget som aldrig har været sikkert nok til netbanker? (Det er i hvert fald længe siden, hvis kodeord alene nogensinde har været nok til homebanking.)
Det lyder hverken som noget der har med NemID at gøre, eller synderligt interessant (for mig).
Windcape (20) skrev:NemID er i høj grad politisk.[...]Men derfor kan nørder vel godt diskuttere teknik,.
Så det har altså intet med NemID at gøre? Ren fokus på teknik nytter jo intet. Der er jo også mennesker der skal bruge det, og politik der skal financiere det.
Jeg spørger bare fordi jeg ikke gider en debat hvor vi ikke er enige om formålet. Så bliver det bare den sædvanlige med at én har et godt argument til én pointe, mens en anden afviser det fordi det er ligegyldigt i en anden sammenhæng.
Snakker vi om hvordan NemID kunne have været bedre, eller er det en teoretisk debat om hvordan man engang kunne gøre noget lignende (fx. afløseren til NemID), hvis ellers den teknik man skal bruge bliver lavet og udbredt i mellemtiden?
Det kan godt være jeg er træls lige nu. Jeg kunne selvfølgelig også bare påpege diverse fejl ligesom de andre deltagere gør, uden noget egentlig formål med det.
Helt rigtigt. Og så vidt jeg ved, er der heller intet keystore API på vej til HTML5 endnu, og derfor kunne det være interassant at tænke i de baner.myplacedk (27) skrev:HTML er jo ikke klar til brug hos tilstrækkeligt mange danskere lige foreløbig.
Det var ihvertfald min intention.myplacedk (27) skrev:Snakker vi om hvordan NemID kunne have været bedre, eller er det en teoretisk debat om hvordan man engang kunne gøre noget lignende (fx. afløseren til NemID), hvis ellers den teknik man skal bruge bliver lavet og udbredt i mellemtiden?
Vi har jo haft en masse diskussioner om NemID, men jeg synes aldrig forsøget på at definere en teknisk løsning, der (teoretisk) kunne være brugbar i fremtiden, hvis visse teknologier blev aktuelle.
Dog har Emil kommet med nogle gode pointer, der helt sikkert bevidner at papkortet, eller en digital udgave (betal selv?) helt sikkert vil være på plads i fremtiden.
Lyder lidt som den gamle Digital Signatur, bare uden Java.
Grunden til at vi ikke selv har vores private keys, er at der ikke stoles på at den gennemsnitlige dansker kan passe på den. Uden den tillid forsvinder tilliden til systemet. Problemet er jo at det er fx. banken der hænger på regningen når netbank misbruges.
Nu kender jeg ikke til den tekniske implementation, men jeg kunne forestille mig at appletten bruges til at signere ændringer. Det ville ikke kunne gøres med html.
Ikke nødvendigvis. Det er ret nemt at besværliggøre bruteforce af et password login. Det er sværere at sikre private keys der er spredt ud over brugernes maskiner. Selvom en key er krypteret kan den kopieres af malware og bruteforces på en anden maskine.
Men passwords kan ikke erstatte en private key, man kan
jo ikke signe med et password.
Windcape (21) skrev:En to-faktor løsning som vi ser med NemID er rigtig god, men Hubert et. al. har tit klaget over at de ikke har deres private nøgle selv.
Grunden til at vi ikke selv har vores private keys, er at der ikke stoles på at den gennemsnitlige dansker kan passe på den. Uden den tillid forsvinder tilliden til systemet. Problemet er jo at det er fx. banken der hænger på regningen når netbank misbruges.
Windcape (23) skrev:NemID er i høj grad politisk. Og hvis det ikke lige var for de unødvendige java applets, så ville jeg være 100% tilfreds med løsningen.
Nu kender jeg ikke til den tekniske implementation, men jeg kunne forestille mig at appletten bruges til at signere ændringer. Det ville ikke kunne gøres med html.
Windcape (25) skrev:Nej nej, jeg mente at public/private key implementationen er mere sikkert end et password.
Ikke nødvendigvis. Det er ret nemt at besværliggøre bruteforce af et password login. Det er sværere at sikre private keys der er spredt ud over brugernes maskiner. Selvom en key er krypteret kan den kopieres af malware og bruteforces på en anden maskine.
Men passwords kan ikke erstatte en private key, man kan
jo ikke signe med et password.
Den gamle var ActiveX (og uden to-faktor authentication).Killa (29) skrev:Lyder lidt som den gamle Digital Signatur, bare uden Java.
Modsat så kan nøglefilerne på Windows ikke kopieres, ligesom de kan på Linux.
Det kan sagtens lade sig gøre med JavaScript, HTML5 dækker sådan lidt over JavaScript APIs.Killa (29) skrev:Nu kender jeg ikke til den tekniske implementation, men jeg kunne forestille mig at appletten bruges til at signere ændringer. Det ville ikke kunne gøres med html.
Et standardiseret JavaScript API der har adgang til browserens keystore, ville kunne signere uden at den private nøgle skal ligge andre steder end på din computer.
Men NemID bruges hovedsageligt til login, og ikke til signering.Killa (29) skrev:Men passwords kan ikke erstatte en private key, man kan jo ikke signe med et password.
Nøglefiler & mobiler.
Faktisk så introducere hele perspektivet med login på mobiler endnu et problem -- mobiler har vidt forskellige operativ-systemer, browsere, og håndtering af filsystemer.
Det gør nok hele ideen med nøglefiler endnu mere urealistisk, hvor den nuværende implementation af NemID faktisk er langt mere praktisk.
Vi skal bare have DanID til at fatte at Java Appletten overhovedet ikke er nødvendigt. (Fordi det er den altså ikke!)
Faktisk så introducere hele perspektivet med login på mobiler endnu et problem -- mobiler har vidt forskellige operativ-systemer, browsere, og håndtering af filsystemer.
Det gør nok hele ideen med nøglefiler endnu mere urealistisk, hvor den nuværende implementation af NemID faktisk er langt mere praktisk.
Vi skal bare have DanID til at fatte at Java Appletten overhovedet ikke er nødvendigt. (Fordi det er den altså ikke!)
Windcape (31) skrev:Vi skal bare have DanID til at fatte at Java Appletten overhovedet ikke er nødvendigt. (Fordi det er den altså ikke!)
Helt enig!
Windcape (30) skrev:Den gamle var ActiveX (og uden to-faktor authentication).
Den gamle brugte en password beskyttet private key. Hvordan er det forskelligt fra det du forslår i #1? Digital signatur bruger også Java.
Windcape (30) skrev:HTML5 dækker sådan lidt over JavaScript APIs.
HTML5 er stadig draft.
Windcape (30) skrev:Et standardiseret JavaScript API der har adgang til browserens keystore, ville kunne signere uden at den private nøgle skal ligge andre steder end på din computer.
Du vil lægge alt sikkerheden på maskiner du ikke kan stole på? Det var jo lige præcist det der var problemet med den gamle løsning.
Windcape (30) skrev:Men NemID bruges hovedsageligt til login, og ikke til signering.
Jeg går ud fra at bankoverførsler, adresseændringer osv. skal signeres. Ellers virker det ret meningsløst med den private key der ligger hos DanID.
Windcape (31) skrev:Vi skal bare have DanID til at fatte at Java Appletten overhovedet ikke er nødvendigt. (Fordi det er den altså ikke!)
Det kommer jo lidt an på funktionen. Selve login delen behøver selvfølgelig ikke at være Java, men jeg går ud fra at appletten også tager sig af signering af ændringer du laver efter du er logget på.
Windcape (31) skrev:
Vi skal bare have DanID til at fatte at Java Appletten overhovedet ikke er nødvendigt. (Fordi det er den altså ikke!)
Der er en del forskellige krav til appletten, der ikke lader sig gøre med en ren HTML/Javascript-løsning. Blandt andet:
1) Browser-kompatibilitet: den skal virke i alle de mest anvendte browsere. Så det går altså f.eks. ikke, at anvende HTML5.
2) Der ønskes en mere sikker udveksling af password end f.eks. form-submit over HTTPS. NemID bruger SRP-protokollen. Der findes ganske vist en Javascript-implementation af SRP, men jeg er personligt utryk ved deres tilfældighedsgenerator (det er ikke meget entropi, man har adgang til gennem Javascript).
3) Løsningen skal være modstandsdygtig overfor man-in-the-browser angreb. I teorien er det naturligvist umuligt, men man kan gøre det mere besværligt for angriberne. Det må i det mindste være et krav, at løsningen ikke kan angribes med off-the-shelf værktøjer som Zeus og Spy-Eye.
Jeg vil personligt være meget interesseret i et design, der kan opfylde ovenstående lige så godt som en Java-applet.
Rasmus Faber (34) skrev:Der ønskes en mere sikker udveksling af password end f.eks. form-submit over HTTPS.
Hvis det er godt nok til dankortoplysninger burde det altså også være godt nok til NemID.
Emil Melgaard (35) skrev:Hvis det er godt nok til dankortoplysninger burde det altså også være godt nok til NemID.
Kortnummer, udløbsdato og PKK er væsentligt sværere at misbruge end dit NemID-login.
At ActiveX kun virkede i IE?-) (Det tog DanID næsten et halvt år at fixe Windows 7 support...)Killa (33) skrev:Den gamle brugte en password beskyttet private key. Hvordan er det forskelligt fra det du forslår i #1? Digital signatur bruger også Java.
Jeg troede problemet var at den var IE only, men okay.Killa (33) skrev:Du vil lægge alt sikkerheden på maskiner du ikke kan stole på? Det var jo lige præcist det der var problemet med den gamle løsning.
Nix. Adresseændringer etc. er kun som login, og det andet afhænger af din bank.Killa (33) skrev:Jeg går ud fra at bankoverførsler, adresseændringer osv. skal signeres. Ellers virker det ret meningsløst med den private key der ligger hos DanID.
I Dansk Bank bruger man ikke NemID til signering.
Nej, det gør den ikke.Killa (33) skrev:Det kommer jo lidt an på funktionen. Selve login delen behøver selvfølgelig ikke at være Java, men jeg går ud fra at appletten også tager sig af signering af ændringer du laver efter du er logget på.
DanIDs argument for at bruge en Applet var "lol, vi kan ikke få HTMl til at virke på Mac (ikke OSX)" og "lol, vi skal da have logfiler!!!11111".
Begge meget dårlige argumenter :p
Helt enig. Men derfor kan vi godt bruge HTML4 :pRasmus Faber (34) skrev:1) Browser-kompatibilitet: den skal virke i alle de mest anvendte browsere. Så det går altså f.eks. ikke, at anvende HTML5.
Man burde decompilere deres Java Applet og checke om det faktisk passer :pRasmus Faber (34) skrev:2) Der ønskes en mere sikker udveksling af password end f.eks. form-submit over HTTPS. NemID bruger SRP-protokollen. Der findes ganske vist en Javascript-implementation af SRP, men jeg er personligt utryk ved deres tilfældighedsgenerator (det er ikke meget entropi, man har adgang til gennem Javascript).
Men under alle omstændigheder giver jeg ikke meget for det som grundlag for at vi skal bruge en Java Applet. JavaScript implementation ville sikkert være god nok.
Java Appletten hjælper ikke her. Det gør det nærmest nemmere.Rasmus Faber (34) skrev:3) Løsningen skal være modstandsdygtig overfor man-in-the-browser angreb. I teorien er det naturligvist umuligt, men man kan gøre det mere besværligt for angriberne. Det må i det mindste være et krav, at løsningen ikke kan angribes med off-the-shelf værktøjer som Zeus og Spy-Eye.
Hvis DanID selv tror på at folk faktisk bekymre sig om hvem der har signede appletterne de åbner på internettet, så burde de ikke stå for folkets sikker.ed
Altså med undtagelse af at du siger HTTPS ikke er sikkert nok (srzly?), så er der altså ikke nogle gode argumenter for at bruge den.Rasmus Faber (34) skrev:Jeg vil personligt være meget interesseret i et design, der kan opfylde ovenstående lige så godt som en Java-applet.
Pjat.Rasmus Faber (36) skrev:Kortnummer, udløbsdato og PKK er væsentligt sværere at misbruge end dit NemID-login.
De fleste banker har da brugt HTTPS til login længe, hvor man udover brugernavn og password havde et elektronisk token (Dansk Bank har tilbudt det).
Så jeg giver altså ikke meget for argumentet om SRP.
Windcape (37) skrev:Jeg troede problemet var at den var IE only, men okay.
Digital signatur virker også i andre browsere og på Mac og Linux.
Windcape (37) skrev:Nix. Adresseændringer etc. er kun som login, og det andet afhænger af din bank.
I Dansk Bank bruger man ikke NemID til signering.
Hvis de keys der ligger hos DanID hverken bliver brugt til kryptering eller signering, kunne de jo lige så godt slette dem.
For mit tilfælde, kunne de ihvertfald godt.Killa (40) skrev:Hvis de keys der ligger hos DanID hverken bliver brugt til kryptering eller signering, kunne de jo lige så godt slette dem.
Jeg har endnu ikke oplevet at bruge NemID til signering. Kun til login. Og det gælder adresseflytning, SU, pas, homebanking, eboks, osv.
#44
Ah, ja, det er korrekt. Og hvis du sender en signeret mail, så for modtageren på rådhuset en identitetsbekræfigelse når de modtager din mail.
Men de kan ikke selv, på rådhuset, sende mails krypterede med din NemID, som så kun du kan dekryptere.
Mig og min makker lavede et forsøg hos Aarhus Kommune's Lønhuset.
Og jeg kan også fortælle hvorfor. Århus Kommune bruger Lotus Notes som mail client, og Lotus Notes understøtter det simpelthen ikke. Af samme grund bliver signaturer checket på deres mailserver, før den bliver videresendt internt.
Det skal måske lige siges at det var den digitale signatur vi testede med, og ikke NemID. Men jeg tvivler på tingene har ændret sig markandt (Det var i foråret 2010 vi gennemførte forsøget)
Ah, ja, det er korrekt. Og hvis du sender en signeret mail, så for modtageren på rådhuset en identitetsbekræfigelse når de modtager din mail.
Men de kan ikke selv, på rådhuset, sende mails krypterede med din NemID, som så kun du kan dekryptere.
Mig og min makker lavede et forsøg hos Aarhus Kommune's Lønhuset.
Og jeg kan også fortælle hvorfor. Århus Kommune bruger Lotus Notes som mail client, og Lotus Notes understøtter det simpelthen ikke. Af samme grund bliver signaturer checket på deres mailserver, før den bliver videresendt internt.
Det skal måske lige siges at det var den digitale signatur vi testede med, og ikke NemID. Men jeg tvivler på tingene har ændret sig markandt (Det var i foråret 2010 vi gennemførte forsøget)
Hubert (42) skrev:Har de overhovedet åbnet for signering?
Vi snakker ikke om "digital signatur" as in "se mig, jeg har skrevet under på en email" og sådan. Det er ikke noget jeg har undersøgt, for jeg vil ikke bruge det alligevel.
Men hver gang jeg laver en transaktion i min netbank kommer der et bekræftelsesskærmbillede op, hvor jeg skal skrive mit password. Både mit kodeord og de data jeg bekræfter står i NemID-appletten. De data jeg bekræfter bliver signeret på klienten, og det gør livet lettere for bankens sikkerhedsafdeling.
Det gør der også her. Men hvorfor tror du det har noget med NemID at gøre?myplacedk (46) skrev:Men hver gang jeg laver en transaktion i min netbank kommer der et bekræftelsesskærmbillede op, hvor jeg skal skrive mit password.
Det gjorde man også årtier før den digitale signatur, og NemID.
Windcape (47) skrev:Det gør der også her. Men hvorfor tror du det har noget med NemID at gøre?
Primært at det er NemID-appletten.
Og så tager vi lige pointen én gang til, og så gider jeg altså ikke mere: Appletten signerer. Nogle netbanker som bruger NemID-appletten på den måde, havde ikke clientside signering før. Om andre havde ved jeg ikke.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund