mboost-dp1
NemID gjort lidt nemmere
Jeg har hørt om mange der brokker sig over NemID, specielt at et papkort er valgt som løsning. Det har jeg lavet en løsning på. NemmereID hedder mit program og det gør at du kan logge ind uden at skulle bruge papkortet. 1 gang for hvert NemID kort skal du dog tage et billede af kortet og give det til programmet, men herefter sker login uden at du selv skal indtaste nogen kode; det klarer NemmereID for dig. :)
Programmet kan hentes her:
http://ege.cc/
Det skal siges du ikke må tage billede af dit NemID kort, men det er der jo så mange som gør alligevel...
Programmet kan hentes her:
http://ege.cc/
Det skal siges du ikke må tage billede af dit NemID kort, men det er der jo så mange som gør alligevel...
Der er forhåbentlig ikke nogen der kan finde på at bruge et sådan program, uden at have fuld adgang til den hellige sovs, og selv compile den.
Hvordan kan vi vide at den ikke sender hele lortet til dig?
At det så også er dit eneste indlæg, gør bestemt ikke situationen bedre. Uanset hvad, ville jeg aldrig selv bruge sådan et program, uden fuld adgang til sovsen, men jeg ville dog stole lidt mere på det, hvis det var en jeg "kender", der havde lavet det.
Hvordan kan vi vide at den ikke sender hele lortet til dig?
At det så også er dit eneste indlæg, gør bestemt ikke situationen bedre. Uanset hvad, ville jeg aldrig selv bruge sådan et program, uden fuld adgang til sovsen, men jeg ville dog stole lidt mere på det, hvis det var en jeg "kender", der havde lavet det.
Det største problem ved nemid er at det kræver man installerer tredjepartssoftware med ubegrænsede rettigheder til at foretage sig hvad som helst på ens maskine.
Så vidt jeg kan se løser dit program ikke det problem. Det ser ud til at det kræver et stykke tredjepartssoftware mere.
Så med dit program har man nu ud over en browser brug for tre stykker software, som hver især kan kompromittere sikkerheden af både nemid og den computer det køres på:
- En JVM
- En applet
- En ekstra DLL fil
Så vidt jeg kan se løser dit program ikke det problem. Det ser ud til at det kræver et stykke tredjepartssoftware mere.
Så med dit program har man nu ud over en browser brug for tre stykker software, som hver især kan kompromittere sikkerheden af både nemid og den computer det køres på:
- En JVM
- En applet
- En ekstra DLL fil
#2 Dine kommentarer er selvfølgelig relevante men eftersom jeg ikke er villig til at forære omverdenen min sourcekode, så kan jeg kun tilbyde at nogen får mulighed for at se den igennem mod ikke at bruge den selv eller give den videre. Jeg ved ikke om der findes et sådan online sted hvor dette kan gøres. Ellers må vedkommende dukke op fysisk hvor jeg bor og se koden.
Men ellers kan man evt. decompile koden. Jeg har ikke obfuskeret den på nogen måde så f.eks. alle originale funktionsnavne ligger stadig i exe filen. Det behøver selvfølgelig ikke betyde noget for jeg kan blot have lagt andet i funktionerne, men hvis man er god til at decompile vil man se at mit program ingen netværksadgang kræver og ingen eksterne programmer kalder. Jeg ved ikke hvor nemt det er med .NET programmer.
At det er mit første indlæg gør selvfølgelig at I ikke har nogen indlæg at vurdere mig ud fra. Men selv hvis jeg havde lavet andre indlæg så ville I stadig ikke kunne stole på at programmet er harmløst.
#3 Mit program kræver en dll fra visual studio 2010 (som jeg også skriver på hjemmesiden, link er givet til vsredistx86 som giver den og andre filer) samt .NET 4.0 (fra windows update).
#4 Jeg har returneret venligheden. :)
Jeg vil dog sige at det ikke vil være mange folk som vil lægge et program op i deres eget navn hvis de havde onde hensigter. Domænet er også mit (som I selv kan checke med whois) og der kan I endda få adressen på mig. Så der er rigelig mulighed for at finde mig skulle I mene at jeres kort bliver misbrugt og I mistænker mig/mit program.
At jeg har kodet det i C++/CLI (.NET 4.0) er simpelthen fordi det var nemmest for mig. Jeg har ikke lavet en installer fordi så er der endnu mere kode som skal dokumenteres. Af samme grund har jeg ikke inkluderes 3rd parts softwaren (som er ren Microsoft software) i zip filen.
Men ellers kan man evt. decompile koden. Jeg har ikke obfuskeret den på nogen måde så f.eks. alle originale funktionsnavne ligger stadig i exe filen. Det behøver selvfølgelig ikke betyde noget for jeg kan blot have lagt andet i funktionerne, men hvis man er god til at decompile vil man se at mit program ingen netværksadgang kræver og ingen eksterne programmer kalder. Jeg ved ikke hvor nemt det er med .NET programmer.
At det er mit første indlæg gør selvfølgelig at I ikke har nogen indlæg at vurdere mig ud fra. Men selv hvis jeg havde lavet andre indlæg så ville I stadig ikke kunne stole på at programmet er harmløst.
#3 Mit program kræver en dll fra visual studio 2010 (som jeg også skriver på hjemmesiden, link er givet til vsredistx86 som giver den og andre filer) samt .NET 4.0 (fra windows update).
#4 Jeg har returneret venligheden. :)
Jeg vil dog sige at det ikke vil være mange folk som vil lægge et program op i deres eget navn hvis de havde onde hensigter. Domænet er også mit (som I selv kan checke med whois) og der kan I endda få adressen på mig. Så der er rigelig mulighed for at finde mig skulle I mene at jeres kort bliver misbrugt og I mistænker mig/mit program.
At jeg har kodet det i C++/CLI (.NET 4.0) er simpelthen fordi det var nemmest for mig. Jeg har ikke lavet en installer fordi så er der endnu mere kode som skal dokumenteres. Af samme grund har jeg ikke inkluderes 3rd parts softwaren (som er ren Microsoft software) i zip filen.
Rolig folkens.
Manden tilbyder et program der kan løse et irritationsmoment for mange, han skriver det er imod reglerne for brug af DanID, han har hans egen information på hjemmesiden, samt han svarer høfligt på spørgsmål.
Hvad med lige at give ham en chance?
Personligt har jeg en dongle og kan derfor ikke bruge programmet.
Manden tilbyder et program der kan løse et irritationsmoment for mange, han skriver det er imod reglerne for brug af DanID, han har hans egen information på hjemmesiden, samt han svarer høfligt på spørgsmål.
Hvad med lige at give ham en chance?
Personligt har jeg en dongle og kan derfor ikke bruge programmet.
#5 - du har så ødelagt 2 faktor delen af sikkerheden i NemID ved at lade et program på din computer gemme indholdet af nøglekortet på samme maskine, som du logger på NemID fra...
Jeg har ikke kontaktet DanID, som KaW, men jeg ville da anbefale dig at fjerne programmet igen inden de rent faktisk gør noget ved det.
Jeg begriber virkeligt ikke, hvorfor NemID er så stort et problem, at man vil sætte sig ned og lave et program, der kan klare at indtaste nøglerne for en...
Programmet er ikke lettere end normalt brug af NemID efter min mening.
Du skal altid indtaste dit selvvalgte password for at få indtastet nøglen + du skal også lige klikke på ikonet nede i startmenuen. Og mon ikke det selvvalgte password skal være længere end de 6 cifre en nøgle består af, for ikke at kunne brydes let, så du skal også indtaste flere tegn end nøglen.
Hvis du skal bruge din NemID på andre maskiner, skal du også lige have programmet liggende på en usb nøgle... det er satme lettere...
Og så, at du ikke vil udgive kildekoden, så andre ikke bruger det - what?
#7 - vil du have vi giver ham en chance, når han opfordrer til at kompromittere sikkerheden? Hvem får skylden, når en eller anden kegle derude får drænet sin konto efter at have brugt programmet? Desuden er der ingen info på siden om, at man ikke må indscanne sit kort.
Og så er det da en totalt ubrugelig grund, at han svarer høfligt på kommentarerne... tænk dig nu om.
Jeg har ikke kontaktet DanID, som KaW, men jeg ville da anbefale dig at fjerne programmet igen inden de rent faktisk gør noget ved det.
Jeg begriber virkeligt ikke, hvorfor NemID er så stort et problem, at man vil sætte sig ned og lave et program, der kan klare at indtaste nøglerne for en...
Programmet er ikke lettere end normalt brug af NemID efter min mening.
Du skal altid indtaste dit selvvalgte password for at få indtastet nøglen + du skal også lige klikke på ikonet nede i startmenuen. Og mon ikke det selvvalgte password skal være længere end de 6 cifre en nøgle består af, for ikke at kunne brydes let, så du skal også indtaste flere tegn end nøglen.
Hvis du skal bruge din NemID på andre maskiner, skal du også lige have programmet liggende på en usb nøgle... det er satme lettere...
Og så, at du ikke vil udgive kildekoden, så andre ikke bruger det - what?
#7 - vil du have vi giver ham en chance, når han opfordrer til at kompromittere sikkerheden? Hvem får skylden, når en eller anden kegle derude får drænet sin konto efter at have brugt programmet? Desuden er der ingen info på siden om, at man ikke må indscanne sit kort.
Og så er det da en totalt ubrugelig grund, at han svarer høfligt på kommentarerne... tænk dig nu om.
Han skriver jo netop det er imod reglerne at bruge programmet. Det står i nederste linie af hans første indlæg.
Hvem der får skylden når et program der ikke på noget tidspunkt har forsøgt at få adgang til nettet stjæler oplysninger?
Det er sgu ikke så sært at kvaliteten af diskussionerne her på newz er faldet på det seneste når man tænker på hvilket møgfald de fleste nye brugere får.
Hvem der får skylden når et program der ikke på noget tidspunkt har forsøgt at få adgang til nettet stjæler oplysninger?
Det er sgu ikke så sært at kvaliteten af diskussionerne her på newz er faldet på det seneste når man tænker på hvilket møgfald de fleste nye brugere får.
i dette tilfælde er møjfaldet fortjent- ligesåvel som en persom der fortæller om hvor vidunderligt det er at sniffe æther vil få et møgfald.
#8
At man opretter et brugernavn, udelukker ikke at man kan logge ind med CPR nr.
Brugernavn er ikke case-sensitive.
Password er ikke case-sensitive.
...bare for at nævne tre af de problemer det havde været aller simplest for dem at løse!
Og mon ikke det selvvalgte password skal være længere end de 6 cifre en nøgle består af,Nu ved jeg ikke om det er tilfældet, men DanID tager ikke sikkerheden alt for seriøst, så det er ingen selvfølge.
At man opretter et brugernavn, udelukker ikke at man kan logge ind med CPR nr.
Brugernavn er ikke case-sensitive.
Password er ikke case-sensitive.
...bare for at nævne tre af de problemer det havde været aller simplest for dem at løse!
BurningShadow (12) skrev:At man opretter et brugernavn, udelukker ikke at man kan logge ind med CPR nr.
Brugernavn er ikke case-sensitive.
Jeg kan ikke se hvordan det kan være et problem for sikkerheden. Det ligger i brugernavnets natur at det gerne må være offentligt (hvilket jo også er årsagen til at det ikke bliver skjult af stjerner).
BurningShadow (12) skrev:Password er ikke case-sensitive.
Det er jo helt klart med vilje. Jeg forstår ikke hvorfor så mange gerne vil have det case sensitivt. Normalt opfatter man jo a og A som det samme bogstav, og på denne her måde slipper du også for problemerne med caps lock. At tilføje et ekstra tegn til din kode vil betyde langt mere for sikkerheden i din kode end at gøre den case sensitiv.
#13
Et password på 6 tegn, med bogstaverne a-å, A-Å og tallene 0-9 giver 98.867.482.624 muligheder.
Så er det, at du siger at det bedre kan betale sig at vælge et password med et ekstra tegn. Det giver 137.231.006.679 muligheder, og du har da helt ret i at det er en del mere, end 6 tegn, case sensitive.
Men hvad nu hvis, det var et case sensitive password med et ekstra tegn... Så er der 6.722.988.818.432 muligheder...
Jeg vil altså tillade mig at holde fast i at passwords skal være case sensitive.
Det har yderligere den fordel, at selv hvis folk vælger svage passwords, det er relativt lette at gætte (f.eks. hundens navn), så er det ikke kun selve passwordet der skal gættes, men også om hundens navn har et par store bogstaver i midten.
Jeg kan ikke se hvordan det kan være et problem for sikkerheden. Det ligger i brugernavnets natur at det gerne må være offentligt (hvilket jo også er årsagen til at det ikke bliver skjult af stjerner).Jo, for sådan som verden ser ud, så er det ikke så vanskeligt at finde folks CPR nr, men ved det at du ikke ved om din nabo bruger CPR nr, eller brugernavn, så er det blevet lidt vanskeligere for dig at logge ind på f.eks. hans net bank, for nu skal du ikke kun gætte et (case insensetive) password, men også et brugernavn.
Det er jo helt klart med vilje. Jeg forstår ikke hvorfor så mange gerne vil have det case sensitivt.Et password på 6 tegn, med bogstaverne a-å og tallene 0-9 giver 3.518.743.761 muligheder.
Et password på 6 tegn, med bogstaverne a-å, A-Å og tallene 0-9 giver 98.867.482.624 muligheder.
Så er det, at du siger at det bedre kan betale sig at vælge et password med et ekstra tegn. Det giver 137.231.006.679 muligheder, og du har da helt ret i at det er en del mere, end 6 tegn, case sensitive.
Men hvad nu hvis, det var et case sensitive password med et ekstra tegn... Så er der 6.722.988.818.432 muligheder...
Jeg vil altså tillade mig at holde fast i at passwords skal være case sensitive.
Det har yderligere den fordel, at selv hvis folk vælger svage passwords, det er relativt lette at gætte (f.eks. hundens navn), så er det ikke kun selve passwordet der skal gættes, men også om hundens navn har et par store bogstaver i midten.
Mht. til usikkerheden i at have kortinformationen liggende krypteret på sin disk mod at have NemID-kortet liggende frit læsbart i sin pengepung eller andet sted (kontor) så vil jeg nu foretrække den krypterede version.
NemID i sig selv er MEGA dårligt designet og det er netop grunden til at jeg har valgt at lave mit program. NemID gemmer endda billedfiler på din harddisk, men det er i virkeligheden eksekverbare filer! Dvs. NemID kan til enhver tid lægge andre eksekverbare filer ind på din harddisk og køre dem. Dvs. stort hul for regeringen til at lægge spyware ind på din pc. Temmelig suspekt løsning.
Set i det lys er mit program ikke ikke en særlig forværring af sikkerheden (nærmere en forbedring når man tænker på hvor folk lægger deres kort helt uden opsyn). Ja, folk kan kopiere datafilen med kortinformationen fra mit program, men den er trods alt krypteret med 3DES som går for at være en god kryptering (alt afhængig af det kodeord folk vælger). Med NemmereID er det største problem nok keyloggers hvis jeg ikke vælger at lave et andet password system (farve/form baseret). Keyloggers er dog ikke nok. De skal også have den krypterede datafil som ikke ligger et fast sted på harddisken (der er ingen jo installer). Jeg vil dog gerne give mulighed for at man kan låse datafilen til ens OS men jeg ved ikke lige hvordan jeg skal gøre dette. Det kræver jeg kan lave et unikt dataid for den aktuelle pc. Men så ryger flytbarheden...
Og jeg er nu ikke bekymret for DanID. Mit program er på ingen måde ulovligt at lave og gøre tilgængelig, men de kan muligvis nok kræve at jeg fjerne "NemID" ordene fra hjemmesiden.
NemID i sig selv er MEGA dårligt designet og det er netop grunden til at jeg har valgt at lave mit program. NemID gemmer endda billedfiler på din harddisk, men det er i virkeligheden eksekverbare filer! Dvs. NemID kan til enhver tid lægge andre eksekverbare filer ind på din harddisk og køre dem. Dvs. stort hul for regeringen til at lægge spyware ind på din pc. Temmelig suspekt løsning.
Set i det lys er mit program ikke ikke en særlig forværring af sikkerheden (nærmere en forbedring når man tænker på hvor folk lægger deres kort helt uden opsyn). Ja, folk kan kopiere datafilen med kortinformationen fra mit program, men den er trods alt krypteret med 3DES som går for at være en god kryptering (alt afhængig af det kodeord folk vælger). Med NemmereID er det største problem nok keyloggers hvis jeg ikke vælger at lave et andet password system (farve/form baseret). Keyloggers er dog ikke nok. De skal også have den krypterede datafil som ikke ligger et fast sted på harddisken (der er ingen jo installer). Jeg vil dog gerne give mulighed for at man kan låse datafilen til ens OS men jeg ved ikke lige hvordan jeg skal gøre dette. Det kræver jeg kan lave et unikt dataid for den aktuelle pc. Men så ryger flytbarheden...
Og jeg er nu ikke bekymret for DanID. Mit program er på ingen måde ulovligt at lave og gøre tilgængelig, men de kan muligvis nok kræve at jeg fjerne "NemID" ordene fra hjemmesiden.
BurningShadow (12) skrev:#8
Nu ved jeg ikke om det er tilfældet, men DanID tager ikke sikkerheden alt for seriøst, så det er ingen selvfølge.
At man opretter et brugernavn, udelukker ikke at man kan logge ind med CPR nr.
Brugernavn er ikke case-sensitive.
Password er ikke case-sensitive.
...bare for at nævne tre af de problemer det havde været aller simplest for dem at løse!
CPRnr. kan slås fra.
Derudover forsøgte jeg bare at pointere, at hvis man laver et password på under 6 tegn til det lille program #1 har lavet, så er du jo alligevel lige vidt, fordi det er let at bryde - derfor bliver du nødt til at lave et langt password til programmet og så skal du alligevel indtaste et længere password og så er det igen mere besværligt - efter min mening.
#15 - det dit program gør, svarer til, hvis du skriver pinkoden bag på dit dankort og du så får stjålet din pung...
Jeg er da klar over, at "tyven" skal lægge en keylogger eller lignende på din maskine og efterfølgende også stjæle dit lille program med nøglekortet i, men den samme risiko er der jo ikke, hvis man vælger at følge de regler som DanID har sat op og ikke scanner sit nøglekort ind.
Der var en gut, der lavede GlemID (hed det ikke det?) for et stykke tid siden. Det var en lille app, som kunne opbevare nøglekortet eletronisk i en app - den blev pillet af ret hurtigt... men det da kan da godt være DanID ikke ser noget problem i dit program - jeg tvivler bare på det. Der er en grund til, at de har sat nogle retningslinjer for hvordan man opbevarer nøglekortene - det er ikke bare for sjov...
#8 Jeg skriver faktisk på aller første side at man skal bruge et billede af sit NemID kort men at dette vil bryde reglerne for brugen af kortet. Jeg skriver det igen der hvor jeg forklarer nærmere i detaljer hvordan NemmereID læser kortet. Så jeg synes helt klart jeg gør opmærksom på at brugen af programmet kræver man bryder reglerne for brugen af kortet. Man kan også "bare" indtaste al information fra kortet direkte ind i NemmereID, men det fjerner jo lidt det smarte ved programmet.
Og ja, 2-faktor delen kompromiteres en anelse, men taget i betragtning at brugeren i forvejen ingen anelse har om at han/hun egentlig er inde på et rigtigt NemID site eller ej (man in the middle attack), så kan vedkommende uvidende jo videregive deres information alligevel. Jeg søgte at detektere dette med mit program, men fandt ikke en løsning der virkede. Havde jeg kunnet det, ville jeg kunne have forbedre sikkerheden i NemID systemet.
Og husk, at kopiere den krypterede nøglefil svarer til at en fremmed person tager billede af dit ubeskyttede NemID kort. Med en rimelig beskyttet pc ved jeg faktisk ikke hvilket scenarie der er mest sandsynligt.
#16 Jeg vil da ikke benægte at NemmereID teoretisk gør det muligt at en person i den anden ende af verden kan skaffe de nødvendige informationer (logins/nøglekort) hvis pc'eren kompromiteres, men netop derfor vil jeg da gerne gøre det muligt at låse nøglefilen til pc'eren for at gøre det vanskeligere at bruge data fra en anden pc. Evt. kan jeg bruge NemID's eksekverbare filer som hører til NemID java appletten. De genererer checksums over pc-systemet og bruges af DanID til at beskytte sig selv mod brugerne.
Jeg har først og fremmest lavet programmet til mig selv (og jeg har rimelig styr over mit system). Og jeg med mit program kan jeg logge ind på 3-4 sekunder fra jeg flytter hånden til musen for at klikke på NemmereID ikonet og til at koden er sat ind i feltet. Programmet er også lavet for at se om det i det hele taget kunne lade sig gøre (hvilket det kunne).
Jeg vil gerne øge sikkerheden i programmet så forslag modtages gerne.
Og ja, 2-faktor delen kompromiteres en anelse, men taget i betragtning at brugeren i forvejen ingen anelse har om at han/hun egentlig er inde på et rigtigt NemID site eller ej (man in the middle attack), så kan vedkommende uvidende jo videregive deres information alligevel. Jeg søgte at detektere dette med mit program, men fandt ikke en løsning der virkede. Havde jeg kunnet det, ville jeg kunne have forbedre sikkerheden i NemID systemet.
Og husk, at kopiere den krypterede nøglefil svarer til at en fremmed person tager billede af dit ubeskyttede NemID kort. Med en rimelig beskyttet pc ved jeg faktisk ikke hvilket scenarie der er mest sandsynligt.
#16 Jeg vil da ikke benægte at NemmereID teoretisk gør det muligt at en person i den anden ende af verden kan skaffe de nødvendige informationer (logins/nøglekort) hvis pc'eren kompromiteres, men netop derfor vil jeg da gerne gøre det muligt at låse nøglefilen til pc'eren for at gøre det vanskeligere at bruge data fra en anden pc. Evt. kan jeg bruge NemID's eksekverbare filer som hører til NemID java appletten. De genererer checksums over pc-systemet og bruges af DanID til at beskytte sig selv mod brugerne.
Jeg har først og fremmest lavet programmet til mig selv (og jeg har rimelig styr over mit system). Og jeg med mit program kan jeg logge ind på 3-4 sekunder fra jeg flytter hånden til musen for at klikke på NemmereID ikonet og til at koden er sat ind i feltet. Programmet er også lavet for at se om det i det hele taget kunne lade sig gøre (hvilket det kunne).
Jeg vil gerne øge sikkerheden i programmet så forslag modtages gerne.
galmok (17) skrev:#8 Jeg skriver faktisk på aller første side at man skal bruge et billede af sit NemID kort men at dette vil bryde reglerne for brugen af kortet.
havde overset det på forsiden ;-) Jeg ville nok gøre det tydeligere i form af en disclaimer eller lignende.
galmok (17) skrev:
Og ja, 2-faktor delen kompromiteres en anelse, men taget i betragtning at brugeren i forvejen ingen anelse har om at han/hun egentlig er inde på et rigtigt NemID site eller ej (man in the middle attack), så kan vedkommende uvidende jo videregive deres information alligevel. Jeg søgte at detektere dette med mit program, men fandt ikke en løsning der virkede. Havde jeg kunnet det, ville jeg kunne have forbedre sikkerheden i NemID systemet.
Er det jo ikke netop meningen med 2-faktor sikkerhed, at man adskiller det fra hinanden? Det er lidt svært, hvis man lægger nøglekortet ind på den samme maskine du logger på med NemID.
Man kan vel altid tjekke om man er på den korrekte hjemmeside ved at tjekke deres sikkerhedscertifikat? Det er vel det de bruges til?
galmok (17) skrev:
Og husk, at kopiere den krypterede nøglefil svarer til at en fremmed person tager billede af dit ubeskyttede NemID kort. Med en rimelig beskyttet pc ved jeg faktisk ikke hvilket scenarie der er mest sandsynligt.
Egentligt ikke - din krypterede nøglefil ligger på din computer som er tilsluttet internettet næsten konstant og du overvåger den ikke hele tiden. Dit nøglekort (for mange i hvert fald), ligger højst sandsynligvis i din pung fx - den er sq svær at tage billeder af imens den ligger i din lomme.
galmok (17) skrev:
#16 Jeg vil da ikke benægte at NemmereID teoretisk gør det muligt at en person i den anden ende af verden kan skaffe de nødvendige informationer (logins/nøglekort) hvis pc'eren kompromiteres, men netop derfor vil jeg da gerne gøre det muligt at låse nøglefilen til pc'eren for at gøre det vanskeligere at bruge data fra en anden pc. Evt. kan jeg bruge NemID's eksekverbare filer som hører til NemID java appletten. De genererer checksums over pc-systemet og bruges af DanID til at beskytte sig selv mod brugerne.
Igen, hvis jeg ikke kopierer mit nøglekort ind på min computer, så skal tyven stjæle min pung og min computer, mens hvis mit nøglekort ligger på min computer, skal tyven bare stjæle min computer.
Du foreslår at låse nøglekortet til maskinen - så er vi tilbage til nogle af bankernes gamle systemer - var det Danske Bank, der låste login til maskinerne? De låste det vist med en form for PC dna, så vidt jeg husker og pludselig er NemID utroligt ikke-nemt. Det fede ved NemID er jo netop, at man kan bruge det alle steder bare ved at have sit nøglekort eller dongle med sig.
galmok (17) skrev:
Jeg har først og fremmest lavet programmet til mig selv (og jeg har rimelig styr over mit system). Og jeg med mit program kan jeg logge ind på 3-4 sekunder fra jeg flytter hånden til musen for at klikke på NemmereID ikonet og til at koden er sat ind i feltet. Programmet er også lavet for at se om det i det hele taget kunne lade sig gøre (hvilket det kunne).
Kudos fordi du har lavet programmet - der ligger nok noget seriøs billedeanalyse bagved, men jeg mener bare ikke det giver dig ret til at opfordre andre til at bryde reglerne, hvilket jeg mener du gør ved at lave dit første indlæg.
Og selvfølgelig er det muligt at lave sådan et program - alt er muligt i programmering ;)
Du kan sgu da ikke argumentere med, at siden sikkerheden omkring NemID allerede er dårlig, så kan du sagtens bikse et lorteprogram sammen og gøre det endnu værre?! Det synes jeg lidt du gør pt.
Har den krypterede fil så samme navn på alle installationer? For i så fald burde det ikke være så svært at lave et program der søger efter filen.
galmok skrev:De skal også have den krypterede datafil som ikke ligger et fast sted på harddisken (der er ingen jo installer)
Har den krypterede fil så samme navn på alle installationer? For i så fald burde det ikke være så svært at lave et program der søger efter filen.
Hvis du ønsker vi skal tage dig seriøst, så er du nødt til at sandsynliggøre at dit program ikke er en trussel imod sikkerheden.galmok (5) skrev:eftersom jeg ikke er villig til at forære omverdenen min sourcekode
At frigive sourcekoden vil gøre meget for at styrke troværdigheden.
Du kan starte med at fortælle hvorfor du ikke vil frigive den. For hvis du alligevel forærer programmet væk, så kan jeg ikke se hvad du mister ved at give sourcekoden med.
Jeg kan komme med tre gæt på årsagen til at du ikke vil ud med sourcekoden:
- Du forventer at nogen vil finde et sikkerhedshul i din kode og udnytte det til at tage kontrol over din computer.
- Du har gemt en bagdør i koden og vil ikke have vi finder den.
- Du har en forkert opfattelse af hvordan computere fungerer, som får dig til at tro det udgør et problem at frigive sourcekoden.
Ingen af de tre forklaringer giver mig lyst til at bruge dit program. Hvis der er en anden årsag, som jeg ikke har kunnet gætte mig til, så må du fortælle hvad den er.
Men du får dog ikke mig til at bruge programmet med mindre det løser et problem. Jeg nævnte i mit tidligere indlæg hvilket problem jeg har med nemid, så du kan evt. overveje hvordan du kan modificere dit program til at løse det problem.
Darwind (18) skrev:havde overset det på forsiden ;-) Jeg ville nok gøre det tydeligere i form af en disclaimer eller lignende.
Done.
Darwind (18) skrev:
Er det jo ikke netop meningen med 2-faktor sikkerhed, at man adskiller det fra hinanden? Det er lidt svært, hvis man lægger nøglekortet ind på den samme maskine du logger på med NemID.
Man kan vel altid tjekke om man er på den korrekte hjemmeside ved at tjekke deres sikkerhedscertifikat? Det er vel det de bruges til?
Dette kræver så jeg laver browser plugins til alle slags browsere. Hvis API'en er fleksibel nok i browseren, så kunne hele NemmereID nok inkluderes i browseren som et plugin. Men billedbehandling i et scriptet sprog er ikke hurtigt... så det bliver nok et no-go.
Darwind (18) skrev:
Egentligt ikke - din krypterede nøglefil ligger på din computer som er tilsluttet internettet næsten konstant og du overvåger den ikke hele tiden. Dit nøglekort (for mange i hvert fald), ligger højst sandsynligvis i din pung fx - den er sq svær at tage billeder af imens den ligger i din lomme.
Jeg overvåger nu heller ikke min pengepung hele tiden. Faktisk bruger jeg slet ikke nogen pengepung. Jeg har blot de 2-3 kort med mig rundt som er nødvendige. Resten ligger hvor jeg nu end sidst har lagt det, inkl. NemID kortet.
Darwind (18) skrev:
Igen, hvis jeg ikke kopierer mit nøglekort ind på min computer, så skal tyven stjæle min pung og min computer, mens hvis mit nøglekort ligger på min computer, skal tyven bare stjæle min computer.
Skal også lure dine adgangsinformationer. Computeren alene er ikke nok.
Darwind (18) skrev:
Du foreslår at låse nøglekortet til maskinen - så er vi tilbage til nogle af bankernes gamle systemer - var det Danske Bank, der låste login til maskinerne? De låste det vist med en form for PC dna, så vidt jeg husker og pludselig er NemID utroligt ikke-nemt. Det fede ved NemID er jo netop, at man kan bruge det alle steder bare ved at have sit nøglekort eller dongle med sig.
Ja, vi er tilbage til gamle dage, men hvis jeg gør det valgfrit at låse, så kan man kopiere sin NemmereID installation ind på en ny pc og så låse den dertil. Der er selvfølgelig stadig det øjeblik USB-pinden sættes ind som er ubeskyttet (ud over kodeord) men risikoen sænkes meget.
Darwind (18) skrev:
Kudos fordi du har lavet programmet - der ligger nok noget seriøs billedeanalyse bagved, men jeg mener bare ikke det giver dig ret til at opfordre andre til at bryde reglerne, hvilket jeg mener du gør ved at lave dit første indlæg.
Og selvfølgelig er det muligt at lave sådan et program - alt er muligt i programmering ;)
Der ligger faktisk en del billedanalyse i det og disse algoritmer og metoder ønsker jeg ikke umiddelbart at dele med omverdenen som det ser ud nu. Jeg vil muligvis bruge billedanalysedelen i et firmaprojekt og så går det ikke koden allerede flyver rundt i verden, omend koden er rimelig generisk. Det kan være den situation ændrer sig og så vil jeg nok offentliggøre koden.
skovtrolden (19) skrev:Du kan sgu da ikke argumentere med, at siden sikkerheden omkring NemID allerede er dårlig, så kan du sagtens bikse et lorteprogram sammen og gøre det endnu værre?! Det synes jeg lidt du gør pt.
Det har du også ret i jeg gør. NemID har fået meget kritik i lang tid og får stadig mere. Jeg har aldrig selv synes at NemID er sikkert på nogen måde og i hvert fald langt værre end det gamle system med public/private key systemet.
Det retfærdiggør selvfølgelig ikke den del af min argumentation.
skovtrolden (19) skrev:
Har den krypterede fil så samme navn på alle installationer? For i så fald burde det ikke være så svært at lave et program der søger efter filen.
Pt. har den krypterede fil samme navn, men det giver mig da den ide at man skal kunne vælge navnet frit i f.eks. config filen. Og så vidt jeg ved (ikke testet) så kan exe filen og config filen blot renames til det man ønsker (skal dog være det samme navn) uden at det ødelægger noget. På den måde vil hverken program eller data have et fastlagt filnavn. Det vil være en rimelig simpel tilføjelse som jeg nok egentlig gerne vil bruge selv også. Jeg må til tasterne. ;-)
kasperd (20) skrev:Hvis du ønsker vi skal tage dig seriøst, så er du nødt til at sandsynliggøre at dit program ikke er en trussel imod sikkerheden.
At frigive sourcekoden vil gøre meget for at styrke troværdigheden.
Du kan starte med at fortælle hvorfor du ikke vil frigive den. For hvis du alligevel forærer programmet væk, så kan jeg ikke se hvad du mister ved at give sourcekoden med.
Der ligger godt nok flere måneders arbejde i det program med endnu flere måneders arbejde med prototyper i MATLAB. Så koden repræsenterer en vis værdi for mig, nok til at jeg ikke umiddelbart ønsker at forære den væk. Det er trods alt ikke et lille utility som er lavet på en eftermiddag.
kasperd (20) skrev:
Jeg kan komme med tre gæt på årsagen til at du ikke vil ud med sourcekoden:
- Du forventer at nogen vil finde et sikkerhedshul i din kode og udnytte det til at tage kontrol over din computer.
- Du har gemt en bagdør i koden og vil ikke have vi finder den.
- Du har en forkert opfattelse af hvordan computere fungerer, som får dig til at tro det udgør et problem at frigive sourcekoden.
Ingen af de 3 årsager er noget jeg har tænkt på. Eftersom programmets IO er simpel (billede ind, kode ud), så kan jeg ikke se hvordan sikkerheden i programmet i det hele taget skulle komme i spil. Der er ingen hemmelige bivirkninger i programmet. Alt hvad det kan er beskrevet. Der er nogle få konfigureringsmuligheder i config filen men det er kun til at få programmet til at spille bedre med evt. langsomme pc'ere. Jeg har desuden en rimelig viden om hvordan en pc virker. Jeg har f.eks. aldrig haft en pc-virus på trods af en næsten altid tændt pc uden firewall og virus scanner (og ja, jeg skanner måske en gang hvert halve år). Jeg erkender ikke at kende .NET så meget endnu, men det skal jeg nok blive bedre til.
kasperd (20) skrev:
Ingen af de tre forklaringer giver mig lyst til at bruge dit program. Hvis der er en anden årsag, som jeg ikke har kunnet gætte mig til, så må du fortælle hvad den er.
Koden repræsenterer simpelthen en værdi for mig. Denne værdi vil nok aftage over tid, men som det er nu er værdien for høj til at jeg ønsker at forære den væk. En anden årsag er nok også at forhindre DanID i at lure hvordan de kan forhindre mit program i at virke. Det vil jeg personligt være ked af fordi jeg netop har lavet programmet først og fremmest til mig selv. Jeg er modstander af at skulle rende rundt med det papkort og var i en situation hvor jeg skulle lave flere logins dagligt (var arbejdsløs og skulle logge ind på jobnet, fagforening, komunen, banken jævnligt). Det var nok til at irritere mig til at lave det program.
kasperd (20) skrev:
Men du får dog ikke mig til at bruge programmet med mindre det løser et problem. Jeg nævnte i mit tidligere indlæg hvilket problem jeg har med nemid, så du kan evt. overveje hvordan du kan modificere dit program til at løse det problem.
Jeg ved ikke hvordan man laver et program i windows der kører med færre rettigheder end alle andre programmer. Windows har ingen sandboks funktion og ingen mulighed for at forhindre f.eks. læsning af fremmede filer, skrivning fremmede steder, netværksbrug samt kørsel af programmer. Noget af dette kan løses ved at lave en ikke-priviligeret bruger som ejer filerne til NemmereID og som kun har rettigheder til at læse filerne i den folder den er (ud over normale dll filer har den ikke brug for andet). Det vil kunne løse det meste, men jeg ved ikke om det vil kunne forhindre netværksadgang skulle du have fået programmet fra en 3'de part som havde lagt en trojansk hest i.
DanID er jo f.eks. heller ikke villig til at dele sourcekoden med deres app med omverdenen, men du vil gerne tillade DanID fuld kontrol med adgang til din netbank med videre, samt fuld adgang med kontrol af din pc. Jeg gør det selv, men er da heller ikke glad for det.
Apropos kode - en kollega ville have en sikker kode - gav ham følgende eksempel på en kode der rager lang tid at knække
"JegHedderSteen0gBorIRavsted.JegArbejderHosFirmanavn" - skide nem og huske :P
"JegHedderSteen0gBorIRavsted.JegArbejderHosFirmanavn" - skide nem og huske :P
galmok (23) skrev:DanID er jo f.eks. heller ikke villig til at dele sourcekoden med deres app med omverdenen, men du vil gerne tillade DanID fuld kontrol med adgang til din netbank med videre, samt fuld adgang med kontrol af din pc. Jeg gør det selv, men er da heller ikke glad for det.
Du kan få lov til at se koden hvis du underskriver en NDA, og mht. brug af NemID er det ikke ligefrem valgfrihed der præger folks valg.
Mamad (moveax1ret) (10) skrev:i dette tilfælde er møjfaldet fortjent- ligesåvel som en persom der fortæller om hvor vidunderligt det er at sniffe æther vil få et møgfald.
Tjah.. Jeg har flere gange set stoffer omtalt herinde (hovedsageligt hash), men der har alle ligesom delt erfaringer.
galmok (15) skrev:Dvs. stort hul for regeringen til at lægge spyware ind på din pc.
Hvad har regeringen med DanID at gøre? Jeg troede det var Nets og Nationalbanken der stod bag...
galmok (17) skrev:Og ja, 2-faktor delen kompromiteres en anelse
En anelse? 2-faktor-sikkerheden er helt væk. Idéen er "noget du har, noget du ved". "Du har" et nøglekort, "du ved" dit kodeord. På den her måde bliver sikkerheden til "noget du ved, noget du ved" - altså en 1,1-faktor-sikkerhed.
galmok (23) skrev:Koden repræsenterer simpelthen en værdi for mig. Denne værdi vil nok aftage over tid, men som det er nu er værdien for høj til at jeg ønsker at forære den væk.
Jeg kender det godt. Mine småprogrammer er heller ikke nogen som jeg deler med alle og enhver - af samme grund benytter jeg mig ikke af github.
galmok (23) skrev:Jeg er modstander af at skulle rende rundt med det papkort og var i en situation hvor jeg skulle lave flere logins dagligt [...] Der ligger godt nok flere måneders arbejde i det program med endnu flere måneders arbejde med prototyper i MATLAB.
Nu skal jeg ikke kunne sige om du har anskaffet Matlab før du blev arbejdsløs, men koster det program ikke fra 20.000 kr og opefter?
Alrekr (26) skrev:
Nu skal jeg ikke kunne sige om du har anskaffet Matlab før du blev arbejdsløs, men koster det program ikke fra 20.000 kr og opefter?
MATLAB er meget dyrere end det, men jeg lavede meget af prototypen under mit forrige arbejde hvor jeg havde fuld adgang til MATLAB. Derefter havde jeg kun lejlighedsvist adgang. Siden lavede jeg C++/CLI koden. Godt nok? ;-)
Alrekr (26) skrev:
Hvad har regeringen med DanID at gøre? Jeg troede det var Nets og Nationalbanken der stod bag...
Ja, ok, du har ret, men det gør kun situationen værre. Et privat selskab kan i praksis udgive sig for at være mig på nettet i alle henseender hvor NemID er login. Det sker formodentlig ikke, men vi kan ikke vide det. Og PET har sikkert adgang til at undersøge folks pc'ere skulle de få lyst... (tager sølvpapirshatten af igen). Det er teknisk set muligt.
@galmok:
Du skrev, at det var okay at dekompilere koden, så jeg tog et hurtigt kig. Hvis du er interesseret i konstruktiv kritik, så kunne sikkerheden forbedres markant, hvis du brugte en tilfældig IV i stedet for en statisk. Som det er, er din kryptering sårbar overfor et præberegnings-angreb (a'la rainbow tables). Det ville nok også være en god ide at anvende en key-strengthening-teknik som f.eks. PBKDF2.
Du skrev, at det var okay at dekompilere koden, så jeg tog et hurtigt kig. Hvis du er interesseret i konstruktiv kritik, så kunne sikkerheden forbedres markant, hvis du brugte en tilfældig IV i stedet for en statisk. Som det er, er din kryptering sårbar overfor et præberegnings-angreb (a'la rainbow tables). Det ville nok også være en god ide at anvende en key-strengthening-teknik som f.eks. PBKDF2.
Rasmus Faber (30) skrev:@galmok:
Du skrev, at det var okay at dekompilere koden, så jeg tog et hurtigt kig. Hvis du er interesseret i konstruktiv kritik, så kunne sikkerheden forbedres markant, hvis du brugte en tilfældig IV i stedet for en statisk. Som det er, er din kryptering sårbar overfor et præberegnings-angreb (a'la rainbow tables). Det ville nok også være en god ide at anvende en key-strengthening-teknik som f.eks. PBKDF2.
Jeg ville egentlig gerne gøre IV'en dynamisk, men hvis den er tilfældig, så kan jeg jo ikke dekode hvad jeg krypterer. Men jeg kan udlede den af hardware/software setup og på den måde tilbyde at låse krypteringen til pc'eren. Alternativt skulle IV'en kunne defineres i config filen.
Jeg kender ikke PBKDF2, men vil læse om den ved lejlighed.
#6 (og dem som er interesseret): DanID har kontaktet mig med en service besked og deres vejledning går primært på at jeg bør beskytte mig bedre mod evt. søgsmål hvis folk har mistet penge fordi de har brugt mig program. Det er mest at gøre det endnu tydeligere hvad konsekvensen i sikkerheden er at bruge mit program (2-faktor forsvinder) samt at opfordringen til donationer vil kunne opfattes som om jeg lavede programmet til at tjene penge på det (hvilket jo ikke er tilfældet). DanID's jurister kigger pt. på om der er et problem mht. varemærke så dem hører jeg nok fra hvis der er.
Det er da fin service. Jeg vil nok se om jeg ikke kan gøre noget ved det. :)
Det argument lyder nogenlunde fornuftigt. Det ville nok til dels falde under kategorien "Du forventer at nogen vil finde et sikkerhedshul i din kode". Men du forventer blot at det er danid der udnytter svagheden, og blot at de udnytter den til at lave et DoS angreb imod din software.galmok (23) skrev:En anden årsag er nok også at forhindre DanID i at lure hvordan de kan forhindre mit program i at virke.
Det er security-through obscurity, men hvis den eneste risiko der beskyttes imod er et DoS angreb og ikke en overtagelse af kontrollen med computeren, så er det ikke så stor en trussel.
Udfordringen er så at dokumentere at det eneste der beskyttes imod ved obscurity er DoS angreb af ovenstående type, og at resten af sikkerheden er håndteret på forsvarlig vis. En dokumentation for dette ville nok kræve at der anvendes en sandkasse og den lukkede kode ikke kan forlade sandkassen.
Om danid ville ønske at udnytte nogen svaghed i din kode til at tage kontrol over din computer er tvivlsomt. For det første har de jo allerede kontrol i kraft af de rettigheder du har givet til deres applet (som også dækker fremtidige versioner af appleten, som vi af gode grunde ikke kan vide hvad vil foretage sig).
Hvis du havde fundet en løsning der forhindrer danid i at opnå kontrol over brugernes computere, så ville det have været langt mere interessant. En sådan løsning kunne også hjælpe med at beskytte imod at danid laver et DoS angreb imod din software. På den anden side kunne de måske vælge at lave et DoS angreb der simpelthen forhindrer nemid i at virke, hvis de ikke kan tage kontrol over computeren.
Det ved jeg heller ikke. Jeg vil gå et skridt videre og sige: Jeg ved ikke hvordan man laver et program i Windows.galmok (23) skrev:Jeg ved ikke hvordan man laver et program i windows der kører med færre rettigheder end alle andre programmer.
Havde spørgsmålet derimod gået på Linux, så kan jeg kan jeg beskrive hvordan jeg ville have lavet designet. Jeg vil give beskrivelsen alligevel, for den kan være brugbar som inspiration til andre programmer.
Jeg ville anvende Linux secure computing mode til at placere en del af koden i en sandkasse. Koden udenfor sandkassen skulle så være åben så man kan se at der ikke er nogen bagdør.
Med Linux secure computing kræves der et enkelt systemkald til at aktivere sandkassen:
prctl(PR_SET_SECCOMP,1);
Efter dette kald kan tråden kun gøre fire ting. Læse fra allerede åbne filer, skrive til allerede åbne filer, modtage signaler, afslutte.
Om der findes noget lignende til Windows aner jeg ikke. Jeg prøvede at søge efter "Windows equivalent of PR_SET_SECCOMP", men der var ikke noget der umiddelbart så brugbart ud.
Så kan jeg låne den og begynde at spekulere over om der er en bagdør i deres applet som giver skat mulighed for at overvåge min kommunikation med UBS. De vil jo nok gerne vide hvor meget jeg har stående på min konto i Schweiz.galmok (28) skrev:tager sølvpapirshatten af igen
Det er en ret almindelig fejl at begå. Var det ikke også derfor WEP blev knækket?Rasmus Faber (30) skrev:så kunne sikkerheden forbedres markant, hvis du brugte en tilfældig IV i stedet for en statisk.
IV gemmes i starten af de krypterede data, så det er ikke noget problem.galmok (31) skrev:Jeg ville egentlig gerne gøre IV'en dynamisk, men hvis den er tilfældig, så kan jeg jo ikke dekode hvad jeg krypterer.
Vandborg (32) skrev:Må jeg egentlig spørge om hvad du bruger donationen til?
Som opmuntring til at fortsætte med at udgive nye versioner. ;-)
kasperd (33) skrev:Det argument lyder nogenlunde fornuftigt. Det ville nok til dels falde under kategorien "Du forventer at nogen vil finde et sikkerhedshul i din kode". Men du forventer blot at det er danid der udnytter svagheden, og blot at de udnytter den til at lave et DoS angreb imod din software.
Æh, kan du ikke lige forklare mig hvilket sikkerhedshul der egentlig kan være i det software? Jeg har svært ved at følge din tankegang.
kasperd (33) skrev:
Det er security-through obscurity, men hvis den eneste risiko der beskyttes imod er et DoS angreb og ikke en overtagelse af kontrollen med computeren, så er det ikke så stor en trussel.
Der er ingen netværksfunktionalitet i mit program (det er der jeg normalt vil kunne forstå DoS begrebet).
kasperd (33) skrev:
Udfordringen er så at dokumentere at det eneste der beskyttes imod ved obscurity er DoS angreb af ovenstående type, og at resten af sikkerheden er håndteret på forsvarlig vis. En dokumentation for dette ville nok kræve at der anvendes en sandkasse og den lukkede kode ikke kan forlade sandkassen.
Jeg er stadig blank.
kasperd (33) skrev:
Om danid ville ønske at udnytte nogen svaghed i din kode til at tage kontrol over din computer er tvivlsomt. For det første har de jo allerede kontrol i kraft af de rettigheder du har givet til deres applet (som også dækker fremtidige versioner af appleten, som vi af gode grunde ikke kan vide hvad vil foretage sig).
DanID har allerede kontrol over din pc hver gang du viser NemID java applikationen i din browser. De kører native eksekverbare filer uden din viden med et indhold de ikke vil fortælle om. Jeg fortæller i det mindste hvad mit program gør (og ikke gør).
kasperd (33) skrev:
Hvis du havde fundet en løsning der forhindrer danid i at opnå kontrol over brugernes computere, så ville det have været langt mere interessant. En sådan løsning kunne også hjælpe med at beskytte imod at danid laver et DoS angreb imod din software. På den anden side kunne de måske vælge at lave et DoS angreb der simpelthen forhindrer nemid i at virke, hvis de ikke kan tage kontrol over computeren.
Hvad er det for en service de kunne lave at angreb på?
kasperd (33) skrev:Det ved jeg heller ikke. Jeg vil gå et skridt videre og sige: Jeg ved ikke hvordan man laver et program i Windows.galmok (23) skrev:Jeg ved ikke hvordan man laver et program i windows der kører med færre rettigheder end alle andre programmer.
Havde spørgsmålet derimod gået på Linux, så kan jeg kan jeg beskrive hvordan jeg ville have lavet designet. Jeg vil give beskrivelsen alligevel, for den kan være brugbar som inspiration til andre programmer.
Jeg ville anvende Linux secure computing mode til at placere en del af koden i en sandkasse. Koden udenfor sandkassen skulle så være åben så man kan se at der ikke er nogen bagdør.
Med Linux secure computing kræves der et enkelt systemkald til at aktivere sandkassen:
prctl(PR_SET_SECCOMP,1);
Efter dette kald kan tråden kun gøre fire ting. Læse fra allerede åbne filer, skrive til allerede åbne filer, modtage signaler, afslutte.
Om der findes noget lignende til Windows aner jeg ikke. Jeg prøvede at søge efter "Windows equivalent of PR_SET_SECCOMP", men der var ikke noget der umiddelbart så brugbart ud.
Det lyder ellers smart! Det vidste jeg ikke Linux kunne. Jeg har ikke hørt om sådan noget til windows.
kasperd (33) skrev:Det er en ret almindelig fejl at begå. Var det ikke også derfor WEP blev knækket?Rasmus Faber (30) skrev:så kunne sikkerheden forbedres markant, hvis du brugte en tilfældig IV i stedet for en statisk.IV gemmes i starten af de krypterede data, så det er ikke noget problem.galmok (31) skrev:Jeg ville egentlig gerne gøre IV'en dynamisk, men hvis den er tilfældig, så kan jeg jo ikke dekode hvad jeg krypterer.
Det er selvfølgelig også en mulighed... har arbejdet med saltede passwords og dette er jo i princippet det samme. Vil se om jeg kan gemme IV'en et eller andet sted i de krypterede data. Det vil dog ikke rigtig ændre det store da man blot kan decompile mit program og se hvordan IV'en pilles ud. Så der vindes ikke det store.
Det var dig selv der startede med at foreslå muligheden.galmok (34) skrev:Æh, kan du ikke lige forklare mig hvilket sikkerhedshul der egentlig kan være i det software? Jeg har svært ved at følge din tankegang.
Det kan vi så ikke vide med mindre vi har kildekoden eller synes det er værd at bruge tiden på at reverse engineer det hele. Hvis ingen sandkasse der er, så er man jo nødt til at reverse engineer hver eneste byte af koden.galmok (34) skrev:Der er ingen netværksfunktionalitet i mit program
Betegnelsen DoS dækker ethvert angreb der kan forhindre hardware eller software i at opfylde dets funktion. Det behøver ikke nødvendigvis involvere netværkstrafik. Hvis du kan konstruere en datafil der får et program til at gå ned, så er det også et DoS angreb.galmok (34) skrev:det er der jeg normalt vil kunne forstå DoS begrebet
Det argument ville kun kunne bruges til noget hvis man havde valget mellem at enten bruge appleten eller bruge din kode. Hvis ikke man har det valg kan det jo være lige meget om du synes du kan præstere en højere standard end danids. Der skal ikke ret meget til for at præstere en højere standard end danid. At danid overhovedet kan slippe afsted med det de gør skyldes at nogen har valgt at give dem monopol på området.galmok (34) skrev:DanID har allerede kontrol over din pc hver gang du viser NemID java applikationen i din browser. De kører native eksekverbare filer uden din viden med et indhold de ikke vil fortælle om. Jeg fortæller i det mindste hvad mit program gør (og ikke gør).
Selv hvis man havde mulighed for at vælge mellem din software og danids software, så er du stadig nødt til at præstere en meget højere standard fordi man står med valget mellem software fra en tilfældig ukendt person på den ene hånd og software fra en virksomhed med opbakning fra samtlige pengeinstitutter i Danmark på den anden hånd. Du har et dårlige udgangspunkt, derfor er der større krav til dig for at opnå troværdighed end der er til danid.
At du overhovedet kan stille sådan et spørgsmål er faktisk bevis for at du ikke er den rette person til at skrive software til at håndtere kryptering. Jeg vil råde dig til at enten bruge et par år på at lære grundprincipperne i kryptologi eller bruge et af de softwarebiblioteker der er skrevet af personer som har.galmok (34) skrev:Vil se om jeg kan gemme IV'en et eller andet sted i de krypterede data.
kasperd (35) skrev:At du overhovedet kan stille sådan et spørgsmål er faktisk bevis for at du ikke er den rette person til at skrive software til at håndtere kryptering. Jeg vil råde dig til at enten bruge et par år på at lære grundprincipperne i kryptologi eller bruge et af de softwarebiblioteker der er skrevet af personer som har.
Jeg indrømmer da gerne jeg ikke har den store erfaring med 3DES kryptering, men har implementeret det som Microsoft selv foreslår man går. Men siden det lader til at du ved præcist hvordan man gør så kan du evt. give mig en pointer? Eller larmer du bare?
galmok (36) skrev:Jeg indrømmer da gerne jeg ikke har den store erfaring med 3DES kryptering, men har implementeret det som Microsoft selv foreslår man går. Men siden det lader til at du ved præcist hvordan man gør så kan du evt. give mig en pointer? Eller LARMER du bare?
Tror lige du skal læse et par af kasperd indlæg....
Tripple-DES er også en forældet algoritme. En blokstørrelse på 64 bits er for lidt.galmok (36) skrev:Jeg indrømmer da gerne jeg ikke har den store erfaring med 3DES kryptering
Der findes ganske få situationer, hvor man har brug for en specifik blokstørrelse, og derfor kunne have brug for en med en størrelse på 64 bits. Det du beskriver er ikke en af de situationer.
Du har brug for en blokstørrelse på 128 bits. En blokstørrelse på 128 bits er ingen garanti for at du ikke får problemer. Men jeg vil godt garantere, at hvis du vælger en blokstørrelse på 128 bits, så bliver en for lille cipherblok ikke det første problem du får.
Jeg tror ikke på at Microsoft foreslår at man selv implementerer den slags. Det du har brug for er et library, der arbejder på så højt niveau, at din kode aldrig selv skal tage stilling til valg af cipher, valg af mode, generering af IV, etc.galmok (36) skrev:men har implementeret det som Microsoft selv foreslår man går
Så vidt jeg husker blev der nævnt noget om det i [url= video[/url], men jeg har ikke tid til at se den igennem lige nu for at checke at det var netop den video.
Apropos det spørgsmål, så fandt jeg ud af at nemid ikke kan køre hvis /tmp er mountet med noexec.kasperd (33) skrev:På den anden side kunne de måske vælge at lave et DoS angreb der simpelthen forhindrer nemid i at virke, hvis de ikke kan tage kontrol over computeren.
Pally (38) skrev:Bare for at være en lille smule behjælpelig (det må man godt være af og til):
Givet data, så
Lav en random IV
Krypter data med nøgle og IV
Gem: IV | Enc(K, IV, data)
Alle data har nu deres egen IV og du kan dekryptere lige så tosset du vil.
Jeg har nu en fungerende version (ikke lagt op endnu) med denne teknik. Men det ser ikke ud til at .NET understøtter 3DES med en IV-blockstørrelse på andet end 64 bit. Jeg har kigget lidt på AES men den ser heller ikke lovende ud. Noget bud på hvilken krypteringsstandard i .NET pakken jeg bør brug?
DES, 3DES og DESX har altid en blokstørrelse på 64 bits. Det eneste der varierer er nøglestørrelsen.galmok (41) skrev:Men det ser ikke ud til at .NET understøtter 3DES med en IV-blockstørrelse på andet end 64 bit.
AES 128 bits. Med AES er blokstørrelsen altid 128 bits, nøglestørrelsen kan vælges til 128, 192 eller 256. Dog er der fundet svagheder ved de større nøgler, så jeg vil anbefale at man holder sig til 128 bits nøgler med mindre man har meget specifikke behov.galmok (41) skrev:Noget bud på hvilken krypteringsstandard i .NET pakken jeg bør brug?
Valget af krypteringsmode er lidt sværere at besvare da der er mange fornuftige kandidater. Uden at vide hvilke modes der er understøttet af det library du anvender kan jeg ikke sige hvad der er det bedste valg.
Lad være med at bruge ECB.
OFB og CTR mode bør man holde sig fra hvis ikke man ved præcist hvad man gør fordi de nemt kan bruges forkert og underminere sikkerheden i krypteringen. WEP standarden er et godt eksempel på hvad der kan gå galt.
CBC er understøttet af det meste software. Det er et nogenlunde fornuftigt valg, hvis blot man sikrer sig at man bruger et tilfældigt IV. Dårlige valg af IV kan svække sikkerheden af CBC, men CBC med et dårligt IV er langt stærkere end OFB eller CTR ville være med et dårligt IV.
Der er to punkter hvor en cipher mode kan gøres bedre end CBC. For det første findes der modes som stiller færre krav til IV end CBC gør. Derudover er det en god idé at anvende en authenticated encryption mode. Ingen af de modes jeg har nævnt indtil er authenticated. Det største problem med authenticated encryption er at der er for mange modes at vælge mellem, og der vist ikke er konsensus omkring en standard mode for authenticated encryption.
Det er nemmer at vælge en god authenticated encryption mode, hvis man ved hvad der understøttes af den software man anvender.
kasperd (42) skrev:
AES 128 bits.
Det er bare når jeg læser wiki siden om AES så er den ret så sårbar overfor side-channel angreb (et par sætninger fra wiki):
One attack was able to obtain an entire AES key after only 800 operations triggering encryptions, in a total of 65 milliseconds.
In November 2010 Endre Bangerter, David Gullasch and Stephan Krenn published a paper which described a practical approach to a "near real time" recovery of secret keys from AES-128 without the need for either cipher text or plaintext.
Når jeg læser dette, så er AES ikke lige det bedste valg. AES er da også udviklet til ikke at bruge ret meget hukommelse og til at være hurtig. Til mit brug er det modsatte nærmere ønskeligt (specielt det at være langsomt er nice da det begrænser bruteforce muligheden).
Jeg vil se på nogle af de andre ting du nævnte, men hvis .NET ikke understøtter det, så bliver det nok ikke overvejet så meget. Tak for info. :)
prøv lige at læs op på http://en.wikipedia.org/wiki/Side_channel_attack og stil dig selv spørgsmålet: Spiller det ind til dette brug?
Det er da langt at gå for at få adgang til NemID informationen, men det gør da stadig AES sårbar. 3DES er sårbar overfor samme slags angreb. Men når man så tager dit spørgsmål med i billedet så gør forskellem mellem 3DES og AES128 nok heller ikke rigtig nogen forskel.
Nej, min pointe var at side channel attacks kræver at man har mulighed for at måle på strømmen, cpubrug, varme eller EMG.
Hvis at der er en der har adgang til de informationer har han sku nok også adgang til at optage dine keystrokes.
Side channel attacks er irrelevante!
Hvis at der er en der har adgang til de informationer har han sku nok også adgang til at optage dine keystrokes.
Side channel attacks er irrelevante!
galmok (43) skrev:Jeg vil se på nogle af de andre ting du nævnte, men hvis .NET ikke understøtter det, så bliver det nok ikke overvejet så meget. Tak for info. :)
Så bruger du bare cryptoapi32 og Interop!
Cachetiming er nok det angreb man bør være mest bekymret om i denne henseende. Hvis cachetiming kan implementeres i javascript er det en reel trussel.Mamad (moveax1ret) (46) skrev:Nej, min pointe var at side channel attacks kræver at man har mulighed for at måle på strømmen, cpubrug, varme eller EMG.
Men sidechannels er i høj grad et implementationsspørgsmål og i mindre grad et spørgsmål om designet af selve cipheren.
Så i stedet for at skifte fra AES til en svagere cipher, så bør du i stedet finde ud af om den AES implementation du anvender er sikret imod angrebet, og hvis ikke, så må du oprette en bugrapport på den software.
I både DES og AES er det oplagt at bruge tabelopslag, og dermed kan begge være sårbare overfor cachetiming.
Det er nok på tide med en ny krypteringsstandard til at afløse AES. Jeg er af den opfattelse at det eneste der bør ændres er den keyschedule der anvendes i AES. Resten af algoritmen kan vi sandsynligvis bruge i mange år endnu.
Alle de angreb jeg har hørt om imod AES har i en eller anden udstrækning udnyttet den meget simple struktur i AES keyschedule.
Afbildningen fra nøgle til keyschedule bør være pseudotilfældig. Hvis den var det ville det eliminere mange angreb, og mig bekendt ville det eliminere alle kendte angreb imod AES.
Jeg ville personligt hente inspiration fra blowfish. I blowfish ittereres blockcipheren selv adskillige gange for at konstruere keyschedule.
Men alt dette skal man ikke tænke på når man designer applikationer. Man skal hellere designe sin applikation således at man med en simpel indstilling i opsætningen kan vælge mellem alle de ciphers der er tilgængelige i det cryptolibrary man anvender. Og så overlad valget af cipher til udviklerne af det cryptolibrary, da de som regel har mere forstand på det end udviklere af applikationer.
tror du virkeligt at cache timing der skal fortolkes af javascript motoren kan måle på data der kører i en seperat process?
Jeg tvivler stærkt........
Mit umiddelbare indtryk er at det først spiller ind hvis man deler shells på en server, og selv der er det meget teoretisk.
Husk på, dekrypteringen sker jo kun én gang ved denne applikation, og man kan ikke vide præcist hvornår.
Jeg tvivler stærkt........
Mit umiddelbare indtryk er at det først spiller ind hvis man deler shells på en server, og selv der er det meget teoretisk.
Husk på, dekrypteringen sker jo kun én gang ved denne applikation, og man kan ikke vide præcist hvornår.
Jeg tvivler, men det ville være den nemmeste måde at få kode til at køre på samme maskine. Der er andre metoder. Et andet spørgsmål er om native kode i en sandkasse kan foretage målingerne.Mamad (moveax1ret) (49) skrev:tror du virkeligt at cache timing der skal fortolkes af javascript motoren kan måle på data der kører i en seperat process?
Hvis ikke man tager højde for muligheden for et angreb udført af en anden bruger på samme maskine, så har man ikke gjort nok for at sikre sig.Mamad (moveax1ret) (49) skrev:Mit umiddelbare indtryk er at det først spiller ind hvis man deler shells på en server, og selv der er det meget teoretisk.
Hvor nemt det så er at udføre angrebet når man er på maskinen på det rigtige tidspunkt ved jeg ikke. Jeg har ikke selv afprøvet cachetiming angreb.
En process i baggrunden som holder øje med hvornår der åbnes en TCP forbindelse til danid vil ikke kræve ret mange resourcer. Derefter ved man ikke præcist hvor lang tid der går før dekrypteringen vil foregå, men der går nok ikke mange minutter, og man kan blot lade angrebet køre i hele den periode.Mamad (moveax1ret) (49) skrev:Husk på, dekrypteringen sker jo kun én gang ved denne applikation, og man kan ikke vide præcist hvornår.
Der sker godt nok kun en dekryptering, men den dekryptering vil bestå af flere blokke.
Et fuldstændigt teoretisk scenarie er det ikke. Men man skal ikke vælge cipher udfra hvilken cipher der tilfældigvis bliver nævnt i artikler om sidechannel angreb. Så længe der ikke er research som påviser at angrebene er mere effektiv imod nogle ciphers end imod andre er det ikke dette der afgør hvad der er det bedste valg af cipher.
Og det er stadigvæk et implementationsspørgsmål. Og det er den slags subtile detaljer omkring implementation af ciphers som gør at man bør anvende libraries fremfor at selv implementere ciphers i sin applikation.
Hvis der viser sig en svaghed i et cryptolibrary, så er det nok at opdatere det library, og så vil det være rettet i alle de applikationer, der anvender det library. Og hvis det viser sig at en cipher er blevet brudt, så kan applikationerne konfigureres til at bruge en anden. Et fornuftigt library har også en metode til at konfigurere et default valg af cipher for alle applikationer, som ikke selv har en metode til det.
Hvis du skriver en applikation til Windows og det viser sig at der er en svaghed pga. en fejl i et library fra Microsoft som du anvendte, så kommer du næppe til at skulle stå til ansvar for den svaghed. Ved at vælge Windows er du allerede afhængig af sikkerheden i Microsofts software, så om du er afhængig af deres cryptolibrary også gør ikke den store forskel.
Hvis du bruger Windows men selv skriver din cryptokode, så er der stor risiko for at du introducerer en svaghed i den kode. Selv hvis det skulle lykkes dig at undgå fejl i din egen kode, så er du sikkert stadig udsat hvis der skulle vise sig fejl i Microsofts cryptolibrary fordi andre applikationer på systemet bruger det.
Kort sagt, brug et cryptolibrary og sørg for at applikationen kan konfigureres til at bruge forskellige ciphers, med et fornuftigt default valg. Lad være med at bekymre dig om implementationsfejl i cipheren. Du kan lige så godt antage at hvis der viser sig et sikkerhedshul i cipheren, så kommer der rettelse ud som en opdatering uden applikationen behøver at gøre noget for det. Hvis den antagelse ikke holder, så har man alligevel større problemer.
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
- ⟨
- Software
Gå til bund