- Du er nødt til å deaktivere Java

[efikkan]

...men det er problemfritt å synce tidsserver mot brikken.

For å fortsette sidesporet: Tanken er grei så lenge brikken brukes ofte nok, problemet blir heller hvis brikken ligger ubrukt over lengre tid. Det hadde vært uproblematisk i mine øyne hvis det hadde vært snakk om under ti gyldige koder, men hvis det genereres én ny kode per sekund så er det snakk om mange hundre, om ikke tusener av gyldige koder. Med tanke på at enkelte banker bruker bare 6 siffer så er ikke det mye sikkerhet. Jeg har en sterk mistanke om at mange av disse kodebrikkene bruker en pseudo-random funksjon som hver gang bare gir neste tall i rekken, litt som kodebrettene som enkelte banker og skatteetaten brukte før. Slike løsninger er absolutt ikke sikre.

[Occi]

Er det ikke et litt for stort hylekor nå?

Java kan settes til å kun brukes på godkjente sider. Feks nettbank, etc.

Det er ganske naivt å tro at dette er noen sikker løsning. Vi snakker om trojanere som kan lastes ned i drive-by-attacks, kan installere rootkit og gjøre hva enn de vil med systemet. Aktivering av java kun på godkjente sider er ikke noe unntak.

 

NoScript derimot er ganske fint. Det er litt tungvint å hele tiden måtte whiteliste nye sider, men jeg føler det er verdt det.

[_dundun_]

For å fortsette sidesporet: Tanken er grei så lenge brikken brukes ofte nok, problemet blir heller hvis brikken ligger ubrukt over lengre tid. Det hadde vært uproblematisk i mine øyne hvis det hadde vært snakk om under ti gyldige koder, men hvis det genereres én ny kode per sekund så er det snakk om mange hundre, om ikke tusener av gyldige koder. Med tanke på at enkelte banker bruker bare 6 siffer så er ikke det mye sikkerhet. Jeg har en sterk mistanke om at mange av disse kodebrikkene bruker en pseudo-random funksjon som hver gang bare gir neste tall i rekken, litt som kodebrettene som enkelte banker og skatteetaten brukte før. Slike løsninger er absolutt ikke sikre.

 

Det er derfor man ikke godtar koder langt utenfor scope, man bare sjekker når de var korrekte og justerer deretter. Levetiden på en slik brikke er et par år, så det er nok ikke snakk om så altfor mye vandring.

 

Min forståelse av hvordan brikkene virker er forøvrig at de ikke genererer noe som helst - kodene ligger lagret og er uavhengige av hverandre. Dette er en teknisk god løsning som ikke krever noe særlig datakraft og som vanskelig kan "hackes".

 

Men nå er vi nok litt for langt unna Java

Endret 11. januar 2013 av kvasbo

[Visjoner]

Litt off topic, men jeg tror du tar feil her. Det er ikke mulig å synce brikken med tidsserver, men det er problemfritt å synce tidsserver mot brikken.

 

"Brukeren sender inn kode 12345678, skal vi se, da er brikken hans tydeligvis to timer bak min systemklokke. Det vil si at hans neste kode skal være 87654321, la oss sende ham en 'sorry, feil kode' og se om neste er rett, og om den er det kan vi sette offset for denne brukeren til to timer sånn at neste pålogging går fint med en gang". Eventuelt "heisann, brukeren ligger to koder bak ventet, jaja, vi setter offset!".

 

Med lange nok koder er sikkerhetsrisikoen ved å godta et par koder foran og bak den korrekte ikke et problem.

 

Sånn ville iallfall jeg designet det, og jeg jobber med å designe sånt.

 

 

Satt akkurat og funderte på problemet. Forslaget ditt høres ut som en sannsynlig virkemåte.

 

Hvis du f.eks har et 32kHz krystall med drift på max 7.5ppm over alle temperaturer, vil du ha en worst-case drift på ca. 4min. pr/år. Det vil derfor være lurt med en form for synkronisering, men det sentrale systemet må også ta høyde for at kunden ikke logger inn før det har gått to år, og da godta en lang rekke forskjellige koder. Det vil antakelig allikevel ikke medføre noen risiko når man snakker om 8-sifrede koder. Selv med 1000 godkjente koder, vil det fortsatt være 1:100000 sjanse for å gjette riktig kode. Og vi vet jo lite om tidsoppløsning/overlapp for disse kodene. Men det tar sikkert en 10-20 sekunder mellom hver nye kode, med kanskje 20-30-sekunders varighet på hver. Det er antakelig noenlunde gjennomtenkt

 

Når det gjelder Java, kommer jeg nok ikke til å slutte å bruke det. Google Chrome spør alltid pent om å få lov til å kjøre et Java-program, og jeg vil nå påstå at en nettleser som uten å si fra kjører programmer over nett ikke er særlig sikker. Det blir litt som å bare kjøre hva som helst av .exe-filer, man kan ikke bare regne med at det går bra. Må være litt kritisk.

 

Men jeg ser argumentet om at de store brukermassene lett kan gå på en smell, og det er nok derfor det slås alarm...

[sinnaelgen]

Pussig at noen mener at kodebrikken blir "gammel" .

Hvis det stemmer

hvorfor virker min ( den man må taste inn en egen kode først ) forsatt etter så mange år ?

Hvorfor har jeg ikke fått tilsendt en nye en ?

[efikkan]

Det er derfor man ikke godtar koder langt utenfor scope, man bare sjekker når de var korrekte og justerer deretter. Levetiden på en slik brikke er et par år, så det er nok ikke snakk om så altfor mye vandring.

Min forståelse av hvordan brikkene virker er forøvrig at de ikke genererer noe som helst - kodene ligger lagret og er uavhengige av hverandre. Dette er en teknisk god løsning som ikke krever noe særlig datakraft og som vanskelig kan "hackes".

Men nå er vi nok litt for langt unna Java

Jepp vi er langt unna Java, og ennå lenger unna JRE. Dette problemet er like aktuelt som da kodebrikker ble brukt før BankID (jeg vet flere banker brukte de samme kodebrikkene).

 

Kodebrikkene varer mer enn et par år, 5-8 år på de brikkene jeg kjenner til. Jeg vet at en PC-klokke kan gjerne vandre 10 min på noen måneder, hvor mye bedre er klokkene i kodebrikkene som eventuelt har det?

 

Jeg tror nok at mange av disse brikkene som ikke baserer seg på tid har en pseudu-random-funksjon, men med ulik seed. Denne seeden er nok kodet inn i strekkoden på baksiden av brikken.

 

Det merkverdige er at folk kan bytte om brikkene, noe som skulle vært ekstremt usannsynlig hvis det var tallrekker, men godt mulig dersom det er tidsintervaller.

 

Pussig at noen mener at kodebrikken blir "gammel" .

Hvis det stemmer

hvorfor virker min ( den man må taste inn en egen kode først ) forsatt etter så mange år ?

Hvorfor har jeg ikke fått tilsendt en nye en ?

De fleste banker sender ikke ny brikke før du ber om en. Den ene min er nå fire år gammel, den eneste grunnen til at jeg måtte bytte var at halve displayet sviktet på den forrige, så det ble litt vanskelig å lese av tallene.

[Visjoner]

Jeg vet at en PC-klokke kan gjerne vandre 10 min på noen måneder, hvor mye bedre er klokkene i kodebrikkene som eventuelt har det?

Hvis den eneste funksjonen til en kodebrikke er å ha en mest mulig presis klokke, klarer de nok mye bedre enn det. Det tallet jeg fant, var til et reellt 32kHz krystall (mye brukt ifbm real-time-klokker). Et typisk hovedkort til PC vil nok ikke legge mye penger i en presis real-time-klokke, da dette ikke er viktig for funksjonaliteten.

[sinnaelgen]

Jepp vi er langt unna Java, og ennå lenger unna JRE. Dette problemet er like aktuelt som da kodebrikker ble brukt før BankID (jeg vet flere banker brukte de samme kodebrikkene).

 

Kodebrikkene varer mer enn et par år, 5-8 år på de brikkene jeg kjenner til. Jeg vet at en PC-klokke kan gjerne vandre 10 min på noen måneder, hvor mye bedre er klokkene i kodebrikkene som eventuelt har det?

 

Jeg tror nok at mange av disse brikkene som ikke baserer seg på tid har en pseudu-random-funksjon, men med ulik seed. Denne seeden er nok kodet inn i strekkoden på baksiden av brikken.

 

Det merkverdige er at folk kan bytte om brikkene, noe som skulle vært ekstremt usannsynlig hvis det var tallrekker, men godt mulig dersom det er tidsintervaller.

 

De fleste banker sender ikke ny brikke før du ber om en. Den ene min er nå fire år gammel, den eneste grunnen til at jeg måtte bytte var at halve displayet sviktet på den forrige, så det ble litt vanskelig å lese av tallene.

 

Den jeg har er fra 2005. ( jeg fant papirene )

[Gjest Slettet-x7D6du0Hjb]

Jævla dritt program.. -.-

[Rune-Rolf]

Henvendte meg til disse BankID-folka og fikk følgende svar:

 

"Hei, vi har utviklet to Java-frie løsninger som kan hjelpe deg. BankID på mobil er en mulighet som gjør at du trenger kun en mobiltelefon. DnB, Sparebank1, Skandiabanken og Terra-banker tilbyr tjenesten, men foreløpig er det kun abonnenter hos Telenor, djuice og Talkmore som kan bestille tjenesten. Flere operatører og banker er på vei. Du bestiller tjenesten i nettbanken.

Vi har også en BankID-app klar for IPad og iPhone, den er selvsagt Java-fri. Android-versjonen kommer rett over nyttår. Bank Norwegian har lansert, og de andre bankene kommer etter Ila neste år.

Vi tar med oss ditt hjertesukk videre. Vi må gjøre en grundig sikkerhetsvurdering av alternativene før vi eventuelt bytter ut Java."

[mrs.robinson]

Det er ganske naivt å tro at dette er noen sikker løsning. Vi snakker om trojanere som kan lastes ned i drive-by-attacks, kan installere rootkit og gjøre hva enn de vil med systemet. Aktivering av java kun på godkjente sider er ikke noe unntak.

 

NoScript derimot er ganske fint. Det er litt tungvint å hele tiden måtte whiteliste nye sider, men jeg føler det er verdt det.

 

 

Tanken var jo å bruke enkle grep for å øke sikkerheten. Feks no-script kombinert med å kun tillate Java på forhåndsdefinerte sider. Ønsker man ennå høyere sikkerhet kan man gjerne kjøre alt dette på en egen VM som man kun bruker på nettbanken og altinn.

 

Vi vil ikke oppnå 100% sikkerhet uansett hvilken teknologi man benytter. Det vil alltid finnes måter å omgå sikkerheten. Enten ved hjelp av mad skills eller ren flaks.

 

Slik jeg ser det er dagens Java er greit kompromiss. Såpass enkelt at de aller fleste klarer å bruke BankID. Det er 2 trinns autentisering. Noe som høyner sikkerheten. Ja det kan skje at noen tømmer kontoen din, men det blir ikke et tap du må stå for personlig. Banken dekker tapet.

 

Om du ønsker ekstra sikkerhet så vær super paranoid og ha en helt egen pc med feks Linux på. Legg inn den utskjelte JRE og bruk kun maskinen bak en ekstern brannmur med humbug detektor og trekk ut nettverkskabelen etter bruk. Gå aldri på nett annet enn for BankID.

Med max uflaks kan du fortsatt råkes. Men er det egentlig et problem? Og er det et problem for deg?

 

Slik jeg ser det er det ikke et problem når bankene tar evt. tap. man velger selv hvor paranoid man skal være i forhold til trusler men vi må huske at sikkerhet i bunn og grunn alltid vil være et kompromiss mellom brukervennlighet, kostnader og høy nok sikkerhet.

[_Xorcist]

Henvendte meg til disse BankID-folka og fikk følgende svar:

 

"Hei, vi har utviklet to Java-frie løsninger som kan hjelpe deg. BankID på mobil er en mulighet som gjør at du trenger kun en mobiltelefon. DnB, Sparebank1, Skandiabanken og Terra-banker tilbyr tjenesten, men foreløpig er det kun abonnenter hos Telenor, djuice og Talkmore som kan bestille tjenesten. Flere operatører og banker er på vei. Du bestiller tjenesten i nettbanken.

Vi har også en BankID-app klar for IPad og iPhone, den er selvsagt Java-fri. Android-versjonen kommer rett over nyttår. Bank Norwegian har lansert, og de andre bankene kommer etter Ila neste år.

Vi tar med oss ditt hjertesukk videre. Vi må gjøre en grundig sikkerhetsvurdering av alternativene før vi eventuelt bytter ut Java."

 

Det som er litt dust med BankID-appen er at den ikke erstatter kodebrikken. Det er bare en løsning for å gjøre input av koder "trygt". Hvis BankID fungerte over SSL som alle andre normale nettsider hadde det ikke vært behov for verken Java eller appen slik den er i dag.

 

Den appen burde imidlertid fungert på samme måte som f.eks. Google Authenticator som er en app som viser gyldige engangskoder. Det er vel omtrent 70% av alle nordmenn som har en smarttelefon med Android eller iOS og vi vil gjerne slippe å drasse på kodebrikker. Mobiltelefonen har vi jo alltid med oss uansett. BankID for mobil finnes jo selvfølgelig men med den utrullingstakten som har vært hos operatører og banker så kommer det til å ta flere tiår før alle støtter det.

[sinnaelgen]

Da er det altså 30% som ikke kan bruke apper på telefonen , inkludert bank app

Nå bruker jeg ikke data nedlasting via mobilen , så jeg er litt usikker på det

Uansett så er de ikke noe man vil bruke ukritisk siden man må betale mere for det en for det tradisjonelle bedbandet.

 

Enkelt maser om sikkerheten helt til man skrur av pcen .

Da er man temmelig paranoid og syk.

Man må da kunne buke tjenesten også

[GeirGrusom]

Angående BankID:

Som nevnt er problemene med BankID egentlig ikke knyttet til JRE, men jeg vil gjøre noen poenger:

- Hva skal vi med en applet for BankID? Før BankID hadde norske banker akkurat samme funksjonalitet gjennom HTTPS med SSL. Den eneste "hensikten" jeg kan se ved å velge Java applet er å få kontroll på sikkerheten, siden noen eldre nettlesere (*host* IE #kremt*) støtter bare utrygge varianter av SSL. Problemer er bare at valget av applets introduserer en hel ny rekke av mulige sikkerhetshull, og at nå både nettleseren og JRE må være fri for sikkerhetshull. Pga. problemet over med selvsignering kan du også risikere at noen gir deg en falsk BankID-applet, i motsetning til HTTPS der sertifikatmyndigheter vil forsikre deg om at du er på riktig side og at du ikke sender sensitiv informasjon til gale hender.

- Sikkerheten til kodebrikken/token kan i seg selv stilles store spørsmål ved. Da BankID fremdeles var ferskt kom det påstander om at kodebrikkene var knekt(skal se om jeg finner kilden). Siden jeg vet om tilfeller der folk med uhell har brukt feil kodebrikke og fremdeles blitt autorisert, så sier det meg at algoritmen inne i brikkene ikke kan være så veldig avansert. Hele sikkerheten står og feller på at brukeren skal få en kode fra brikken som skal være umulig å forutsi for en tredjepart. Jeg vet at algoritmen har ingen tilknytning til pin-koden på kodebrikken, siden banken aldri får vite pin-koden du setter på brikken. Kodebrikken blir heller aldri synkronisert med tidsserver, så klokken internt må bli ganske feil over mange år. Siden det fremdeles er ingen problemer å logge inn sier det meg at svært mange koder vil være gyldige til enhver tid. Og siden disse brikkene er billige og masseproduserte, så har mest sannsynlig svært mange brukere identiske brikker. En bedre måte å løse dette på vil være slik som GPG fungerer. Da kunne bankene kvittet seg med de private nøklene og kun beholdt nøklene for verifisering, så et eventuelt datainnbrudd hos banken ville ikke gitt tilgang til andres kodebrikker. Problemet med dette er kostnaden av å konfigurere slike brikker manuelt.

 

BankID brukes for å identifisere brukeren og bruke denne informasjonen for å utføre juridisk bindende signering av avtaler mellom deg og banken, eksempelvis overføring av penger, opprettelse av nye kontoer etc.

HTTPS brukes i tillegg for å sikre forbindelsen ettersom BankID hverken kan, eller skal gjøre dette.

Endret 12. januar 2013 av GeirGrusom

[mandela]

Da er det altså 30% som ikke kan bruke apper på telefonen , inkludert bank app

MinID sin løsning er vel grei nok, personlig passord + kode fra SMS eller PIN-kodebrev, hva gjør BankID sikrere?

[War]

Ingenting.

BankID en elektronisk legitimasjon for sikker identifisering og signering på nett.

MinID er en personlig, elektronisk ID som gir tilgang til offentlige tjenester på nettet.

 

MinID er utviklet av Difi, som har ansvaret for å etablere en felles infrastruktur for bruk av elektronisk ID i offentlig sektor og BankID en elektronisk legitimasjon for sikker identifisering og signering på nett.

 

Banknæringen ønsker å invitere Difi til et samarbeid for å slippe å ha to+ løsninger.

[sinnaelgen]

Min id har det problemet at man må huske det passordet som man bruker noen få ganger i året .

Med tenke på at det ikke er helt aksepterr at man skriver ned passordet så sier det seg selv at det vil fungere dårlig

 

Det har også være en del trøbbel me disse pin kodene.

For min del så blir de ikke godtatt lenger.

 

Da er det en fordel at man har flere løsninger

 

Fra mit synspunkt så virker det som Bank ID er den nest brukervennlige løsningen

[mandela]

Min id har det problemet at man må huske det passordet som man bruker noen få ganger i året .

Med tenke på at det ikke er helt aksepterr at man skriver ned passordet så sier det seg selv at det vil fungere dårlig

Du må huske PIN koden til telefonen og bankkortet også...

 

Det har også være en del trøbbel me disse pin kodene.

For min del så blir de ikke godtatt lenger.

Har selv kun brukt sms koder og har aldri hatt problemer med den løsningen.

[sinnaelgen]

Du må huske PIN koden til telefonen og bankkortet også...

 

og kode brikke ( for de som bruker den gamle)

og adgangskontroll

og passord til pc og epost

 

Alt dette er ikke noe problem så lenge man bruker det regelmessig

Det er når man bruker det under 5 ganger i året at det blir problematisk

 

Angående pinn koder til altinn via SMS

jeg hadde ikke registrert noe telefon nummer eller post der så det var helt umulig å komme seg inn uten pinkodene

helt til man tok i bruk bank ID

 

Videre så vil det være ha vært problematisk å sitte i telefonkø på jobben for å få orden på saken.

[mandela]

Angående pinn koder til altinn via SMS

jeg hadde ikke registrert noe telefon nummer eller post der så det var helt umulig å komme seg inn uten pinkodene

helt til man tok i bruk bank ID

vel, jeg har ikke kodebrikke fra banken, så jeg kan heller ikke bruke bankID