mboost-dp1
PBS A/S
Charlotte Jacoby skrev:Charlotte Jacoby understreger dog, at overvejelserne ikke har noget at gøre med de sidste par ugers store fokus på sårbarheder i Java, da hun pointerer, at der til alle platforme jævnligt findes sårbarheder
Jeg ved slet ikke hvad jeg skal sige til den udtalelse. Jeg må dog indrømme, at den ikke får mig til at føle at det er verdens mest kompetente personer der administrerer nem-id.
#1
Det var også det jeg lagde mest mærke til, ved nyheden. Hun siger jo lige ud, at de vil skide på over 4 millioner danskeres IT sikkerhed. Det burde være strafbart!
Det var også det jeg lagde mest mærke til, ved nyheden. Hun siger jo lige ud, at de vil skide på over 4 millioner danskeres IT sikkerhed. Det burde være strafbart!
#2 Hun siger jo bare, at det ikke er en tju hej beslutning, som er taget på baggrund af én hændelse - Det ville i mine øjne have gjort hende useriøs :-D
Som hun siger, så har man aldrig en garanti for, at samme problematik ikke vil kunne findes i andre systemer. Det har hun ganske ret i, så at skifte som en reaktion på den seneste javeproblematik ville være dybt useriøst.
Som hun siger, så har man aldrig en garanti for, at samme problematik ikke vil kunne findes i andre systemer. Det har hun ganske ret i, så at skifte som en reaktion på den seneste javeproblematik ville være dybt useriøst.
Er det her ikke et spørgsmål om at når en platform bliver lige så populær som Java, så er den et attraktiv mål for hackere og exploiters? Hvis Nem ID var baseret på [Insert Random Platform] og denne platform var populær, ville sagen jo nok få lige så meget presse-dækning?
Der jo java i -næsten- alt, det er jo nok derfor at det er så katastrofalt at denne sårbarhed blev fundet. Men til Oracles forsvar, var de jo også hurtig ude med en midlertidig update, der fixede problemet so-so.
Tror bare ikke på at en udskiftning af Java, fører til ren success med hensyn til sikkerhed.
Skal lige siges, at jeg har INGEN aktier i at java eller nogen som helst anden platform får Nem ID som kunde...
Der jo java i -næsten- alt, det er jo nok derfor at det er så katastrofalt at denne sårbarhed blev fundet. Men til Oracles forsvar, var de jo også hurtig ude med en midlertidig update, der fixede problemet so-so.
Tror bare ikke på at en udskiftning af Java, fører til ren success med hensyn til sikkerhed.
Skal lige siges, at jeg har INGEN aktier i at java eller nogen som helst anden platform får Nem ID som kunde...
Mort (6) skrev:Jeg kan ikke se nogen grund til at der skal bruges mere end en HTTPS webside til at authenticate brugerne, HTTPS understøttes på alle platforme og har ikke konstante sikkerhedsproblemer.
Det var da noget af det mest inkompetente jeg har læst længe.
Har du huske at få refunderede dine penge fra Skat?
Der er et par mails som garanteret er i din spam mappe, som går ind på et par HTTPS sider. Det er ihvertfald en ren html hjemmeside.
held og lykke.
Hack4Crack (8) skrev:
Der er et par mails som garanteret er i din spam mappe, som går ind på et par HTTPS sider. Det er ihvertfald en ren html hjemmeside..
Jeg kan meget nemt lave noget der ligner et NemID-login i jQuery der beder om nøglekort ID efter et par gange hvor den ikke kan logge ind. Derudover kan jeg også fint lave en email der minder om NemID's.
Du kan ikke sammenligne exploits med phising.
Det er jeg stort set enig i. Jeg kan ikke se nogen sikkerhedsmæssig fordel ved at bruge nogen form for scripting på klientsiden. Derudover underbygges dit argument af at alle løsninger med scripting på klientsiden alligevel er afhængige af https til at sikre integriteten af den kode der køres på klienten. Det vil sige at hvis du tilføjer scripting, så kan du kun tilføje flere huller, du kan ikke fjerne dem der allerede måtte være der i https.Mort (6) skrev:Jeg kan ikke se nogen grund til at der skal bruges mere end en HTTPS webside til at authenticate brugerne, HTTPS understøttes på alle platforme og har ikke konstante sikkerhedsproblemer.
Hvad der også er vigtigt ved https er at man har mere frihed til at vælge mellem forskellige implementationer. Skulle en implementation af https vise sig at være svag, så kan man skifte til en anden.
Mort (6) skrev:Jeg kan ikke se nogen grund til at der skal bruges mere end en HTTPS webside til at authenticate brugerne, HTTPS understøttes på alle platforme og har ikke konstante sikkerhedsproblemer.
Helt enig! Jeg tror også netop, at det var det vi alle studsede over da Nemid blev lanceret - hvorfor dog bruge andet en HTML og js (over https) på klientsiden?
Jeg ved at det primære argument er er de her certifikater, men helt ærligt.. Det er meget fint at Nemid-binary'en er signeret, så folk kan se at de kan stole på den osv, men folk klikker jo alligevel 'accepter' - ligemeget om certifikatet til SSL/TLS eller java-applet'en er udløbet eller har fejl.
Kian (3) skrev:Er der nogen all-around-sprog som kan anvendes til samtlige platforme udover Java? Personligt er jeg vild med .NET men det er vel langt mere problematisk end Java.
For mange til at nævne her, men problemet er nok mere at det skal kunne køre i din browser og så er der jo ikke mange.
Silverlight er ved at dø ... og knapt så godt supported på andre platforme end Windows.
Java ... som er træls at opdatere, men virker oftests på alle platforme.
Men hvorfor ikke bare html/js ... som jeg ikke den store indsigt i hvad der gør at man skal over på slem-id, for at lave auth, men det er der sikkert en klogere person som er mere inde i det kan fortælle mig.
#hvad NemID faktisk gør
https://www.nets-danid.dk/om_nets_danid/privatlivs...
https://www.nets-danid.dk/om_nets_danid/privatlivs...
Vi indsamler også oplysninger om den pc, du logger på vores hjemmesider fra (ikke personoplysninger) til brug for sikkerhedsmæssige tiltag.
De oplysninger, vi indsamler om pc’en omfatter:
Browsertype
Computertype
Styresystem
Forbindelsestype (ISDN, ADSL o.l.)
Skærmopløsning
Disse oplysninger eller din adfærd på nettet sammenstilles ikke med dine personoplysninger.
Herudover indsamler vi:
Oplysning om IP adresse
PC-checksum (teknik til beregning af unik identifikation af en pc).
Oplysninger om tjenesteudbydere, du besøger, hvis du har valgt denne mulighed til
Oplysning om tidspunkt, hvor du har besøgt en given hjemmeside.
Disse oplysninger kan anvendes ved efterforskning af misbrug eller forsøg på misbrug af NemID.
Grofle (9) skrev:Hack4Crack (8) skrev:
Der er et par mails som garanteret er i din spam mappe, som går ind på et par HTTPS sider. Det er ihvertfald en ren html hjemmeside..
Jeg kan meget nemt lave noget der ligner et NemID-login i jQuery der beder om nøglekort ID efter et par gange hvor den ikke kan logge ind. Derudover kan jeg også fint lave en email der minder om NemID's.
Du kan ikke sammenligne exploits med phising.
Jeg kan også sagtens installere en keylogger, så kan du stikke din jQueries derop hvor solen aldrig skinner... velkommen til homespanking.
Hack4Crack (15) skrev:Grofle (9) skrev:Hack4Crack (8) skrev:
Der er et par mails som garanteret er i din spam mappe, som går ind på et par HTTPS sider. Det er ihvertfald en ren html hjemmeside..
Jeg kan meget nemt lave noget der ligner et NemID-login i jQuery der beder om nøglekort ID efter et par gange hvor den ikke kan logge ind. Derudover kan jeg også fint lave en email der minder om NemID's.
Du kan ikke sammenligne exploits med phising.
Jeg kan også sagtens installere en keylogger, så kan du stikke din jQueries derop hvor solen aldrig skinner... velkommen til homespanking.
Du ville stadig mangle "nøglen" fra nøglekortet.. Det jo ikke sådan, at den funktion kun kan laves i Java..
arne_v (14) skrev:#hvad NemID faktisk gør
https://www.nets-danid.dk/om_nets_danid/privatlivs...
Vi indsamler også oplysninger om den pc, du logger på vores hjemmesider fra (ikke personoplysninger) til brug for sikkerhedsmæssige tiltag.
De oplysninger, vi indsamler om pc’en omfatter:
Browsertype
Computertype
Styresystem
Forbindelsestype (ISDN, ADSL o.l.)
Skærmopløsning
Disse oplysninger eller din adfærd på nettet sammenstilles ikke med dine personoplysninger.
Herudover indsamler vi:
Oplysning om IP adresse
PC-checksum (teknik til beregning af unik identifikation af en pc).
Oplysninger om tjenesteudbydere, du besøger, hvis du har valgt denne mulighed til
Oplysning om tidspunkt, hvor du har besøgt en given hjemmeside.
Disse oplysninger kan anvendes ved efterforskning af misbrug eller forsøg på misbrug af NemID.
Problemet er så bare, at størstedelen af den information, sender du hvergang du tilgår en hjemmeside i form af din browsers useragent.
min: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.27 (KHTML, like Gecko) Chrome/26.0.1386.0 Safari/537.27
Hvad du kan se der er at jeg bruger Chrome, jeg bruger 64bit Windows version 6.1 (Windows 7), og spørger du browseren pænt så fortæller den dig gladeligt skærmopløsning (Ellers kan du bare tjekke det via css/js), og ved at tjekke hvem IP addressen du benytter tilhører, kan du lave et godt bud på hvilken slags forbindelse du er på (Tilhører den f.eks. TDC, så er det formentligt DSL, ComX, fiber etc. etc.)
--
NemID er en fiasko af kæmpe dimensioner, at kræve et nøglekort i denne tidsalder er simpelthen så latterligt. Ja, der er folk som ikke kan finde ud af at lave et godt password, men der er mange som kan. Tag hensyn til begge parter.
Og evt. brug et system ligesom Google gør. Normalt login+pw, men man kan udvide det med 2 factor auth.
De er endda ved at undersøge at bruge et hardware komponent som er bundet unikt til kontoen, så man kun kan logge ind med det stykke hardware i computeren (usb, bt, wifi etc.)
LaMaH (17) skrev:NemID er en fiasko af kæmpe dimensioner, at kræve et nøglekort i denne tidsalder er simpelthen så latterligt. Ja, der er folk som ikke kan finde ud af at lave et godt password, men der er mange som kan. Tag hensyn til begge parter.
Det er ikke af hensyn til evt. svage password fra brugerne, at de har lavet et system med nøglekort...
LaMaH (17) skrev:Problemet er så bare, at størstedelen af den information, sender du hvergang du tilgår en hjemmeside i form af din browsers useragent.
Da størstedelen ikke er alle, så er det vel ret ligegyldigt.
Og selvom det var alle, så vil der stadig være stor forskel på at få oplysningerne fra NemID kode fremfor fra en HTTP header som alle og enhver kan spoofe.
#hvorfor Java
HTTPS, nøglekort etc. kan sagtens laves uden Java.
Jeg vil formode at årsagerne til at man har valgt Java er:
* den beskrevne mulighed for at sende en identifikation af PC med requests
* fleksibilitet med hensyn til at kunne understøtte både central og decentral certifikater
* mulighed for en vis obfuskering af hvordan det egentligt foregår
HTTPS, nøglekort etc. kan sagtens laves uden Java.
Jeg vil formode at årsagerne til at man har valgt Java er:
* den beskrevne mulighed for at sende en identifikation af PC med requests
* fleksibilitet med hensyn til at kunne understøtte både central og decentral certifikater
* mulighed for en vis obfuskering af hvordan det egentligt foregår
Hvorfor denne overdrevne fokus, på hvilke informationer de kan (eller ikke kan) få om PC'en, når de informationer alligevel ikke bliver brugt til noget fornuftigt?
Det er jo ikke sådan, at jeg kan få f.eks. en SMS advarsel, hvis en eller anden, forsøger at logge ind fra en anden computer, end den jeg plejer. Og hvis det er for at kunne sandsynliggøre, at det er en bestemt computer der er blevet brugt, i forbindelse med svindel, så må det også kunne køres uden brug af Java. Hvad forhindre i øvrigt en svindler i at bruge en virtuel maskine, og slette den bagefter? Hvis deres sikkerhed er bygget op på lidt ekstra information de kan få ved at bruge Java, så er der ingen sikkerhed overhovedet.
Det er jo ikke sådan, at jeg kan få f.eks. en SMS advarsel, hvis en eller anden, forsøger at logge ind fra en anden computer, end den jeg plejer. Og hvis det er for at kunne sandsynliggøre, at det er en bestemt computer der er blevet brugt, i forbindelse med svindel, så må det også kunne køres uden brug af Java. Hvad forhindre i øvrigt en svindler i at bruge en virtuel maskine, og slette den bagefter? Hvis deres sikkerhed er bygget op på lidt ekstra information de kan få ved at bruge Java, så er der ingen sikkerhed overhovedet.
BurningShadow (21) skrev:Hvorfor denne overdrevne fokus, på hvilke informationer de kan (eller ikke kan) få om PC'en, når de informationer alligevel ikke bliver brugt til noget fornuftigt?
Nogen kilder på at de ikke bruge informationerne til noget?
BurningShadow (21) skrev:Det er jo ikke sådan, at jeg kan få f.eks. en SMS advarsel, hvis en eller anden, forsøger at logge ind fra en anden computer, end den jeg plejer.
Jeg vil tro at NemID overlader eventuelle actions til det ste hvor du er ved at logge ind.
BurningShadow (21) skrev:Og hvis det er for at kunne sandsynliggøre, at det er en bestemt computer der er blevet brugt, i forbindelse med svindel, så må det også kunne køres uden brug af Java.
Eneste alternativ jeg kan tænke på er ActiveX for Windows only.
BurningShadow (21) skrev:Hvad forhindre i øvrigt en svindler i at bruge en virtuel maskine, og slette den bagefter?
Intet. Men det er næppe pointen. Den fysiske PC kunne meget nemt tænkes at være på en NetCafe i Nigeria, så ...
Fanatiskfanboy (22) skrev:Indtil videre: Brug kun Java til NemID i VirtualBox.
Hvis ens religion forbyder en at arbejde på en PC med Java installeret, så er det et glimrende valg.
Hvis man bare vil undgå andre appletter, så er der betydeligt nemmere måder at gøre det på idag.
arne_v (19) skrev:Da størstedelen ikke er alle, så er det vel ret ligegyldigt.
Og selvom det var alle, så vil der stadig være stor forskel på at få oplysningerne fra NemID kode fremfor fra en HTTP header som alle og enhver kan spoofe.
jeg mener NemID anvender SRP som til 0-Knowledge kryptering af dit password.
Det kan idag gøres med Javascript, men kun på moderne browsere (som er alt efter IE8). IE6-8 giver eksempelvis op i i BigInt implementeringen af Javascript grundet det ekstreme antal loops. Resultatet er at brugeren skal godkende at scriptet fortsætter for at logge på.
Vi overvejede på et projekt hvilke muligheder der var for at fortsætte med at anvende SRP til vores login system, efter vi fandt IE problemet. Man kan lave en JS implementering og ved udvalgte browsere falde tilbage på fx Java eller Flash. Ulempen er at der skal vedligeholdes 2 sæt kode samt en liste over browsere (uanset om du vælger en blacklist eller whitelist løsning).
Man kan også droppe support for gamle browsere helt, det er desværre ikke en løsning bare at lade dem køre uden SRP da du så alligevel er nød til at opbevare brugerens password (hashed eller krypteret).
Vi endte med at skrotte SRP. God ide, der bare er lidt forud for sin tid.
Man anvender i øvrigt SRP (eller lign.) for at undgå man in the middle attacks. Typisk fordi man gerne vil undgå at en system administrator for serveren kan kigge logs igennem og se username/password efter de er dekrypteret (HTTPS)
Det er et gammelt interview denne artikel linker til.
Digitaliseringsstyrelsen har i forgårs meldt ud at der kommer en Javascript løsning i løbet af 12 måneder.
NemID i ny og mere mobil udgave på vej
Grønt lys for NemID på Javascript: Login fra mobilen klar om et år
At det så ville være rart hvis den kom lidt hurtigere er noget andet.
Digitaliseringsstyrelsen har i forgårs meldt ud at der kommer en Javascript løsning i løbet af 12 måneder.
NemID i ny og mere mobil udgave på vej
Grønt lys for NemID på Javascript: Login fra mobilen klar om et år
At det så ville være rart hvis den kom lidt hurtigere er noget andet.
jonashn (1) skrev:Jeg ved slet ikke hvad jeg skal sige til den udtalelse. Jeg må dog indrømme, at den ikke får mig til at føle at det er verdens mest kompetente personer der administrerer nem-id.
BurningShadow (2) skrev:#1
Det var også det jeg lagde mest mærke til, ved nyheden. Hun siger jo lige ud, at de vil skide på over 4 millioner danskeres IT sikkerhed. Det burde være strafbart!
Gør hun nu også det?
Hun har teknisk set ret. Der findes sårbarheder i alle platforme. I to hopper direkte på vognen af de folk der lader sig påvirke af nyheder - i dette tilfælde nyheder om sikkerhedshuller i Java - på trods af at der - til min viden - endnu ikke er demonstreret noget exploits der gør aktivt brug af omtalte sikkerhedshuller.
"If it's in the news, don't worry about it."
- Bruce Schneier, Security Expert
Selv uden brug af Java er NemID sårbart på mange andre områder, inkl. virus/malware og MITM angreb. Jeg er ikke selv stor fan af Java, og ligesom #1 bekymrer jeg mig også om kompetencen hos de mennesker der administrerer NemID, men det gør jeg af helt andre årsager end deres valg af platform. F.eks. bekymrer det mig stærkt at NemID ikke differentierer mellem store og små bogstaver i adgangskoden, en absolut dum sikkerhedspraktik jeg ikke mindes at have set andre steder før. Det er sådanne beslutninger der får mig til tvivle stærkt på sikkerheden ved hele konceptet.
#28
Politikere fører altid panik-politik, det faktum at der for én gangs skyld er én der ikke gør det, virker meget mistænkeligt, og jeg kan ikke se, hvordan det kan tolkes anderledes, end at hun er skide ligeglad.
Politikere fører altid panik-politik, det faktum at der for én gangs skyld er én der ikke gør det, virker meget mistænkeligt, og jeg kan ikke se, hvordan det kan tolkes anderledes, end at hun er skide ligeglad.
Er blevet er træt af java/nemid at jeg har fjernet java fra samtlige af mine maskiner, og det har fået mig til at tænkte over hvor tit jeg ellers bruger java. Det er nu halvt år siden, og har endnu ikke haft brug for det. Selv på mit arbejde hvor jeg ofte konfiguerer netværks udstyr (som næsten altid bruger java i deres webinterface) kan jeg heldigvis bare klare mig via CLI.
Netbank App er for mig at se en meget mere sikker løsning, og den bruger slet ikke NemID. Den er bundet til min iPhone, så selvom jeg indlæste en backup til en anden iPhone, så skulle den nye enhed godkendes med en ny engangskode genereret fra netbank (ja oki der kunne jeg så ikke komme uden om java...)
Der er i øvrigt SMSkode godkendelse når der skal overføres penge eller betales regninger.
Min iPhone er ikke jailbreaked, så mon ikke den løsning er mere sikker?
Netbank App er for mig at se en meget mere sikker løsning, og den bruger slet ikke NemID. Den er bundet til min iPhone, så selvom jeg indlæste en backup til en anden iPhone, så skulle den nye enhed godkendes med en ny engangskode genereret fra netbank (ja oki der kunne jeg så ikke komme uden om java...)
Der er i øvrigt SMSkode godkendelse når der skal overføres penge eller betales regninger.
Min iPhone er ikke jailbreaked, så mon ikke den løsning er mere sikker?
BurningShadow (29) skrev:#28
Politikere fører altid panik-politik, det faktum at der for én gangs skyld er én der ikke gør det, virker meget mistænkeligt, og jeg kan ikke se, hvordan det kan tolkes anderledes, end at hun er skide ligeglad.
Nej de gør ikke. Politikere er ret ofte tilbageholdende, og fører kun panik-politik når deres troværdighed (og derved popularitet) er under angreb. Siden hoveddelen af befolkningen enten ikke er IT-kyndige eller bare ikke giver en f*** om Javas sårbarheder, så har hun netop ingen grund til at føre panik-politik.
At i to hopper på IT-sikkerhedspanikvognen er mere pinligt end hendes optræden. I har ikke konstateret om der er en reel trussel eller ej, og drager konklusioner baseret på hvad der er hype i medierne. Det er ikke en fornuftig fremgangsmåde :o)
Nu er jeg ikke nogen haj til programmering og kan eller vil ikke anbefale et sprog frem for et andet. Jeg er heller ikke nogen sikkerhedsekspert. Men jeg ser ikke at java er problemet, jeg ser hele opbygningen som problemet. Hvorfor vælger man ikke en certifikat agtig løsning som er båndet til computeren på den ene eller anden måde. Det kan, hvis det er designet rigtigt, vel eleminere man-in-the-middle angreb og hvis certifikatet er sikkert, så kan det vel også eleminere risikoen for misbrug af cetifikatet.
webnoob (32) skrev:Hvorfor vælger man ikke en certifikat agtig løsning som er båndet til computeren på den ene eller anden måde. Det kan, hvis det er designet rigtigt, vel eleminere man-in-the-middle angreb og hvis certifikatet er sikkert, så kan det vel også eleminere risikoen for misbrug af cetifikatet.
Fordi det ikke er så let som det ser ud til.
For det første kan intet bindes "sikkert" til en computer via software alene. Det kræver en hardware-implementering (en kryptografisk TPM), ellers kan certifikatet stjæles.
For det andet, så skal selve oprettelsen af certifikatet (transmitteringen til NemID's central af din offentlige nøgle, "håndtrykket" om du vil) også ske sikkert fra en maskine der ikke er kompromitteret, ellers kan det også misbruges.
For det tredje beskytter ingen af ovenstående dig mod malware. Malware vil stadigvæk kunne misbruge certifikatet da det afvikles direkte på din computer, og derved bare kan benytte dit certifikat/din TPM efter egen lyst.
Sidst men ikke mindst er hardware-løsningen jeg nævner problematisk. En hardware-baseret kryptografisk løsning kræver at man opretter et system der gør at folk kan kontakte NemID for at ophæve certifikatet (i tilfælde af at computeren bryder sammen, bliver stjålet etc.), og dette system er også åbent til misbrug. Samme problem ses med udstedelsen af ID kort i den virkelige verden. 5% af alle identifikationspapirer går årligt tabt (hvilket kræver man har et system så folk kan få udstedt et nyt ID), og et stykke identifikation kan aldrig være mere resistent over for forfalskning/identitetstyveri end den legitimation man skal fremvise for at få det udstedt. Det var sådan Mat Honan blev hacket.
Det mest sorte er at Jyske Bank havde 100% samme nøglekortsløsning som HTTPS request via normal HTML før NemID løsningen og det var lige så sikkert. Mht. at fake en hjemmeside så vil certifikatet jo ikke være korrekt eller officielt signed så browseren vil ikke vise en lås og/eller komme med en advarsel.
TwistedSage (34) skrev:Det mest sorte er at Jyske Bank havde 100% samme nøglekortsløsning som HTTPS request via normal HTML før NemID løsningen og det var lige så sikkert. Mht. at fake en hjemmeside så vil certifikatet jo ikke være korrekt eller officielt signed så browseren vil ikke vise en lås og/eller komme med en advarsel.
Det kunne da være fedt hvis du ville uddybe "lige så sikkert".
HTTPS er mig bekendt kun sikkert frem til webserveren i den anden ende. Derfra sendes requestet ukrypteret ind til selve applikationen der klarer resten. En sur sysmin kan altså logge alle bruger/password kombinationer.
TwistedSage (34) skrev:Det mest sorte er at Jyske Bank havde 100% samme nøglekortsløsning som HTTPS request via normal HTML før NemID løsningen og det var lige så sikkert. Mht. at fake en hjemmeside så vil certifikatet jo ikke være korrekt eller officielt signed så browseren vil ikke vise en lås og/eller komme med en advarsel.
Hold nu op med at påstå at det kunne gøres "lige så sikkert" med HTTPS. Det viser bare at folk lukker en masse lort ud uden at have styr på hvad de snakker om.
Man startede faktisk med at forsøge at lave en JS baseret løsning, men implementationerne er simpelhen ikke hurtige nok, da de IKKE bare sender dine informationer. De opretter en krypteret tunnel igennem SSL, som altså end-to-end krypterer alle data du udveksler med DanID. Dette er ikke trivielt, og kan ikke bare klares med en formular i HTML/Javascript over HTTPS, som mange herinde (og på V2) tilsynelandende tror.
Nogle af landets/verdens førende sikkerheds/krypterings-eksperter har kigget på denne her løsning, det er ikke bare en flok bebumsede teenagere og politikere i en kælder.
Mht. kritikken af et pap-kort. De ville gerne have valgt en elektronisk løsning, men brugertests viste at folk troede mere på at papkortet var tilfældigt (ja det er noget vrøvl, men sådan er Hr/Fru Danmark), derfor valgte man noget folk havde tillid til.
Alle systemer er desuden sårbare overfor aktivt Man-in-the-middle angreb, det kan man simpelhen ikke komme udenom, og den voldsomme kritik af NemID på baggrund af dette er helt vanvittig. Ja, DanID har opført sig som nogle tåber nogle gange, ja det giver ikke mening at lave GIF filer som indholder executables, men det betyder ikke at hele systemet er usikkert.
[/rant]
Athinira (31) skrev:
At i to hopper på IT-sikkerhedspanikvognen er mere pinligt end hendes optræden. I har ikke konstateret om der er en reel trussel eller ej, og drager konklusioner baseret på hvad der er hype i medierne. Det er ikke en fornuftig fremgangsmåde :o)
Kære Athinira. Du har ikke beskrevet min fremgangsmåde korrekt her. At jeg betragter java dom en sikkerhedstrussel der er rimelig stor, skyldes på ingen måde danske mainstreammedier, men folk hvis skriverier jeg læser. Jeg har dannet min mening om java bl. a. ud fra ting sagt og skrevet af Bruce Schneier, Steve Gibson og Troy Hunt. Af sidste kan fx nævnes http://www.troyhunt.com/2013/01/is-java-root-of-al... . Jeg betragter Troy som en meget troværdig mand - hvis du ikke gør det er det selvfølgelig i orden.
T-Hawk (36) skrev:Hold nu op med at påstå at det kunne gøres "lige så sikkert" med HTTPS. Det viser bare at folk lukker en masse lort ud uden at have styr på hvad de snakker om.
Man startede faktisk med at forsøge at lave en JS baseret løsning, men implementationerne er simpelhen ikke hurtige nok, da de IKKE bare sender dine informationer. De opretter en krypteret tunnel igennem SSL, som altså end-to-end krypterer alle data du udveksler med DanID. Dette er ikke trivielt, og kan ikke bare klares med en formular i HTML/Javascript over HTTPS, som mange herinde (og på V2) tilsynelandende tror.
'De opretter en krypteret tunnel igennem SSL' - er det ikke det HTTS gør med TLS?
Spørgsmålet er vel, om de var nødt til at lave deres 'egen' krypteret tunnel-implementation i stedet for at bruge TLS, og det er vi tilsyneladende lidt uenige om.
jonashn (38) skrev:T-Hawk (36) skrev:Hold nu op med at påstå at det kunne gøres "lige så sikkert" med HTTPS. Det viser bare at folk lukker en masse lort ud uden at have styr på hvad de snakker om.
Man startede faktisk med at forsøge at lave en JS baseret løsning, men implementationerne er simpelhen ikke hurtige nok, da de IKKE bare sender dine informationer. De opretter en krypteret tunnel igennem SSL, som altså end-to-end krypterer alle data du udveksler med DanID. Dette er ikke trivielt, og kan ikke bare klares med en formular i HTML/Javascript over HTTPS, som mange herinde (og på V2) tilsynelandende tror.
'De opretter en krypteret tunnel igennem SSL' - er det ikke det HTTS gør med TLS?
Spørgsmålet er vel, om de var nødt til at lave deres 'egen' krypteret tunnel-implementation i stedet for at bruge TLS, og det er vi tilsyneladende lidt uenige om.
SSL "stopper" når webserveren modtager den krypterede data. Her bliver det dekrypteret og sendt videre til din applikation ukrypteret.
Hvis du vil undgå at din systemadministrator kan kigge med i sin log, så er du nød til at lave en kryptering fra klienten til din server applikation. Det kan du mig bekendt ikke med SSL.
Se på ting som Lastpass - de krypterer al data fra klient til server vha js, og det fungerer lige godt på smartphones og computere.
Hvad forhindrer Dan-Id i at lave (eller bruge en eksisterende) en implementation af fx AES i JS, og så bruge public key til key generation hvorefter alt krypteres in transit med AES+cbc ell. lign.?
Tingene går afgjort ikke lige så hurtigt i js som i java, og jeg ved godt, at det måske er nemmere for malware at angribe js-kode der kører end en applet - men når andre har gjort det, ser jeg ikke hvorfor Dan-id ikke kan.
Hvis deres kryptering ikke er hurtig nok i JS, kan det være at de ikke bruger den hurtigste og mest optimerede algoritme?
Hvad forhindrer Dan-Id i at lave (eller bruge en eksisterende) en implementation af fx AES i JS, og så bruge public key til key generation hvorefter alt krypteres in transit med AES+cbc ell. lign.?
Tingene går afgjort ikke lige så hurtigt i js som i java, og jeg ved godt, at det måske er nemmere for malware at angribe js-kode der kører end en applet - men når andre har gjort det, ser jeg ikke hvorfor Dan-id ikke kan.
Hvis deres kryptering ikke er hurtig nok i JS, kan det være at de ikke bruger den hurtigste og mest optimerede algoritme?
ko (41) skrev:https://www.nets-danid.dk/produkter/for_tjenesteudbydere/nemid_tjenesteudbyder/nemid_tjenesteudbyder_support/tjenesteudbyderpakken/tu12/tu12_dokumentation_dk/2_implementeringsdokumentation/implementeringsvejledning_for_nemid.pdf
Fortæller lidt om det, appletten kan.
Så fik man alligevel lidt respekt for dem. Rimelig gennemarbejdet! Jeg ser dog stadig ikke noget der hindrer en JS-implementation. Selvfølgelig vil den ikke kunne køre på oldemors win95-maskine, men så kan hun få lov at bøvle med java.
Det med at det er sværere at dekompilere en java-applet end at kigge i HTML-kildekode er i øvrigt ikke relevant her - sikkerhed skal jo bero på god kryptografi, og ikke steganografi. Jeg tror faktisk også, at Dan-id har rimelig godt styr på det første.
jonashn (42) skrev:
Så fik man alligevel lidt respekt for dem. Rimelig gennemarbejdet! Jeg ser dog stadig ikke noget der hindrer en JS-implementation. Selvfølgelig vil den ikke kunne køre på oldemors win95-maskine, men så kan hun få lov at bøvle med java.
Bortset fra at det er et, indlysende, krav at NemID skal kunne køre på alle borgeres computere. Man kan altså ikke bare afvise folk for at have en for gammel browser e.l.
Kryptering er tungt arbejde, og bortset fra de nyeste browsere kan det ikke gøres effektivt i JS.
At have både en Java og en HTML/JS udgave, hvor mange problemer tror du ikke det vil give? Så skal de pludselig til at udvikle, fejlfinde, osv. på to udgaver af koden i to helt forskellige sprog. Det vil aldrig gå godt.
T-Hawk (43) skrev:
Bortset fra at det er et, indlysende, krav at NemID skal kunne køre på alle borgeres computere. Man kan altså ikke bare afvise folk for at have en for gammel browser e.l.
Det er rigtigt - og min pointe er netop, at "borgernes computere" i 2013 ikke kun inkluderer stationære og bærbare der kan køre Java, men også mobile enheder der kører iOS, Android og WP.
Derfor kan man ikke bare ignorere dem - og det er netop ikke ret fremtidssikret at lave en implementation der ikke fungerer på de enheder.
Det er også en af grundene til, at jeg virkelig tog mig til hovedet da det kom frem, at de ville bruge Java - det nødvendiggjorde, at de på et tidspunkt enten lavede en HTML/JS-implementation, eller lavede et API til mobile appls (også ekstra arbejde)
T-Hawk (43) skrev:
At have både en Java og en HTML/JS udgave, hvor mange problemer tror du ikke det vil give? Så skal de pludselig til at udvikle, fejlfinde, osv. på to udgaver af koden i to helt forskellige sprog. Det vil aldrig gå godt.
Det er muligt, og det er gjort før - men jeg er enig i, at det er besværligt.
Man kunne netop undgå besværet, hvis man havde droppet Java fra starten af.
T-Hawk (43) skrev:Kryptering er tungt arbejde, og bortset fra de nyeste browsere kan det ikke gøres effektivt i JS.
Tungt er vel et vidt begreb her eller?
Hvor meget er det lige som skal krypteres? Snakker vi ikke stadig kun om validering eller bruges slem-id også efter man er logget ind?
Jeg tvivler på der er mange brugere af IE6( 0,070 fra FDIM ) ...
Hvem siger denne lille bruger flade bruger netbank, det kan vel ligeså godt være opstillede PC'er ...
Jeg tror den almindelige bruger hvis de fik det forklaret, godt kunne se det smarte i at få en ny brwoser og dermed at det hele blev billigere og nemmere for dem selv ville kunne forstå det.
syska (45) skrev:Tungt er vel et vidt begreb her eller?
Hvor meget er det lige som skal krypteres? Snakker vi ikke stadig kun om validering eller bruges slem-id også efter man er logget ind?
Jeg tvivler på der er mange brugere af IE6( 0,070 fra FDIM ) ...
Hvem siger denne lille bruger flade bruger netbank, det kan vel ligeså godt være opstillede PC'er ...
Jeg tror den almindelige bruger hvis de fik det forklaret, godt kunne se det smarte i at få en ny brwoser og dermed at det hele blev billigere og nemmere for dem selv ville kunne forstå det.
IE6,7 og 8 bruger samme javascript motor. Det er knap 16% af alle FDIM site besøgende der er på en af de 3 browsere.
mfriis (46) skrev:IE6,7 og 8 bruger samme javascript motor. Det er knap 16% af alle FDIM site besøgende der er på en af de 3 browsere.
Ja okay, point taken.
Men hvis vi stadig snakker 20ms i chrome og 1000ms i overnævnte browsere, så har det i min verden ingen betydning.
Men er der nogen der kan svare på om det bliver brugt ved andet end Auth af sin nem-id, for så synes jeg at snakker om performance problemer er lige til at lukke op og skide i.
Java tager allerede nu LANG tid om at starte op ... dvs flere sekunder på ældre maskiner. Det er der aldrig nogen der snakker om.
Inden vi fortsætte med at sige javascript er langsomt til dette, er der så ikke nogen der kan komme med tal for betydningen af langsom her ... hvis min overstående tanke omkring performance (20ms vs 1000ms) er korrekt, så synes jeg det er totalt ligegyldig, hvis det kun er login delen.
syska (47) skrev:Ja okay, point taken.
Men hvis vi stadig snakker 20ms i chrome og 1000ms i overnævnte browsere, så har det i min verden ingen betydning.
Men er der nogen der kan svare på om det bliver brugt ved andet end Auth af sin nem-id, for så synes jeg at snakker om performance problemer er lige til at lukke op og skide i.
Java tager allerede nu LANG tid om at starte op ... dvs flere sekunder på ældre maskiner. Det er der aldrig nogen der snakker om.
Inden vi fortsætte med at sige javascript er langsomt til dette, er der så ikke nogen der kan komme med tal for betydningen af langsom her ... hvis min overstående tanke omkring performance (20ms vs 1000ms) er korrekt, så synes jeg det er totalt ligegyldig, hvis det kun er login delen.
Langsom behøver ikke være eneste faktor. Som jeg også nævnte tidligere i tråden så giver netop IE6,7 og 8's motor op allerede ved nogen få tusind iterationer igennem de samme løkker. Den tror den kører i en uendelig løkke.
Netop ved kryptering kan du nemt komme ud i en situation hvor du skal iterere rigtig mange gange. Skal du op i en strengere kryptering (eksempelvis 2048) så bygger mange JS krypterings algogitmer på BigInt (http://www.leemon.com/crypto/BigInt.html). Netop Bigint.js er notorisk for at fremprovokere script timeout dialogen i IE browsere.
Som jeg læser det, så er der ingen der har prøvet og alt handler om mulige forhindringer mere end det handler om det ikke kan lade sig gøre.
Der er jo mindst ligeså mange forhindringer ved Java. Virker ikke, uninstall, install, for gammel version, you name it ...
Nu kan løsningen jo gøres nemmere, som jeg ser det. Opdater din browser, så virker det ... så det med IE6,7,8 synes jeg er et ligeså ringe argument som at man skal opdatere Java for at nem-id virker ...
Eller er det noget jeg har misforstået her?
Der er jo mindst ligeså mange forhindringer ved Java. Virker ikke, uninstall, install, for gammel version, you name it ...
Nu kan løsningen jo gøres nemmere, som jeg ser det. Opdater din browser, så virker det ... så det med IE6,7,8 synes jeg er et ligeså ringe argument som at man skal opdatere Java for at nem-id virker ...
Eller er det noget jeg har misforstået her?
syska (49) skrev:Som jeg læser det, så er der ingen der har prøvet og alt handler om mulige forhindringer mere end det handler om det ikke kan lade sig gøre.
Der er jo mindst ligeså mange forhindringer ved Java. Virker ikke, uninstall, install, for gammel version, you name it ...
Nu kan løsningen jo gøres nemmere, som jeg ser det. Opdater din browser, så virker det ... så det med IE6,7,8 synes jeg er et ligeså ringe argument som at man skal opdatere Java for at nem-id virker ...
Eller er det noget jeg har misforstået her?
IE kan ikke opgraderes fra eksempelvis IE6 til 9. Jeg tror endda heller ikke det kan lade sig gøre fra IE7 til 9.
Jeg mener IE7 var standard browser i den første version af Vista. IE9 kræver Windows 7.
Så hvis du anvender XP eller Vista så kan du i realiteten ikke opgradere din browser.
At gennemtvinge en browser opgradering væk fra IE6-8 har været teoretiseret og forsøgt af mange. Oracle kan nagge dig til at opdatere Java, og lade dig gennemføre det på ganske kort tid.
Jeg siger ikke Java er et fantastisk valg til NemID men valget er næppe truffet uden at undersøge alternativer som fx Javascript.
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
- ⟨
- Nyheder
Gå til bund