Endelig blir du kvitt Java på BankID

[saivert]

Jeg bruker nå to-trinns innlogging flere steder. På Google. Hos registraren min og hos Microsoft Account.

Alle disse benytter samme system som er HOTP (http://en.wikipedia.org/wiki/HMAC-based_One-time_Password_Algorithm). Ser ikke hvorfor BankID ikke kan velge samme løsning. Dette er sikkert nok for alle andre så burde det være sikkert nok for BankID.

[blackbrrd]

 

 

Ingen her som husker at vi hadde nettbank nesten 10 år uten Bank-ID?

når ?

hvordan fungerte det ?

 

Flere banker hadde dette før. HTML-skjema med SSL, som er alt som trengs, valideringen skal tross alt skje på serversiden. Noen banker som f.eks. Cresco hadde kodekort, og jeg tror de fremdeles har det.

 

Tviler på at det er slik det har foregått. Jeg tipper teknologien ble valgt fordi det var den mest utbredte da BankID ble påtenkt. Er mye lettere å utrulle når hundretusenvis av brukere allerede har det som trengs.

Java applet/JRE ble valgt for BankID fordi gamle nettlesere(IE) ikke hadde tilstrekkelig SSL-/TLS-støtte. Det var "enklere" å garantere dette ved å kreve en plugin enn å kreve at kundene skulle oppgradere nettleserne sine. (selv om jeg er uenig)

 

Jeg kan ikke se at det skulle være noe i vegen for å lage en løsning både med og uten både Java og JavaScript. Slik som f.eks. DNB har i dag. Har ikke brukt BankID på lang tid.

Jeg vil heller si, hvorfor i all verden skal vi bruke Java applets(JRE) eller JavaScript til noe som på ingen måte trenger det? Det blir bare mer kompleksitet, vanskeligere for brukerne og flere rom for alvorlige sikkerhetsfeil (det er flere ledd hvor ting kan gå galt). Kom med et eneste solid argument for hvorfor BankID skal bruke det?

 

JavaScript e.l. kommer man seg ikke utenom hvis man vil ha websider som oppfører seg smart og responsivt. Ikke noe jeg vil gi slipp på. Full page submits/refreshes gir ikke akkurat drømmeopplevelsen på web. Sikrere ja, men totalt sett en bedre opplevelse? For meg helt klart ikke.

 

Det er bra at bank-id ikke lenger kommer til å bruke java, det er helt unødvendig og jeg kan ikke helt forstå hensikten. Det er jo lov å håpe at den nye bankid-løsningen fungerer uten javascript også, burde være relativt enkelt for en enkel komponent med to tekstfelt og en submit-knapp...

JavaScript til interaksjon på nettsider er en helt annen sak og det har jeg heller ikke sagt noe imot.

 

Men JavaScript bør holdes milevis unna alt av sensitiv informasjon. Sikkerhetsmessig er det faktisk mer sårbart enn en Java-Applet. Det beste er da å holde siden fri for JavaScript. På lengre sikt bør nok innsending av skjema skje utenfor DOM-elementer og håndteres direkte av nettleseren, separert så lekkasjer blir umulig.

 

Hvorfor er java+nettleser tryggere enn bare nettleseren? Såvidt jeg kan skjønne, så vil feil i enten java eller nettleser gjøre at den løsningen er usikker, mens en som bare bruker nettleseren kun kan være sårbar hvis det er fei på den.

 

Så lenge javascript er aktivt i en nettleser (som vel 99%+ kjører med), så spiller det ikke noen rolle sikkerhetsmessig om siden bruker javascript eller ikke, sikkerheten blir den samme?

[icc]

Jeg vil heller si, hvorfor i all verden skal vi bruke Java applets(JRE) eller JavaScript til noe som på ingen måte trenger det? Det blir bare mer kompleksitet, vanskeligere for brukerne og flere rom for alvorlige sikkerhetsfeil (det er flere ledd hvor ting kan gå galt). Kom med et eneste solid argument for hvorfor BankID skal bruke det?

 

JavaScript trenger ikke være påkrevd, men for mange vil det bidra til en rikere opplevelse og oppfattes som enklere, f.eks. ved navigering, dobbel innsending av skjema-data og sider som går ut på dato. Æraen hvor man behøver sitte og trykke på F5 for å se kontoutskriften oppdatere seg må vel snart være forbi.

 

Hvilke sikkerhetsmessige sårbarheter er det du tenker på i JavaScript?

[G]

De tar seg god tid...

 

AtW

 

Sikkert tryggest det, så får Oracle ta seg av all piss i mellomtiden, det er jo de som eier og utvikler på Java videre.

 

Hva heter erstatningen som finnes i BankID2.0 ?

Er det bruk av HTML5 eller noe liknende?

[RaggSokk3n]

Jre /Java løsningen ble valgt grunnet en dobbel godkjenning hvor passord og kode aldrig skulle sendes sammen. Slik jeg forstod det fantes det ikke et fornuftig alternativ til Java.

[Gjest Slettet-x7D6du0Hjb]

Handelsbanken har fjernet java total fra sin løsning, så jeg trenger ikke stresse med det.

[Karl Skapeland]

 

 

Java er nok et godt eksempel på hvordan det går når spisshåra sjefer og økonomer skal bestemme tekniske løsninger og valg av programvare. Uten engang å ha den teoretiske kunnskap som er nødvendig, og selvsagt, når det går "ad skogen" så er det programmererene (Dilbert ) sin skyld at alt går galt !

Tviler på at det er slik det har foregått. Jeg tipper teknologien ble valgt fordi det var den mest utbredte da BankID ble påtenkt. Er mye lettere å utrulle når hundretusenvis av brukere allerede har det som trengs.

 

 

Nuvel, JavaScript har nå vært verdens mest utbredte(og misforståtte) programmeringsspråk i ganske lenge. Kan aldri huske at Java har vært i nærheten av så utbredt. Jeg tror nok heller teknologi valget kan være et resultat av tilgjengelig kompetanse og sterke pådrivere av Java.

 

Jeg kan ikke se at det skulle være noe i vegen for å lage en løsning både med og uten både Java og JavaScript. Slik som f.eks. DNB har i dag. Har ikke brukt BankID på lang tid.

 

Jeg har da ikke nevnt JavaScript? Hvorfor i all verden drar du det inn i denne diskusjonen uansett? Da BankID ble rullet ut var JavaScript fortsatt et sant helvete, med diametralt forskjellige implementasjoner i de forskjellige browserne. Så jeg skjønner ikke hvordan du kan mene at det skulle være et alternativ til Java i denne sammenhengen.

 

JRE/Applets ble også valgt på grunn av at det var den løsningen som var ga best sikkerhet. Med code signing certificates var det aldri tvil om hvor appleten kom fra, når du logget inn i nettbanken. Det var en av grunnene, og ikke fordi "spisshårede sjefer og økonomer" bestemte det. Du snakker mot bedre vitende. Jeg har jobbet med Java siden 1996. Når det gjelder utbredelse har du ikke peiling på hva du snakker om.

Endret 30. april 2014 av Karl Skapeland

[efikkan]

Hvorfor er java+nettleser tryggere enn bare nettleseren? Såvidt jeg kan skjønne, så vil feil i enten java eller nettleser gjøre at den løsningen er usikker, mens en som bare bruker nettleseren kun kan være sårbar hvis det er fei på den.

 

Så lenge javascript er aktivt i en nettleser (som vel 99%+ kjører med), så spiller det ikke noen rolle sikkerhetsmessig om siden bruker javascript eller ikke, sikkerheten blir den samme?

Nei, det blir slik i prioritert rekkefølge fra best til dårligst:

* HTML-skjema i SSL/TLS.

* Java-Applet

* JavaScript-implementasjon.

 

Merk at Java-Applet har en lang rekke med sikkerhetsproblemer. Hensikten med Applet er som sagt å tvinge støtte for nyeste SSL/TLS, men hvis noen kjører på eldre versjon så kan angriperen injisere en falsk applet. Selv-signerings-funksjonen til Applets gjør at hvem som helst kan signere for hvem som helst. F.eks. jeg kan lage en applet som ser ut som BankID som er signert av "DNB".

 

JavaScript med sine utallige implementasjoner, inkonsitente oppførsel og muligheter for injisering introduserer en hel rekke med nye "angrepsvektorer". Det er bare helt hull i hodet når det er totalt unødvendig.

[Junk Inbox]

Har Bank ID på mobil. Men må fortsatt ha Java for å bruke Norsk Tipping. Når skal de kvitte seg med Java ??? Dessuten er det ikke alle som har smartmobil.

Endret 1. mai 2014 av Junk Inbox

[Abigor]

Selv-signerings-funksjonen til Applets gjør at hvem som helst kan signere for hvem som helst. F.eks. jeg kan lage en applet som ser ut som BankID som er signert av "DNB".

Det er jo derfor man skal ha "trusted third party" med sertifikat. Det kan du ikke lage selv, og sertifikatet ditt blir merket som "self-signed" og dermed er autentiseringen av det verdiløst.

[sinnaelgen]

Når man fjerner JAVA fra Bankid betyr det da at alle bruk av Bankid blir fullstendig uten JAVA elelr komemr noen til jukse ?

 

slik jeg forsto det så var det først og fremst bankene som skulle slutte å bruke JAVA

[blackbrrd]

 

Hvorfor er java+nettleser tryggere enn bare nettleseren? Såvidt jeg kan skjønne, så vil feil i enten java eller nettleser gjøre at den løsningen er usikker, mens en som bare bruker nettleseren kun kan være sårbar hvis det er fei på den.

 

Så lenge javascript er aktivt i en nettleser (som vel 99%+ kjører med), så spiller det ikke noen rolle sikkerhetsmessig om siden bruker javascript eller ikke, sikkerheten blir den samme?

Nei, det blir slik i prioritert rekkefølge fra best til dårligst:

* HTML-skjema i SSL/TLS.

* Java-Applet

* JavaScript-implementasjon.

 

Merk at Java-Applet har en lang rekke med sikkerhetsproblemer. Hensikten med Applet er som sagt å tvinge støtte for nyeste SSL/TLS, men hvis noen kjører på eldre versjon så kan angriperen injisere en falsk applet. Selv-signerings-funksjonen til Applets gjør at hvem som helst kan signere for hvem som helst. F.eks. jeg kan lage en applet som ser ut som BankID som er signert av "DNB".

 

JavaScript med sine utallige implementasjoner, inkonsitente oppførsel og muligheter for injisering introduserer en hel rekke med nye "angrepsvektorer". Det er bare helt hull i hodet når det er totalt unødvendig.

 

Kan ikke si jeg er videre overbevist over argumentasjonen din. Poenget ditt angående injisering antar jo at nettleseren eller websiden allerede er tatt over, da spiller det ingen rolle hvilken teknologi som er i bruk. I tillegg, så er jo javascript aktivert hos så å si alle, så at java er aktivt i nettleseren legger jo bare til en ekstra ting som kan angripes. Skjønner heller ikke hvorfor du nevner SSL/TLS spesifikt for ren html (uten javascript), SSL/TLS vil jo bli brukt i alle tre løsningene (hvis ikke de som har laget java-appletten har funnet på noe nytt da).

[HrKristian]

For DNB sin del er det nok å avinstallére/blokkere Java, så får du valget "Logg inn med kodebrikke", der du trenger personlig PIN (ikke bankkort PIN) og kodebrikken.

 

En periode gjorde DNB noe som gjorde det umulig for meg å laste java-appleten (Chromium på Linux m/IcedTea Java), og i tillegg hang hele fanen som resultat.

Løsningen? m.dnb.no

 

Jo fortere de går over til en ekte løsning som faktisk er sikker, jo bedre.

[sinnaelgen]

Da må man bare huske på å lage seg pinkoden i nettbanken før man fjerner java

[efikkan]

Kan ikke si jeg er videre overbevist over argumentasjonen din. Poenget ditt angående injisering antar jo at nettleseren eller websiden allerede er tatt over, da spiller det ingen rolle hvilken teknologi som er i bruk. I tillegg, så er jo javascript aktivert hos så å si alle, så at java er aktivt i nettleseren legger jo bare til en ekstra ting som kan angripes. Skjønner heller ikke hvorfor du nevner SSL/TLS spesifikt for ren html (uten javascript), SSL/TLS vil jo bli brukt i alle tre løsningene (hvis ikke de som har laget java-appletten har funnet på noe nytt da).

Hvis du har tre implementasjoner av samme sikkerhetsprodukt, som benytter teknologi A, B og C på følgende måte:

1) Bruker kun A

2) Bruker A og B

3) Bruker A, B og C

Hvor B og C ikke bidrar til å øke sikkerheten, men bare tilfører flere ledd hvor det kan skje feil er det åpenbart at 1) er det sikreste valget.

 

Den som har følgt med i timen vet at JavaScript allerede er en verkebyll av feil og inkonsistente implementasjoner. Injisering av kode og cross-site scripting er fremdeles et stort problem. Ethvert forsøk på å implementere sikkerhetsmekanismene i JavaScript vil være en tikkende bombe, og et yndet mål for den som vil manipulere systemet.

 

Det beste på sikt hadde vært en standardisert form for innsending av skjema direkte i nettleseren uten bruk av DOM, slik at JavaScript aldri får fatt i informasjonen. Ett annet steg på veien hadde vært om alle nettlesere kjørte hver fane i en egen "sandkasse".

[Shruggie]

Herregud, hva får dere til å tro at dere kan dette bedre enn de som er ansatt for å faktisk utvikle dette? Vent og se! Hvis det viser seg at den nye løsningen er en fadese så kan dere rope "I told you so", men frem til da er dette et utrolig dølt tema å snakke om.

[efikkan]

Herregud, hva får dere til å tro at dere kan dette bedre enn de som er ansatt for å faktisk utvikle dette? Vent og se! Hvis det viser seg at den nye løsningen er en fadese så kan dere rope "I told you so", men frem til da er dette et utrolig dølt tema å snakke om.

Det er nok av eksempler på tjenester som har blitt laget av utviklere som enten ikke kan eller ikke har prioritert sikkerhet. Hele konsulentbransjen er gjennomsyret av en industri hvor "over-engineering" er et motto for å drive opp prisen. Vi kunne sikkert ramset opp en side med eksempler på slikt. Dagens BankID har som kjent svakheter, og tjenester som Altinn og politisidene har vært ekstremt dårlig laget. Direktoratet for forvaltning og IKT har heller ikke greie på sakene sine, og mener f.eks. hashing av passord er unødvendig. De fleste feilene som har vært i diverse SSL-implementasjoner den siste tiden har vært amatørfeil, ikke vanskelige obskure feil. SCADA-systemer som brukes til infrastruktur og forsvar har praktisk talt ingen sikkerhet. Nettsidene til Obamacare har vært en fadese fra ende til annen. Du forstår forhåpentligvis poenget snart.

 

Når vi skal snakke om BankIDs Java-applet-problemer så blir det riktig å ta en diskusjon med teknisk vinkling.

[sinnaelgen]

Problemet her er nok at de som ønsker disse siden ikke har råd til å ha både jurister som kjenner reglene , programmererer som skal få det til å fungere og de som skal designe på samme tid

 

Nå er de jo også slik at brukergrensesnitt . design og sikkerhet ikke alltid går i hop

 

og så skal det nok også till en viss grad være kompatibelt med andre systemer

[Shruggie]

 

Herregud, hva får dere til å tro at dere kan dette bedre enn de som er ansatt for å faktisk utvikle dette? Vent og se! Hvis det viser seg at den nye løsningen er en fadese så kan dere rope "I told you so", men frem til da er dette et utrolig dølt tema å snakke om.

Det er nok av eksempler på tjenester som har blitt laget av utviklere som enten ikke kan eller ikke har prioritert sikkerhet. Hele konsulentbransjen er gjennomsyret av en industri hvor "over-engineering" er et motto for å drive opp prisen. Vi kunne sikkert ramset opp en side med eksempler på slikt. Dagens BankID har som kjent svakheter, og tjenester som Altinn og politisidene har vært ekstremt dårlig laget. Direktoratet for forvaltning og IKT har heller ikke greie på sakene sine, og mener f.eks. hashing av passord er unødvendig. De fleste feilene som har vært i diverse SSL-implementasjoner den siste tiden har vært amatørfeil, ikke vanskelige obskure feil. SCADA-systemer som brukes til infrastruktur og forsvar har praktisk talt ingen sikkerhet. Nettsidene til Obamacare har vært en fadese fra ende til annen. Du forstår forhåpentligvis poenget snart.

 

Når vi skal snakke om BankIDs Java-applet-problemer så blir det riktig å ta en diskusjon med teknisk vinkling.

 

Du kan si mye negativt om BankID 1.0, og jeg kan godt bli med og si like mange ting, men bortsett fra de innebygde problemene med Java har jeg aldri hørt om et seriøst sikkerhetsproblem med BankID, så jeg vet ikke helt hva du prater om her.

 

User interface, interaksjonsdesign, selve valget av Java... Det er mange andre ting som er fucked up...

Endret 3. mai 2014 av Shruggie

[efikkan]

 

 

Herregud, hva får dere til å tro at dere kan dette bedre enn de som er ansatt for å faktisk utvikle dette? Vent og se! Hvis det viser seg at den nye løsningen er en fadese så kan dere rope "I told you so", men frem til da er dette et utrolig dølt tema å snakke om.

Det er nok av eksempler på tjenester som har blitt laget av utviklere som enten ikke kan eller ikke har prioritert sikkerhet. Hele konsulentbransjen er gjennomsyret av en industri hvor "over-engineering" er et motto for å drive opp prisen. Vi kunne sikkert ramset opp en side med eksempler på slikt. Dagens BankID har som kjent svakheter, og tjenester som Altinn og politisidene har vært ekstremt dårlig laget. Direktoratet for forvaltning og IKT har heller ikke greie på sakene sine, og mener f.eks. hashing av passord er unødvendig. De fleste feilene som har vært i diverse SSL-implementasjoner den siste tiden har vært amatørfeil, ikke vanskelige obskure feil. SCADA-systemer som brukes til infrastruktur og forsvar har praktisk talt ingen sikkerhet. Nettsidene til Obamacare har vært en fadese fra ende til annen. Du forstår forhåpentligvis poenget snart.

 

Når vi skal snakke om BankIDs Java-applet-problemer så blir det riktig å ta en diskusjon med teknisk vinkling.

 

Du kan si mye negativt om BankID 1.0, og jeg kan godt bli med og si like mange ting, men bortsett fra de innebygde problemene med Java har jeg aldri hørt om et seriøst sikkerhetsproblem med BankID, så jeg vet ikke helt hva du prater om her.

 

User interface, interaksjonsdesign, selve valget av Java... Det er mange andre ting som er fucked up...

 

Link