mboost-dp1
Brug udenlandsk bank for at slippe for NemID?
#48
Bare rolig- du falder ikke under den kategori- du har din helt egen kategori.
Hvis du nu bare kørte din asshole stil helt ud så kan det være at jeg faktisk godt ville kunne lide dig.
Men når du samtidigt virker så desperat efter at virke som en badass og vil bruge tid på at tage billeder og lave beviser for at du besidder det job du påstår.
Bare rolig- du falder ikke under den kategori- du har din helt egen kategori.
Hvis du nu bare kørte din asshole stil helt ud så kan det være at jeg faktisk godt ville kunne lide dig.
Men når du samtidigt virker så desperat efter at virke som en badass og vil bruge tid på at tage billeder og lave beviser for at du besidder det job du påstår.
#50
Sorry, denne diskussion angående nemID har bare kørt så længe at jeg ikke gider andet end at opsummere.
Jeg har argumenteret, jeg har diskuteret, jeg har rettet på folk når de tager fejl, jeg er blevet rettet ind når jeg har taget fejl(myspacedk)
Jeg gider ikke mere- der er nogle folk der bare VIL hade nemID uanset hvad.
Og de er bare ikke generelt dem der ved noget om kryptografi/kryptoanalyse- sådan er det bare.
Sorry, denne diskussion angående nemID har bare kørt så længe at jeg ikke gider andet end at opsummere.
Jeg har argumenteret, jeg har diskuteret, jeg har rettet på folk når de tager fejl, jeg er blevet rettet ind når jeg har taget fejl(myspacedk)
Jeg gider ikke mere- der er nogle folk der bare VIL hade nemID uanset hvad.
Og de er bare ikke generelt dem der ved noget om kryptografi/kryptoanalyse- sådan er det bare.
I starten var jeg faktisk også imod nemID- alene det at man ikke selv opbevarer sin rsa private nøgle fik mig til at gyse.
Men efter jeg har fået fuld forståelse for nemID giver det hele faktisk mening.
Hvert eneste argument mod nemID falder bare lynhurtigt til jorden hvis man ved noget om hvordan tingene fungerer.
Men vi kan da godt lige tage dem jeg erindrer er nævnt i denne tråd.
Passwords er ikke case sensitive: Det har jeg svaret på, tilføj flere karakterer hvis det generer dig.
Den anden ting jeg husker var at en medarbejder i en bank forbandt en forkert brugerprofil på en person der tilfældigtvis brugte nemID til sin netbank.
Det har slet ingenting med nemID at gøre........WTF?
Det kan kun køre med Java: Jaja, det er da trælst, men Java er virkeligt godt supporteret på alle større arkitekturer og operativ systemer. Dog ved jeg at der er problemer med JRE's fra andre producenter end SUN. Det er kritisabelt- det synes jeg også. Men det kan jo fikses.
Men efter jeg har fået fuld forståelse for nemID giver det hele faktisk mening.
Hvert eneste argument mod nemID falder bare lynhurtigt til jorden hvis man ved noget om hvordan tingene fungerer.
Men vi kan da godt lige tage dem jeg erindrer er nævnt i denne tråd.
Passwords er ikke case sensitive: Det har jeg svaret på, tilføj flere karakterer hvis det generer dig.
Den anden ting jeg husker var at en medarbejder i en bank forbandt en forkert brugerprofil på en person der tilfældigtvis brugte nemID til sin netbank.
Det har slet ingenting med nemID at gøre........WTF?
Det kan kun køre med Java: Jaja, det er da trælst, men Java er virkeligt godt supporteret på alle større arkitekturer og operativ systemer. Dog ved jeg at der er problemer med JRE's fra andre producenter end SUN. Det er kritisabelt- det synes jeg også. Men det kan jo fikses.
moveax1ret (51) skrev:#48
Bare rolig- du falder ikke under den kategori- du har din helt egen kategori.
Hvis du nu bare kørte din asshole stil helt ud så kan det være at jeg faktisk godt ville kunne lide dig.
Men når du samtidigt virker så desperat efter at virke som en badass og vil bruge tid på at tage billeder og lave beviser for at du besidder det job du påstår.
Har du andet end fallcies?
Terra - For lige nu beviser du bare min pointe...
#57
Det er kun fordi du er lidt nuttet på sådan en pisseirreterende måde.
Men ja du har ret- jeg har løjet, det jeg mente var at jeg ikke vil spilde MERE tid på dig.
Og det starter fra nu af :)
Det er kun fordi du er lidt nuttet på sådan en pisseirreterende måde.
Men ja du har ret- jeg har løjet, det jeg mente var at jeg ikke vil spilde MERE tid på dig.
Og det starter fra nu af :)
Det system Jyske Bank anvendte før i tiden har virket på alle de computere jeg har haft siden jeg skiftede til Jyske Bank i starten af 2004. Jeg valgte netop Jyske Bank fordi de havde en netbank der virkede så godt. Nu hvor Jyske Bank har valgt at gå over til en dårligere løsning skiller de sig ikke længere ud som den bedste bank på dette punkt.JesperZ (44) skrev:Før i tiden var der aldrig noget der virkede alle steder.
Hvis der var en bank som ville indføre en bedre løsning end nemid, så ville de kunne tiltrække kunder fra andre banker på samme måde som Jyske Bank tiltrak kunder før nemid blev indført.
3214N (59) skrev:Så kan vi måske dreje tråden over på spørgsmålet vedr. en udenlandsk netbank, som man som bosiddende i DK kan få adgang til, og på den måde slippe for NEMID?
Hvis du tænker på lønkonto, så glemt det. Hver gang du modtager fra, eller sender til, danske konti, kommer du til at betale for veksling af valuta.
Hvis det er en (større) opsparing er jeg sikker på at banker i Schweiz eller Luxemborg kan hjælpe.
Når det så er sagt forstår jeg ikke hvorfor du overhovedet overvejer det. Nemid er ligeså nemt(eller besværligt) som de sikre løsninger var inden det kom. Eneste problem for nogle er at det bruger java, men der er jo halve løsninger på det allerede nu, og hele løsninger på vej.
kasperd (43) skrev:Det problem kan løses ved at lade brugerne vælge den løsning de foretrækker i stedet for at tvinge alle til at bruge den samme løsning. Før i tiden var der et stort nok udbud af forskellige løsninger, til at de fleste kunne finde en løsning de ville være tilfreds med.
Flere løsninger er dyrere. Og hvis jeg skulle betale for dem, ville jeg være utilfreds.
Jeg skal ikke (nødvendigvis) bruge en lønkonto på en ny netbank, Jeg kan beholde min nuværende. Jeg mangler bare en netbank, så jeg kan betale girokort og overføre til andre konti. Det gør ikke noget at der er et gebyr for veksling.
Det må gerne være en erhvervsløsning, bare det ikke forhindrer mig i at betale ikke-firma-regninger.
Mit problem er at jeg ikke stoler på NemID, og at det er usikkert. Der var i min mening, ikke noget besværligt i det gamle system. Principielt er jeg imod at jeg har betalt for en vare, som leverandøren efterfølgende begrænser mig i at bruge, uden at jeg selv kan bruge en alternativ løsning.
De/vi kunne have sparet mange penge, ved aldrig at have påbegyndt NemID.
Why fix it, if it ain't broken?
Det må gerne være en erhvervsløsning, bare det ikke forhindrer mig i at betale ikke-firma-regninger.
Mit problem er at jeg ikke stoler på NemID, og at det er usikkert. Der var i min mening, ikke noget besværligt i det gamle system. Principielt er jeg imod at jeg har betalt for en vare, som leverandøren efterfølgende begrænser mig i at bruge, uden at jeg selv kan bruge en alternativ løsning.
De/vi kunne have sparet mange penge, ved aldrig at have påbegyndt NemID.
Why fix it, if it ain't broken?
3214N (62) skrev:
Jeg skal ikke (nødvendigvis) bruge en lønkonto på en ny netbank, Jeg kan beholde min nuværende. Jeg mangler bare en netbank, så jeg kan betale girokort og overføre til andre konti. Det gør ikke noget at der er et gebyr for veksling.
Det må gerne være en erhvervsløsning, bare det ikke forhindrer mig i at betale ikke-firma-regninger.
Hvis ikke du du flytter en opsparing med, tror jeg ikke det bliver svært at finde en udenlandsk bank der vil have dig som kunde.
3214N (62) skrev:
Mit problem er at jeg ikke stoler på NemID, og at det er usikkert. Der var i min mening, ikke noget besværligt i det gamle system. Principielt er jeg imod at jeg har betalt for en vare, som leverandøren efterfølgende begrænser mig i at bruge, uden at jeg selv kan bruge en alternativ løsning.
Nu har jeg selv brugt Danske Banks ActivCard og Jyske Banks nøglekort. Danske Banks løsning var IMO mere besværlig Nemid, mens Jyske Banks minder ret meget om Nemid. De eneste løsninger der var nemmere var dem hvor man havde en nøglefil, men de var ikke ligefrem sikre. Det eneste problem jeg ser med Nemid er at login bruger en Java applet.
3214N (62) skrev:
De/vi kunne have sparet mange penge, ved aldrig at have påbegyndt NemID.
Nemid er en investering, det koster en del i starten, men vil på lang sigt spare penge.
3214N (62) skrev:
Why fix it, if it ain't broken?
Det var det (nøglefilsløsningerne): link.
Det ville stå dig frit for at vælge den bank der brugte den billigste løsning. Men dit ønske om en billig løsning skal ikke forhindre resten af befolkningen i at vælge netbankløsning udfra et andet kriterie end prisen.Killa (61) skrev:Flere løsninger er dyrere. Og hvis jeg skulle betale for dem, ville jeg være utilfreds.
Vi er gået fra en situation hvor der har været en fri konkurrence imellem forskellige løsninger til den nuværende situation, hvor en enkelt løsning til netbanklogins har monopol på hele det danske marked.
terracide (48) skrev:#47:
Pæn fallacy.
Jeg har lagt mærke til at folk hvis bruger navn starter med "move" virker utroligt uintelligente, ofte er homosexuelle, kan lide sex med små børn og æder deres egen fæces.
Terra - Get the point?
Har du noget imod homoseksuelle, siden de skal sidestilles med åndssvage, pædofile og fæcesfile? Eller er din hjerne bare et sort hul?
moveax1ret (47) skrev:Folk der ikke kan lide nemID er ofte folk der virker utroligt uinformerede indenfor IT, kryptografi og matematik.
Jeg har selv gjort ca. samme observation. Eller mere korrekt: Argumenterne imod NemID er ofte rigtigt dårlige, typisk baseret på misforståelser.
Jeg har opgivet at forklare. Folk som faktisk er interesseret må for pokker have forstået det efterhånden, eller i det mindste forstået konceptet i at overlade sikkerheden til folk der har forstand på det.
moveax1ret (52) skrev:(myspacedk)
myPLACEdk
moveax1ret (53) skrev:Det kan kun køre med Java: Jaja, det er da trælst, men Java er virkeligt godt supporteret på alle større arkitekturer og operativ systemer.
Husk at det ikke bare at Java, men Java-applets. Det udelukker hele den mobile platform. Stort set alle mobiltelefoner, PDA'er, tablets (uden desktop-OS)...
Godt nok er de på vej med en løsning til det, men den kommer alt for langsomt. Det ses jo tydeligt ved at bankerne begyndte at lave grumme hacks for at bruge det bare lidt på mobilerne, på trods af at de aftalte i starten at de ikke ville gøre det.
Desuden vil jeg tro at den løsning kun kommer til at virke på ting som er rettet mod netop den mobile platform. Jeg kan nu ellers godt lide muligheden for at bruge desktop-versionen på min mobiltelefon.
Fedt at have en tablet som fint kan klare den fulde netbank, men pga. den applet er begrænset til en primitiv mobilbank. Fneh.
#53
Du argumenterer for at NemID er "godt nok", ved at "fikse" alle de basale fejl de har lavet?
What the fluffle?! :)
1) non-case sensitive? Hvorfor? Det giver ingen mening. Det er bare retarderet.
Jaja, du kan bare tilfoeje 117 tegn til din kode, men hvorfor dog goere det naar "DiNM0R323" er ligesaa godt som "dinmor323232323232233232323" ? :)
2)
OK, lesson number one:
UNDERSTOETTET. FFS :)
Og nej.
Det er en Java-Applet. Det er ikke "ren" Java. Og det er ikke et argument for at vaelge Java, naar det saa absolut ikke er noedvendigt!
De kunne ogsaa have leveret en .NET loesning, det ville vaere ligesaa forkert.
Det kunne laves 100% serverside og du har reelt ikke nogen fordel i at bruge Java applet'en overhovedet.
Logfilerne de paastaar at gemme hjaelper naeppe naar de skal til at trevle MorphOS og AmiWeb igennem, vel?
Pointen er, at havde de lavet det 100% serverside, saa ville loggen hos brugeren ikke vaere relevant, da du har langt faerre risikofaktorer.
Du argumenterer for at NemID er "godt nok", ved at "fikse" alle de basale fejl de har lavet?
What the fluffle?! :)
1) non-case sensitive? Hvorfor? Det giver ingen mening. Det er bare retarderet.
Jaja, du kan bare tilfoeje 117 tegn til din kode, men hvorfor dog goere det naar "DiNM0R323" er ligesaa godt som "dinmor323232323232233232323" ? :)
2)
Det kan kun køre med Java: Jaja, det er da trælst, men Java er virkeligt godt supporteret på alle større arkitekturer og operativ systemer.
OK, lesson number one:
UNDERSTOETTET. FFS :)
Og nej.
Dog ved jeg at der er problemer med JRE's fra andre producenter end SUN. Det er kritisabelt- det synes jeg også. Men det kan jo fikses.
Det er en Java-Applet. Det er ikke "ren" Java. Og det er ikke et argument for at vaelge Java, naar det saa absolut ikke er noedvendigt!
De kunne ogsaa have leveret en .NET loesning, det ville vaere ligesaa forkert.
Det kunne laves 100% serverside og du har reelt ikke nogen fordel i at bruge Java applet'en overhovedet.
Logfilerne de paastaar at gemme hjaelper naeppe naar de skal til at trevle MorphOS og AmiWeb igennem, vel?
Pointen er, at havde de lavet det 100% serverside, saa ville loggen hos brugeren ikke vaere relevant, da du har langt faerre risikofaktorer.
#68
1)
Det er en to faktor løsning- case insetivitet er i praksis 100% ligegyldigt.
2)
Jaja, jeg tænkte på det engelske ord- supported
At vælge at lave så meget som det er client side i java giver altså god mening.
De har valgt en model hvorat enhver kan blive danid partner og tjenesteudbyder.
De har en snitflade der hedder input xml, appletten sender det til danids servere, og du får signeret xml tilbage, hvilket er dejligt rent at kode opimod.
Hvis enhver skulle kunne lave en serverside løsning skulle det kodes til alle serverside sprog/arkitekturer. Eller de kunne lave noget klodset iframe hack- hvilket er et mareridt at supportere i alle browsere.
Det er dejligt med java at hvis java kan starte i en sun JRE så virker tæt på alting.
En anden ting jeg kan forestille mig har været med i deres overvejelser er at det er dejligt nemt at hurtigt finde 40 java konsulenter.
Det er nogle af de tng jeg kan forestille mig har været med i deres overvejelser- hvad siger du myplace.dk ?
1)
Det er en to faktor løsning- case insetivitet er i praksis 100% ligegyldigt.
2)
Jaja, jeg tænkte på det engelske ord- supported
At vælge at lave så meget som det er client side i java giver altså god mening.
De har valgt en model hvorat enhver kan blive danid partner og tjenesteudbyder.
De har en snitflade der hedder input xml, appletten sender det til danids servere, og du får signeret xml tilbage, hvilket er dejligt rent at kode opimod.
Hvis enhver skulle kunne lave en serverside løsning skulle det kodes til alle serverside sprog/arkitekturer. Eller de kunne lave noget klodset iframe hack- hvilket er et mareridt at supportere i alle browsere.
Det er dejligt med java at hvis java kan starte i en sun JRE så virker tæt på alting.
En anden ting jeg kan forestille mig har været med i deres overvejelser er at det er dejligt nemt at hurtigt finde 40 java konsulenter.
Det er nogle af de tng jeg kan forestille mig har været med i deres overvejelser- hvad siger du myplace.dk ?
#69
Aha, jamen saa er passwordet vel ogsaa 100% ligegyldigt?
Hvordan vil du dsikutere kryptografi og sikkerhed i et to-faktor system, naar du paastaar at sikkerheden i foerste faktor er ligegyldig?
Nej, det goer det ikke.
Der er faktisk ingen reel grund til at goere det.
"Enhver"?
Dette har intet med valget af Java at goere.
Det kraever stadig ikke en JavaApplet og hvis det er eneste argument, saa er det direkte retarderet.
Nej.
Det er en browserbaseret loesning. Det du snakker om har intet med Java at goere.
Dertil kommer saa, at du vil bruge auth via XML som du magisk skal koere via en Java Applet?
Du kan sende XML med brevduer hvis du har lyst.
Really?
De kunne ogsaa have haandteret Auth serverside.
Faktisk er det ligenetop det de har gjort i min AlBank iPhone App, saavidt jeg kan se.
Jeg kan godt lide din vage formulering her. Havde du fjernet "taet paa", saa var det direkte loegn.
Alene det at Java tydeligvis ikke virker specielt godt i #1s situation, samt at Java slet ikke findes paa flere mobilOS og ioevrigt at SUN ikke leverer til alle platforme, etc, goer at Java bare er ENDNU et platformsafhaengigt lag, som ioevrigt er unoedvendigt.
... 40 .... Java konsulenter?
Hvad skulle det hjaelpe?
Saa kan NemID siger "Det er ikke Java der er problemet", naar jeg ringer efter support paa MorphOS eller hvad?
Han siger nok "Din mor er grim"? Hvad med at forholde dig til debatten her?
Du har endnu ikke givet noget argument der goer at NemID er designet rigtigt, tvaertimod det modsatte. Der er slaekket paa sikkerhedsmodellen og implementationsmuligheder af ulogiske aarsager.
Det er bare dumt.
Det er en to faktor løsning- case insetivitet er i praksis 100% ligegyldigt.
Aha, jamen saa er passwordet vel ogsaa 100% ligegyldigt?
Hvordan vil du dsikutere kryptografi og sikkerhed i et to-faktor system, naar du paastaar at sikkerheden i foerste faktor er ligegyldig?
At vælge at lave så meget som det er client side i java giver altså god mening.
Nej, det goer det ikke.
Der er faktisk ingen reel grund til at goere det.
De har valgt en model hvorat enhver kan blive danid partner og tjenesteudbyder.
"Enhver"?
Dette har intet med valget af Java at goere.
De har en snitflade der hedder input xml, appletten sender det til danids servere, og du får signeret xml tilbage, hvilket er dejligt rent at kode opimod.
Det kraever stadig ikke en JavaApplet og hvis det er eneste argument, saa er det direkte retarderet.
Hvis enhver skulle kunne lave en serverside løsning skulle det kodes til alle serverside sprog/arkitekturer.
Nej.
Det er en browserbaseret loesning. Det du snakker om har intet med Java at goere.
Dertil kommer saa, at du vil bruge auth via XML som du magisk skal koere via en Java Applet?
Du kan sende XML med brevduer hvis du har lyst.
Eller de kunne lave noget klodset iframe hack- hvilket er et mareridt at supportere i alle browsere.
Really?
De kunne ogsaa have haandteret Auth serverside.
Faktisk er det ligenetop det de har gjort i min AlBank iPhone App, saavidt jeg kan se.
Det er dejligt med java at hvis java kan starte i en sun JRE så virker tæt på alting.
Jeg kan godt lide din vage formulering her. Havde du fjernet "taet paa", saa var det direkte loegn.
Alene det at Java tydeligvis ikke virker specielt godt i #1s situation, samt at Java slet ikke findes paa flere mobilOS og ioevrigt at SUN ikke leverer til alle platforme, etc, goer at Java bare er ENDNU et platformsafhaengigt lag, som ioevrigt er unoedvendigt.
En anden ting jeg kan forestille mig har været med i deres overvejelser er at det er dejligt nemt at hurtigt finde 40 java konsulenter.
... 40 .... Java konsulenter?
Hvad skulle det hjaelpe?
Saa kan NemID siger "Det er ikke Java der er problemet", naar jeg ringer efter support paa MorphOS eller hvad?
Det er nogle af de tng jeg kan forestille mig har været med i deres overvejelser- hvad siger du myplace.dk ?
Han siger nok "Din mor er grim"? Hvad med at forholde dig til debatten her?
Du har endnu ikke givet noget argument der goer at NemID er designet rigtigt, tvaertimod det modsatte. Der er slaekket paa sikkerhedsmodellen og implementationsmuligheder af ulogiske aarsager.
Det er bare dumt.
moveax1ret (69) skrev:Det er nogle af de tng jeg kan forestille mig har været med i deres overvejelser- hvad siger du myplace.dk ?
Et af de store formål med appletten er at signere. Det er formålsløst at gøre serverside. (Kan også bruges som svar til #70.)
Det irriterer mig at den skal bruges ved login, mest fordi appletter ikke kan køre på min smartphone. Men det har så sine fordele at bruge samme portlet (eller bare samme teknologi) til de to ting.
moveax1ret (69) skrev:Det er dejligt med java at hvis java kan starte i en sun JRE så virker tæt på alting.
Tjaæh, næsten enhver desktop browser kan køre Java applets. Eller man kan få dem til det. Desktops fylder bare ikke så meget som det har gjort. De håndholde computere (smartpones osv) fylder rigtigt meget ved nogle segmenter. "Alting" er ikke længere Windows, OS X (og hvad den nu ellers har heddet) og Linux. Nu er der også iOS og Android. Og lige om hjørnet har vi nok også Symbian og Windows Phone. Ingen af dem kan køre applets.
#72
Hvad er det du gerne vil signere?
HTTPS krypterer din trafik klient og server imellem.
Java Applets er ikke understoettet paa sort set alle mobile enheder eller OS hvor man ikke lige kan koere Suns JRE.
Dertil kommer saa at SUN JRE ikke er frit, saa fx Debian har det i non-free repo. Andre distributioner har valgt slet ikke at have det med, hvor helt andre OS har valgt slet ikke at lave deres egen Java port endnu.
Hvorfor bruge Java? :)
Hvad er det du gerne vil signere?
HTTPS krypterer din trafik klient og server imellem.
Java Applets er ikke understoettet paa sort set alle mobile enheder eller OS hvor man ikke lige kan koere Suns JRE.
Dertil kommer saa at SUN JRE ikke er frit, saa fx Debian har det i non-free repo. Andre distributioner har valgt slet ikke at have det med, hvor helt andre OS har valgt slet ikke at lave deres egen Java port endnu.
Hvorfor bruge Java? :)
fidomuh (73) skrev:Hvad er det du gerne vil signere?
HTTPS krypterer din trafik klient og server imellem.
Huh?
HTTPS krypterer. Jeg snakker om signatur.
Når man laver en transaktion i sin (danske) netbank, så skal man lige skrive sit kodeord igen. I nogle tilfælde indtaste en nøgle fra nøglekortet. Det ser sker der (ud over en ekstra mulighed for at tjekke hvad man har gang i), er at du "skriver under" på at det er dig som beder om det, der står ovenover.
Det betyder dels at det er langt nemmere at håndtere det når det lykkes en "bad guy" at komme ind i andres netbank. (Laaang historie jeg ikke kender halvdelen af, men det er konklusionen.)
Det forhindrer også at data bliver ændret undervejs, ligesom HTTPS gerne skulle. Men HTTPS er ikke sikkert nok i sig selv. Det er ganske normalt at arbejdsplads, skoler osv. installerer sit eget root-certifikat på klienterne så proxy'en kan udføre sin arbejde, og dermed har de et man-in-the-middle attack inden nogen overhovedet er begyndt at gøre noget ondsindet.
Dvs. ud over at gøre noget HTTPS ikke gør, så supplerer det også HTTPS, og bringer dermed sikkerheden endnu et niveau op.
#75
Det har stadigvæk ikke noget at gøre med at det er en applet. F.eks. i Dansk Bank skriver du bare dit password igen, intet apple fis eller password nødvendigt for at godkende en betaling.
Der er intet reelt argument for at bruge Java Applets.
Grunden til at DanID valgte det, var fordi at den eksisterende Digitale Signatur var skrevet i Java. Så deres programmører kunne ikke tænke sig til andre løsninger.
Og det er ikke de skarpeste programmører der findes, ud af dømme fra koden til den digitale signatur. (Jeg tvivler på at NemID er af højere kvalitet)
Det har stadigvæk ikke noget at gøre med at det er en applet. F.eks. i Dansk Bank skriver du bare dit password igen, intet apple fis eller password nødvendigt for at godkende en betaling.
Der er intet reelt argument for at bruge Java Applets.
Grunden til at DanID valgte det, var fordi at den eksisterende Digitale Signatur var skrevet i Java. Så deres programmører kunne ikke tænke sig til andre løsninger.
Og det er ikke de skarpeste programmører der findes, ud af dømme fra koden til den digitale signatur. (Jeg tvivler på at NemID er af højere kvalitet)
#76
Sikke du vrøvler i denne tråd.
Jeg ved ikke hvordan Danske Bank håndterer signatur af transaktioner, men det har da absolut intet at gøre med hvad NemID tilbyder af features, og hvor vidt andre banker bruger dem.
Kilde?
Sikke du vrøvler i denne tråd.
Jeg ved ikke hvordan Danske Bank håndterer signatur af transaktioner, men det har da absolut intet at gøre med hvad NemID tilbyder af features, og hvor vidt andre banker bruger dem.
Windcape (76) skrev:Grunden til at DanID valgte det, var fordi at den eksisterende Digitale Signatur var skrevet i Java. Så deres programmører kunne ikke tænke sig til andre løsninger.
Kilde?
#75
Og jeg spoerger *hvad* du vil signere.
Det er hele pointen.
Eh, det kan man ogsaa lave uden en applet.
Du taenker paa at applet'en er signeret selv og at man saa slipper dels for man-in-the-middle angreb, eller hvad?
Det er korrekt.
Jeg er ikke helt med paa hvorfor en Java Applet skulle forbedre dette scenarie synderligt meget, udover at skolerne endnu ikke er begyndt at fiske den her trafik ud.
HTTPS er krypteret fra klient til server. Java Applet er signeret.
Kudos.
Forskellen er udelukkende at skolerne endnu ikke har fucket med Java Applet'ens data.
Konklusionen er dermed, at din netbank er usikker hvis du bruger en maskine som har fishy software installeret og hvor "ondsindede" folk har fysisk adgang. Det forhindrer applet'en dem ikke i.
Samtidig saa er det et lidt svagt argument, da det her netop er grunden til at der er to-faktor auth.
Saa jeg spoerger igen:
Hvorfor bruge en Java Applet?
Huh?
HTTPS krypterer. Jeg snakker om signatur.
Og jeg spoerger *hvad* du vil signere.
Det er hele pointen.
Når man laver en transaktion i sin (danske) netbank, så skal man lige skrive sit kodeord igen. I nogle tilfælde indtaste en nøgle fra nøglekortet. Det ser sker der (ud over en ekstra mulighed for at tjekke hvad man har gang i), er at du "skriver under" på at det er dig som beder om det, der står ovenover.
Eh, det kan man ogsaa lave uden en applet.
Det betyder dels at det er langt nemmere at håndtere det når det lykkes en "bad guy" at komme ind i andres netbank. (Laaang historie jeg ikke kender halvdelen af, men det er konklusionen.)
Du taenker paa at applet'en er signeret selv og at man saa slipper dels for man-in-the-middle angreb, eller hvad?
Det forhindrer også at data bliver ændret undervejs, ligesom HTTPS gerne skulle. Men HTTPS er ikke sikkert nok i sig selv. Det er ganske normalt at arbejdsplads, skoler osv. installerer sit eget root-certifikat på klienterne så proxy'en kan udføre sin arbejde, og dermed har de et man-in-the-middle attack inden nogen overhovedet er begyndt at gøre noget ondsindet.
Det er korrekt.
Dvs. ud over at gøre noget HTTPS ikke gør, så supplerer det også HTTPS, og bringer dermed sikkerheden endnu et niveau op.
Jeg er ikke helt med paa hvorfor en Java Applet skulle forbedre dette scenarie synderligt meget, udover at skolerne endnu ikke er begyndt at fiske den her trafik ud.
HTTPS er krypteret fra klient til server. Java Applet er signeret.
Kudos.
Forskellen er udelukkende at skolerne endnu ikke har fucket med Java Applet'ens data.
Konklusionen er dermed, at din netbank er usikker hvis du bruger en maskine som har fishy software installeret og hvor "ondsindede" folk har fysisk adgang. Det forhindrer applet'en dem ikke i.
Samtidig saa er det et lidt svagt argument, da det her netop er grunden til at der er to-faktor auth.
Saa jeg spoerger igen:
Hvorfor bruge en Java Applet?
I stedet for at belemre brugerne med en ustabil java applet til det formål kunne de lige så godt have ladet brugeren indtaste password og engangsnøgle i en html form. Resten af funktionaliteten kan implementeres på serversiden.myplacedk (75) skrev:Når man laver en transaktion i sin (danske) netbank, så skal man lige skrive sit kodeord igen. I nogle tilfælde indtaste en nøgle fra nøglekortet. Det ser sker der (ud over en ekstra mulighed for at tjekke hvad man har gang i), er at du "skriver under" på at det er dig som beder om det, der står ovenover.
Det ville være mere sikkert at gøre det på den måde, fordi der er en langt mindre angrebsflade. Brugeren vil kun skulle stole på et website (nemlig bankens), og der kræves mindre software på klientcomputeren.
Ethvert forsøg på at argumentere for at systemet kan blive mere sikkert ved at tilføje appleten falder til jorden af den simple grund, at hvis bankens webserver er kompromitteret kunne appleten alligevel være skiftet ud med en anden applet, eller blot et html fragment, som simulerede appletens brugerflade.
Når du nu alligevel er nødt til at stole på bankens webserver, så kan man lige så godt sende alle data dertil og processere dem på serveren i stedet for at lave en mere besværlig og mindre stabil løsning, som samtidigt er endnu et punkt man kan forsøge at angribe i systemet.
Det vil jeg betragte som en kompromitteret klientmaskine, og man bør aldrig bruge sin netbank fra en kompromitteret maskine. Uanset hvilke påstande du måtte høre andre steder, så kan det ikke lade sig gøre at implementere en netbank som er sikker, hvis man bruger den fra en kompromitteret maskine.myplacedk (75) skrev:Det forhindrer også at data bliver ændret undervejs, ligesom HTTPS gerne skulle. Men HTTPS er ikke sikkert nok i sig selv. Det er ganske normalt at arbejdsplads, skoler osv. installerer sit eget root-certifikat på klienterne så proxy'en kan udføre sin arbejde, og dermed har de et man-in-the-middle attack inden nogen overhovedet er begyndt at gøre noget ondsindet.
Det har vi forsøgt at fortælle ham i snart et år. Han har virkelig svært ved at forstå det.kasperd (80) skrev:I stedet for at belemre brugerne med en ustabil java applet til det formål kunne de lige så godt have ladet brugeren indtaste password og engangsnøgle i en html form. Resten af funktionaliteten kan implementeres på serversiden.
fidomuh (78) skrev:Og jeg spoerger *hvad* du vil signere.
Det er hele pointen.
Transkaktionen. Dvs. ved en pengeoverførsel: Beløb, modtager, dato osv.
fidomuh (78) skrev:Eh, det kan man ogsaa lave uden en applet.
Der er sjældent kun én løsning på et givent problem. Det jeg argumenterer for er, at man kan ikke lave en clientside signatur serverside.
fidomuh (78) skrev:Du taenker paa at applet'en er signeret selv og at man saa slipper dels for man-in-the-middle angreb, eller hvad?
Nej. Jeg prøver at gøre opmærksom på at clientside signering gør det nemmere at se hvad der er foregået, når der er ugler i mosen.
fidomuh (78) skrev:Jeg er ikke helt med paa hvorfor en Java Applet skulle forbedre dette scenarie synderligt meget
Her bevæger vi os ind på et område hvor jeg ikke er så meget inde i detaljerne, så det svar leder desværre ikke til yderligere uddybning.
fidomuh (78) skrev:udover at skolerne endnu ikke er begyndt at fiske den her trafik ud.
Det har i øvrigt også en værdi, men det kan du godt vælge at marginalisere.
Kig i jeres browser på listen over CA's i truster- ethvert certifikat underskrevet af dem kan i teorien lave MITM.
En af dem er kinesisk- så f.eks. den kinesiske regering kan lave MITM.
I en applet kan man vælge kun at stole på en bestemt CA:
En af dem er kinesisk- så f.eks. den kinesiske regering kan lave MITM.
I en applet kan man vælge kun at stole på en bestemt CA:
Det kan man så faktisk godt.myplacedk (82) skrev:Det jeg argumenterer for er, at man kan ikke lave en clientside signatur serverside.
Du bruger dit brugernavn, password, og nem-id kode, som siden så sender videre til DanID, der derefter returnere din offentlige nøgle, som du så signere med.
Det kan lade sig gøre uden problemer. Faktisk en del nemmere end i en Applet.
At du bliver ved med at tro noget andet, er simpelthen for dumt.
Det er bevist, ved flere usability undersøgelser, at folk ignorer fuldstændigt hvad der står i popups omkring signeringer.myplacedk (82) skrev:Nej. Jeg prøver at gøre opmærksom på at clientside signering gør det nemmere at se hvad der er foregået, når der er ugler i mosen.
Derudover er det kun én gang du skal godkende appletten. Ikke hver gang.
Så det argument er ikke validt.
kasperd (80) skrev:I stedet for at belemre brugerne med en ustabil java applet til det formål kunne de lige så godt have ladet brugeren indtaste password og engangsnøgle i en html form. Resten af funktionaliteten kan implementeres på serversiden.
Hvis vi snakker login, så så jeg også gerne en HTML-version.
kasperd (80) skrev:Resten af funktionaliteten kan implementeres på serversiden.
Har du virkelig så svært ved at fatte konceptet i clientside signatur?
kasperd (80) skrev:Ethvert forsøg på at argumentere for at systemet kan blive mere sikkert ved at tilføje appleten falder til jorden af den simple grund, at hvis bankens webserver er kompromitteret kunne appleten alligevel være skiftet ud med en anden applet, eller blot et html fragment, som simulerede appletens brugerflade.
Jeg kender ikke detaljerne, men jeg er ret sikker på at du så får svært ved at lave en korrekt signatur på transaktionerne.
kasperd (80) skrev:Når du nu alligevel er nødt til at stole på bankens webserver, så kan man lige så godt sende alle data dertil
Huh? Det kodeord du bruger til at logge ind osv. med NemID på potentielt alle danske banker, et hav af offentlige sider og hvem ved hvor mange firmaers systemer, det synes du bare man uden problem kan sende til andet end login-systemet?
Det svarer til hvis du logger på newz med openid, så sender du dine credentials (id og kodeord) til newz, som så spørger din openid provider om kodeordet er korrekt. Rigtigt dumt.
kasperd (80) skrev:Det vil jeg betragte som en kompromitteret klientmaskine, og man bør aldrig bruge sin netbank fra en kompromitteret maskine.
Det kan du mene så inderligt du har lyst, det ændrer ikke på at folk ikke kan se noget problem i at logge på fx. sin private netbank fra sin arbejdscomputer.
Jeg mener nu også bestemt at der er forskel på om den PC jeg bruger er "kompromitteret" af min arbejdsgiver (som ejer den), eller om det er en eller anden "bad guy" som vil stjæle mine penge.
Windcape (84) skrev:Det kan man så faktisk godt.myplacedk (82) skrev:Det jeg argumenterer for er, at man kan ikke lave en clientside signatur serverside.
Hold kæft hvor er du dum at høre på efterhånde, ærligt talt. Gå dog i seng.
Banken kan lade som om det er en clientside signatur selv om den er genereret serverside, i hvert fald i teorien. Men når den er lavet serverside, så er den ikke clientside. Præcist ligesom op ikke er ned, og rød ikke er grøn.
I øvrigt ville det også være ufatteligt dumt af banken, og det ville ikke tage lang tid banken står med en skandale som får folk til at glemme de skandaler der har lukket flere banker de sidste år.
Windcape (84) skrev:Det er bevist, ved flere usability undersøgelser, at folk ignorer fuldstændigt hvad der står i popups omkring signeringer.myplacedk (82) skrev:Nej. Jeg prøver at gøre opmærksom på at clientside signering gør det nemmere at se hvad der er foregået, når der er ugler i mosen.
For det første, så må det være folks eget problem at de skriver under på noget de ikke har læst. Der er intet nyt i at folk ikke læser "det med småt".
For det andet, så sker der teknisk set præcist det samme uanset hvor lidt eller meget folk læser hvad der står på skærmen, så længe de trykker på de rigtige knapper. Signaturen skaber stadig de spor bankerne og DanID skal bruge til at efterforske en sag.
Windcape (84) skrev:Derudover er det kun én gang du skal godkende appletten. Ikke hver gang.
Hvad snakker du nu om? Du skal godkende hver gang du skal godkende. Påstår du at når først du har godkendt én kontooverførsel, så skal de efterfølgende ikke godkendes?
Windcape (86) skrev:Har du virkelig så svært ved at fatte at det ikke er nødvendigt at det er clientside?
Pointen er at man ønsker clientside signatur, og det kan man ikke lave serverside.
Så kan du have alle de holdninger du har lyst til om hvad der er nødvendigt.
Nej, jeg siger at jeg kun skal godkende applettens signering én gang.myplacedk (87) skrev:Hvad snakker du nu om? Du skal godkende hver gang du skal godkende. Påstår du at når først du har godkendt én kontooverførsel, så skal de efterfølgende ikke godkendes?
I Dansk Bank's netbank, bruges NemID kun til login. Intet andet. Jeg bruger alm. kodeord til at godkende en kontoroverførsel.
Der er jo ingen som ønsker clientside signatur. Alle så gerne det var serverside, så man ikke havde problemer med Java Applets der ikke virker på mobile platforme.myplacedk (88) skrev:Pointen er at man ønsker clientside signatur, og det kan man ikke lave serverside.
Så der er stadigvæk ingen grund til at bruge Java Applets. Overhovedet!
Vi snakker om 3 værdier der skal sendes til en webservice hos DanID, som så returnere true eller false.
Det er sku for fanden ikke så svært at implementere serverside, så vi kan logge på vores netbank igennem en HTML form -- der også virker på vores mobiler!
Windcape (89) skrev:I Dansk Bank's netbank, bruges NemID kun til login. Intet andet. Jeg bruger alm. kodeord til at godkende en kontoroverførsel.
Mit svar er stadig:
myplacedk (77) skrev:Jeg ved ikke hvordan Danske Bank håndterer signatur af transaktioner, men det har da absolut intet at gøre med hvad NemID tilbyder af features, og hvor vidt andre banker bruger dem.
Windcape (90) skrev:Der er jo ingen som ønsker clientside signatur.
Med "man" mente jeg bankerne og DanID. Dem som skal bruge det.
Det er ærgeligt at sikkerheden går ud over brugeroplevelsen, men sådan er sikkerhed jo ofte. De fleste af os har nok prøvet at være generet af at skulle bruge en nøgle til at komme ind i sit eget hjem eller bil, men det er da bedre end at enhver kan åbne døren.
Windcape (90) skrev:Det er sku for fanden ikke så svært at implementere serverside
Nej, det er ikke svært at droppe sikkerheden. Bare dumt.
Da du ikke kan fremvise et emperisk bevis for at Java Appletten giver højere sikkerhed end en serverside implementering, må det derfor konkluderes at Java Applet modellen ikke er mere sikker.myplacedk (91) skrev:Nej, det er ikke svært at droppe sikkerheden. Bare dumt.
Bankerne vil før eller senere indse det samme, og droppe Java Appletten, fordi at mobilmarkedet er så attraktivt i forhold til at sikre sig de nye unge kunder.
Jeg forstår udmærket godt hvordan en signatur på klientsiden virker. Men nemid har jo ikke ret meget med signaturer at gøre. For det første har de jo aldrig spurgt mig om min offentlige nøgle.myplacedk (85) skrev:Har du virkelig så svært ved at fatte konceptet i clientside signatur?
Alle data appletten får leveret er et password og en engangsnøgle. Begge dele kunne sendes til serveren, som så kunne gennemføre præcist samme beregning. De kunne for den sags skyld anvende samme kode, hvis serveren kan køre java. Men det samme kunne lige så vel være implementeret i samme sprog som serversiden ellers er implementeret i.myplacedk (85) skrev:Jeg kender ikke detaljerne, men jeg er ret sikker på at du så får svært ved at lave en korrekt signatur på transaktionerne.
Nej, jeg mener ikke det er ok. Men det ville stadigvæk være bedre end det nuværende system. Faktum er at alle de systemer du nævner uden videre kunne hente de data fra brugeren. Det eneste de skal gøre er at præsentere brugeren for samme brugerflade som appletten, men sende data til serveren i stedet.myplacedk (85) skrev:Det kodeord du bruger til at logge ind osv. med NemID på potentielt alle danske banker, et hav af offentlige sider og hvem ved hvor mange firmaers systemer, det synes du bare man uden problem kan sende til andet end login-systemet?
Det vil sige, at hvis et eneste af disse systemer er kompromitteret, så vil nemid være kompromitteret for alle brugere, at det system.
Jeg ville foretrække et system, hvor man har et password per system man logger på, og så en god password manager, hvis ikke man kan huske alle disse passwords.
Alternativt kunne man anvende certifikater til at logge på, jeg tror nok det er understøttet af de fleste browsere. Jeg har dog ikke selv anvendt det.
Det er sandsynligvis en overtrædelse af lovgivningen på et eller andet område, hvis en virksomhed foretager mitm angreb på kommunikation til netbank eller andre finansielle transaktioner. Hvis ikke virksomheden stoler på den slags websites, så burde hellere blokere dem helt i stedet for at foretage mitm angreb.myplacedk (85) skrev:det ændrer ikke på at folk ikke kan se noget problem i at logge på fx. sin private netbank fra sin arbejdscomputer.
Hvad angår sikkerheden i nemid er den slags mitm angreb blot en angrebsflade mere. Uanset om man kompromitterer banken, nemid, eller klientmaskinen, så har man kompromitteret sikkerheden i systemet.
Windcape (92) skrev:Da du ikke kan fremvise et emperisk bevis for at Java Appletten giver højere sikkerhed end en serverside implementering, må det derfor konkluderes at Java Applet modellen ikke er mere sikker.
Så fordi en bestemt fyr på nettet (mig) ikke kan/vil overbevise en anden bestemt fyr (dig), på den måde han ønsker, så er det bevist at DanID har spildt sin tid med at lave den problematiske applet?
Det vil jeg ikke argumentere imod.
Windcape (92) skrev:Bankerne vil før eller senere indse det samme, og droppe Java Appletten, fordi at mobilmarkedet er så attraktivt i forhold til at sikre sig de nye unge kunder.
Huh? Har du ikke lagt mærke til de mange mange gange det er blevet nævnt, at DanID er på vej med et alternativ til appletten til den mobile platform? Det har de været længe. Men jeg vil nu gætte på at det ikke får nogen indflydelse på appletten til desktop-brug. Ikke lige foreløbig.
kasperd (93) skrev:Men nemid har jo ikke ret meget med signaturer at gøre. For det første har de jo aldrig spurgt mig om min offentlige nøgle.
Det er ikke en personlig signatur på den måde. Derfor er det nu stadig en signatur. Oplys mig endelig, hvis du kender et bedre ord.
kasperd (93) skrev:Alle data appletten får leveret er et password og en engangsnøgle. Begge dele kunne sendes til serveren, som så kunne gennemføre præcist samme beregning. De kunne for den sags skyld anvende samme kode, hvis serveren kan køre java. Men det samme kunne lige så vel være implementeret i samme sprog som serversiden ellers er implementeret i.
Ah ja, i samarbejde med DanID kan det rent teknisk godt lade sig gøre. Men det hele ryger tilbage til at man ønsker at det foregår clientside.
Jeg kan også sende min mor en banan med posten. Grunden til at jeg ikke gør det er ikke at jeg ikke kan, eller at jeg synes det er svært. Jeg har bare ikke lyst.
kasperd (93) skrev:Faktum er at alle de systemer du nævner uden videre kunne hente de data fra brugeren. Det eneste de skal gøre er at præsentere brugeren for samme brugerflade som appletten, men sende data til serveren i stedet.
Det er helt korrekt at man kan høste brugernavne og kodeord på den måde. Det er derfor vi har nøglekortet.
Man kan også nemt stjæle nøglekortet fra folk. Det er derfor vi har kodeordet.
Udfordringen er at skaffe både kodeord og nøglekort fra den samme person OG være i stand til at kæde dem sammen.
kasperd (93) skrev:Jeg ville foretrække et system, hvor man har et password per system man logger på, og så en god password manager, hvis ikke man kan huske alle disse passwords.
Det er jo så det vi er ved at gå fra, for det er ikke praktisk for langt det fleste brugere. Jeg kan dog godt se attraktionen i systemet for de meget få som kan og gider bruge det korrekt.
kasperd (93) skrev:Alternativt kunne man anvende certifikater til at logge på, jeg tror nok det er understøttet af de fleste browsere.
Altså den løsning vi lige er gået væk fra, fordi den er for usikker og upraktisk?
kasperd (93) skrev:netbank eller andre finansielle transaktioner. Hvis ikke virksomheden stoler på den slags websites, så burde hellere blokere dem helt i stedet for at foretage mitm angreb.
Det handler overhovedet ikke om hvorvidt virksomheden stoler på en eller anden webbank. Det er AL internetadgang der går gennem sådan en proxy. Om ikke andet så for at se hvad det er man tilgår, så proxyen kan se om det er et blacklistet site. (Pga. af sikkerhed, arbejdsrelevans eller hvad de nu vil filtrere på.)
At spærre for fx. netbanker kan jeg ikke se skulle gavne noget.
Men hvorfor? Jeg har allerede forklaret hvorfor det ingen ekstra sikkerhed giver samt hvilke ulemper det giver.myplacedk (95) skrev:Men det hele ryger tilbage til at man ønsker at det foregår clientside.
Hvorfor insisterer man på sådan en løsning når den er mere kompliceret, mere ustabil og mere usikker end en løsning implementeret på serveren?
Nej. Hvad vi er gået bort fra var at bankerne selv kunne vælge et system. Det jeg har haft indtil nu har involveret et nøglekort og et kodeord. Altså præcist de samme faktorer i autentifikationen som nemid har. Forskellen er altså udelukkende, at det nye system er blevet lavet mere ustabilt og introducerer flere angrebsflader.myplacedk (95) skrev:Altså den løsning vi lige er gået væk fra, fordi den er for usikker og upraktisk?
Det vil selvfølgelig ikke ske før der er en virksomhed som er blevet dømt for at have foretaget mitm angreb imod deres medarbejderes finansielle transaktioner.myplacedk (95) skrev:At spærre for fx. netbanker kan jeg ikke se skulle gavne noget.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund