- BankID for dårlig sikret

[NevroMance]

Selvsagt er det billigere å ikke gjøre noe enn å gjøre noe, men nå er det ett faktum at det er sikkerhetshull i bankene. Du snakker om penger, men har egentlig bankene råd til å bruke 2 uker eller hva det tar å få sannsynliggjort svindel før de tilbakebetaler kunden? Greit nok at kunden har gjort en feil, men siden det er hull i sikkerhetssystemet er banken nødt til å påta seg en del av ansvaret.

 

Hvis jeg hadde blitt utsatt for svindel på en eller annen måte og dermed mistet pengene jeg har på kontoen hadde jeg fått store problemer. Jeg er student og har ingen reserver. Hvis det tok banken min over 1 uke, det vil si at jeg måtte leve over 1 uke uten tilgang på mer mat enn hva jeg hadde da kontoen ble tømt, hadde jeg nok sett meg etter en ny bank som forhåpentligvis hadde raskere saksbehandling på sånt. Har bankene råd til det? Er det sikkert at kunden, som banken har en forpliktelse mot, har råd til å vente 1-2 uker? Er det betryggende at stedet så og si alle nordmenn stoler på at kan ta hånd om pengene sine har denne typen sikkerhetshull?

 

Til den siste kan en jo si at Ola Nordmann selv har ansvaret for nettbanken sin og at denne ikke kommer på avveie, men hvor mye vet egentlig Ola Nordmann om nettsikkerhet? Tror du bestefar som nettopp har fått seg nettbank vet at hvis han får en mail fra: security@<din-bank-her>.no med en lenke som heter http://www.<din-bank-her>.no så skal han slette mailen og ikke bruke lenken? Selvsagt gjør han ikke det. Jeg er sikker på at minst 70% av de som har nettbank hadde trykket på denne lenken, og dermed lagt fra seg personnummer, passord + to sikkerhetsnøkler. Noe som er mer enn nok til å komme seg inn på din nettbank og tømme bankkontoen(e). Å sørge for at dette ikke skjer er banken sitt ansvar, og banken kan ikke kreve eller tro at kunden har noe som helst greie på nettsikkerhet. De burde ha ett idiotsikkert system, for folk flest er idioter når det kommer til nettsikkerhet og nettvett. BankID er ikke idiotsikkert, BankID er sårbart.

 

Som ganske kort svar på posten over. Jeg skisserte ikke en ideell løsning på problemet. Da jeg ikke tør komme med påstander om hva som kunne vært en ideell løsning. Jeg kom derimot med en relativt billig løsning, som sikrer en del mer enn hva dagens løsning gjør. Det krever minimale endringer i systemet å sende ut en ekstra brikke og koble betalingsbekreftelsen med denne, og det ville gjort at en hadde fått store problemer med å komme seg inn på kontoen og få tappet denne.

[idos]

Er dette noe som er mulig.. og vil det være sikkert:

 

Biometrisk autentisering (f.eks fingeravtrykksleser i usb) for pålogging. Denne koden er satt sammen av f.eks din identitet (personnummer o.l) og en timestamp i og har et vindu på la oss si 1 eller 2 sekund. koden er selvsagt hashet. Denne blir nå sjekket av av banken og godkjendt. Derom du sender det til en phishingsite vil hackeren klare å logge seg på i løpet av 1 sekund etter at koden blir sendt til han/hun. Dette er selvsagt mulig ved hjelp av f.eks HTTPrequest i f.eks PHP men tror det blir vanskelig å gjennomføre i praksis.

 

Når kunden skal betale et sett med regninger drar han/hun fingeren på fingeravtrykksleseren og de er betalt. .evt. skriver en personlig kode i tillegg(denne må da selvsagt skrives inn før en drar fingeren) . En kan selvsagt la leseren lage en annen type kode ved betaling.. men dette skulle strengt tatt ikke være nødvendig med så kort levetid på koden.

[nebrewfoz]

Enhver sikkerhetsmekanisme vil alltid bli en "trade-off" mellom sikkerhet og brukervennlighet. Akkurat nå virker som om bankene mener at tapene - eller de potensielle tapene - man risikerer ved å bruke BankID er akseptable i forhold til de kostnadene man har ved systemet, og de ulempene systemet påfører kundene.

 

(Det foregår mye svindel med vanlige kredittkort også, men det har aldri vært aktuelt å slutte med kredittkort.)

 

Senere kan det også bli nødvendig å ikke bare koble smartkortet til kode-dingsen, men også til en kortleser på maskinen når man er inne i nettbanken. I tillegg til å ha kodene må du også ha kortet for å få gjort noe. (Her er vi vel i nærheten av løsningen Buypass har valgt.) Hvis det ikke er nok med noe du vet (=kodene) og noe du har (=smartkortet), så må vi kanskje inn med noe du er; dvs. noe som er "unikt" ved deg, f.eks. fingeravtrykk, iris (regnbuehinnen i øyet), retina (netthinnen), eller rett og slett DNA. Ulempen ved å f.eks. måtte gi en blodprøve for å logge seg på nettbanken kan nok skremme vekk en del kunder.

 

Det viktigste må være at kundene holdes skadesløse ved "nettbankran" så lenge de bruker det systemet bankene har valgt.

Og det skader ikke å lære folk flest litt om "nettvett".

[asbjornu]

Problemet med biometrisk autentisering er at de biometriske egenskapene må omsettes til digitale egenskaper, eller bytes, som igjen naturligvis kan kopieres og utnyttes. I tillegg har de fleste fingerkortlesere som så langt har blitt lansert lett latt seg lure av fingeravtrykk på gummibjørner o.l., så det er ikke trygt om det engang ikke er mulig å kopiere den digitale fingeravtrykksignaturen.

 

Har man mulighet til å utføre et MITM-angrep, spiller det ingen rolle hva brukeren autentiserer seg med; det være seg engangskoder, passord eller biometriske egenskaper. MITM har tilgang til alle disse dataene i digital form og kan mate disse videre til banken uten problemer.

[ATWindsor]

Enhver sikkerhetsmekanisme vil alltid bli en "trade-off" mellom sikkerhet og brukervennlighet. Akkurat nå virker som om bankene mener at tapene - eller de potensielle tapene - man risikerer ved å bruke BankID er akseptable i forhold til de kostnadene man har ved systemet, og de ulempene systemet påfører kundene.

 

Ja, dette er viktig å huske, for omfattende systemer er stress å bruke, da kan det være bedre med "sikkert nok" men samtidig enkelt.

 

AtW

[NevroMance]

Enig i det som sies her, at for omfattende systemer bare vil skade det med tanke på at kunder ikke gidder å bruke det. Men jeg vil nok ikke påstå at nettbanken pr. i dag er "sikkert nok". Så lenge en er selektiv og kritisk til hvilke sider en bruker når det gjelder å logge inn til nettbanken (Les: ikke bruke linker fra mail osv) er det selvsagt relativt trygt. Men så er det de som ikke vet hvor mye phising er utbredt og hvor enkelt det er å gå i fella da. For disse er ikke nettbanken sikker nok, og det at ett firma som f. eks. Norsk Tipping har bedre sikkerhet når det gjelder betaling over nett enn hva DnB har gjør at jeg blir veldig skeptisk til bankens sikkerhetssystemer. Banken holder jo faktisk mye mer penger enn hva Norsk Tipping gjør, og til mange flere personer.

[inzyr]

En sikker løsning som også er relativt lett å bruke (men kostbar) ville være å sende dataen over 2 uavhengige nett, slik at det blir vanskeligere å få tak i nettbank-kodene og å koble den opp mot kunden. Ved f.eks. å ha en kodebrikken som ikke viser kodene til kunden men istedenfor når den aktiveres så sender den kodene over GSM nettverket til banken mens kunden vil da bare ha behov for å skrive in passord og brukernavn for å logge inn. På denne måten så vil kunden bare kunne logge seg inn mens kodebrikken er aktiv og videre så slipper kunden å hele tiden bruke kodebrikken for å signere, det gjøres automatisk. Dette kan ikke bli fanget opp da selv om passordet og brukernavnet er fanget opp av en svindler så vil ikke svindleren kunne gjøre noe som helst så lenge kodebrikken er deaktivert (og det er bare kunden som vet når kodebrikken er aktivert). Om dette ble til en standard så kunne jo noe slikt integreres i mobiltelefonene. Ellers er det mye billigere (og sikrere enn BankID) å bare basere seg på en challenge-respond løsning, selv om det vil være mer til besvær for kunden enn det BankID er i dag.

[OberDesiah]

Poenget her er ikke at det er gjennomført et phising-angrep, men at BankID tillater en "mann i midten". BankID kan som Hole påpeker gjøres sikker nok ved forbedringer, men som et sikkerhetsledd i annen infrastruktur vil det uansett være for usikkert i framtiden.

Et angrep forutsetter slett ikke dumskap hos brukerne, masse programvare kan snike seg inn på en brukers data(gjerne i en helt annen sammenheng) uten at dette merkes. Hvordan koder fåes tak i spiller strengt tatt ingen rolle; tekniske utfordringer er det alltid en eller annen idiot som klarer å snøre sammen.

Det fundamentale er at brukerne ikke sitter med signaturen, som nettopp skal brukes til å validere deres egen ID! Det blir som om om banken sier"send oss en kode du, så mekker vi en finfin signatur her på huset om vi får koden i posten."

For det andre forårsaker dette bruddet med normalt bondevett faktisk problemer for banken i fremtiden; ord-mot-ord tvister er ikke av den letthåndterlige sorten. Det blir bare rotete og dyrt for bankene med en slik løsning, fordi rettighetene ikke er riktig forankret. Det er nettopp dette (tror jeg) Hole prøver å understreke ved med snakk om utro tjenere i bankene osv; det gavner på ingen måte bankens side. PS-direktør Jensen tenner på alle pluggene og tror at Hole sier at problemet handler om ansatte som vil bruke signaturene som ligger hos banken/sertifikatholder til å kjøpe julegaver.

[Olaaaaa]

Som posten over, det handler ikke om å finne på nye kryptiske løsninger for innlogging eller sånt, sårbarheten overfor MITM er like stor. Og når det gjelder bruken av GSM, tror ikke jeg ville lest opp kredittkortnummeret mitt oger GSM engang. GSM kan visstnok dekrypteres i sanntid. (Når det gjelder skandiabankens sending av pin-koder som sms så burde disse knyttes opp mot den maskinen som bestilte passordet sånn at man bare kunne bruke dette passordet fra samme IP-adresse som bestilte engangskoden. Nå kan man bestille en engangskode som kan benyttes fra hvilken som helst maskin for å logge seg inn.)

 

Min foreslåtte løsning er å

1) Beholde innloggingssystemet som det er i dag.

2) Innføre et nytt toveis valideringssystem per betaling.

 

Sistnevnte bør da være en enhet der man taster inn kontonummer og beløp inn i en "kalkulator". Denne vil da komme med to outputs, et du gir til banken som din validering av betalingen og et som banken må svare med fra sine sider som må matche den du har fått på din "kalkulator". Først når begge disse er sjekket og funnet korrekt, vil man kunne trykke OK og gjennomføre betalingen.

 

Sistnevnte løsning vil kunne hindre MITM, replay, phishing, brute forcing etc. Ved at banken må valideres gjennom et system som også tar kontonummer og beløp som input vil brukeren kunne kontrollere banken og banken kan kontrollere brukeren. Ta med sekvensnummer, datostempling, pinkoder elns. i beregningen og benytt en god AES/Rjindael kjernefunksjon i "kalkulatoren" og man har et system som ihvertfall for mine øyne ser trygt ut. Ikke brukervennlig, sett med dagens øyne, men brukbart trygt.

[stallman]

Så BankID er i bunn og grunn godt nok sikret, med unntak av pishing ?

 

Sparebank1 har jo dobbel valideringsjekk før betalinger og overføringer skjer.

Dette gjør jo at vi Sparebank1 kunder er trygge mot pishere. Fordi det ikke er mulig å overføre eller betale noe som helst uten ny kode som genereres av kortleser. Derfor er pisherne avhengig av å ha kortet i hånden.

Endret 1. desember 2007 av Winball

[Olaaaaa]

Så BankID er i bunn og grunn godt nok sikret, med unntak av pishing ?

 

Sparebank1 har jo dobbel valideringsjekk før betalinger og overføringer skjer.

Dette gjør jo at vi Sparebank1 kunder er trygge mot pishere. Fordi det ikke er mulig å overføre eller betale noe som helst uten ny kode som genereres av kortleser. Derfor er pisherne avhengig av å ha kortet i hånden.

Det er nettopp her mange tar feil. Du er ikke trygg selv om du oppgir en valideringskode, fordi denne er generert av det samme materialet som brukes til innlogging. Hadde man hatt separate kodesystem for innlogging og betaling ville dette vært mye bedre.

[roac]

Sparebank1 har jo dobbel valideringsjekk før betalinger og overføringer skjer.

Dette gjør jo at vi Sparebank1 kunder er trygge mot pishere. Fordi det ikke er mulig å overføre eller betale noe som helst uten ny kode som genereres av kortleser. Derfor er pisherne avhengig av å ha kortet i hånden.

Det er her du tar TOTALT feil, og du viser med all mulig tydelighet at du har LANGT igjen å gå før du blir god på sikkerhet. Du kommer med en rekke antagelser. Bank ID løsningen må også ha en ny kode for betaling, men de lurte kundene til å taste inn en ny kode, angivelig "på grunn av en feil". Det svakeste leddet er, og vil alltid være, brukerne. En person sa for flere år siden til meg, at før jeg innrømmet at jeg ikke visste noe eller ikke kunne noe, så ville jeg aldri bli god på sikkerhet. Du vet aldri noe om hva angriperene kommer opp med, og følgelig kan du ikke sikre deg mot det.

 

Når det er sagt, så er jeg totalt uenig i kritikken av at det i det hele tatt er mulig med MITM. Med så mange brukere som godtar det som måtte dukke opp av feilmeldinger på en PC vil det alltid være mulig å gjøre et MITM angrep. Det vil selvfølgelig alltid være forskjell på brukere, hvor noen vil være lette å lure, andre så og si umulig. Men, jeg vil hevde at det alltid vil være mulig.

[roac]

Det er nettopp her mange tar feil. Du er ikke trygg selv om du oppgir en valideringskode, fordi denne er generert av det samme materialet som brukes til innlogging. Hadde man hatt separate kodesystem for innlogging og betaling ville dette vært mye bedre.

Det ville vært bedre, for du vil bare kunne tappe brukeren for penger de gangene han selv overfører penger.

 

Men, når det så er sagt så er det ingen ting i veien for å gjøre en liten kombinasjon av allerede tilgjengelige teknikker heller? Hvis vi ser for oss et system hvor en kode kun kan brukes en gang (kort levetid, kodekort, eller at brukeren har mulighet for å be om en ny kode på kode"kalkulatoren"), så burde det ikke være noe i veien for koden ble benyttet til å lage en kryptografisk nøkkel, som i sin tur ble brukt til å lage en hash av betalingsinformasjonen.

 

Det mest kritiske punktet blir i så fall nøkkelgenereringen.

[Olaaaaa]

Det er nettopp her mange tar feil. Du er ikke trygg selv om du oppgir en valideringskode, fordi denne er generert av det samme materialet som brukes til innlogging. Hadde man hatt separate kodesystem for innlogging og betaling ville dette vært mye bedre.

Det ville vært bedre, for du vil bare kunne tappe brukeren for penger de gangene han selv overfører penger.

 

Men, når det så er sagt så er det ingen ting i veien for å gjøre en liten kombinasjon av allerede tilgjengelige teknikker heller? Hvis vi ser for oss et system hvor en kode kun kan brukes en gang (kort levetid, kodekort, eller at brukeren har mulighet for å be om en ny kode på kode"kalkulatoren"), så burde det ikke være noe i veien for koden ble benyttet til å lage en kryptografisk nøkkel, som i sin tur ble brukt til å lage en hash av betalingsinformasjonen.

 

Det mest kritiske punktet blir i så fall nøkkelgenereringen.

Altså, om jeg har forstått Hole rett og har forstått alt jeg burde ha lært på skolen så burde man få kodene fra forskjellige steder, ihvertfall fra forskjellige master keys. Det å autorisere med en hash med samme nøkkelmaterialet som man autentiserer med kan i verste fall lage situasjoner som er minst like sårbare som phising, MITM eller replay som tidligere. Ta for eksempel forutsigbare betalinger som husleie eller avdrag på lån. Samme beløp, samme mottaker, plutselig har man en del av variablene for å finne hash-algoritmen. For ikke å snakke om problemer som kan oppstå med ulumskheter i tallmaterialet (svake nøkler etc.). To master keys, toveis validering av autorisering, kanskje også autentisering. Send det over til de paranoide smartassene i NIST og hør hva de har å si om saken.

[roac]

Her uttrykker du med all mulighet at du ikke har filla peiling på det du skriver om. Autentisering er identifikasjon, autorisering er tilgang. Du vil ALLTID ha BÅDE autorisering og autentisering slike løsninger som det her er snakk om, og autentiseringen skjer alltid før autoriseringen.

 

Replay er enkelt å løse. Phising kan brukes for å kunne utføre MITM-angrep uten å ha kontroll på infrastrukturen mellom kunde og tjeneste. Ellers er det ikke noe problem å finne hash-algoritmene. Algoritmene til f eks MD5 og SHA-1 er fritt tilgjengelig, og med så få transaksjoner som en vanlig bruker har i banken, mer enn sikker nok. Et viktig poeng innen datasikkerhet er at man SKAL bruke en kjent algoritme, det er nøkkelen som ikke skal være kjent.

[Olaaaaa]

Ikke så sinna nå, selv om jeg kritiserte løsningen din

 

Jeg vel hva autorisering og autentisering er. Grunnen til at jeg mener at de bør deles såpass tydelig er slik at en nøkkel som brukes til det ene ikke har mulighet til å bli brukt til det andre. Grunnen til at jeg kritiserer hash-løsningen din er jo nettopp det at om man klarer å snappe opp nøkler og hasher, så er jo, som du sier selv, MD- eller SHA-familiene de mest sannsynlige valgene av algoritme. Ordla meg kanskje litt feil i den sammenhengen, det jeg mente var at man da, om man klarer å komme fram til en hel del av de elementene som inngår i det som blir hashet øker muligheten for å kunne dedusere resten av inputene, utføre et birthday-angrep, eventuelt å lage en rainbow table om man får nok slike hasher med kjente inputs. Jeg bare ser for meg at sikkerheten ikke blir noe øket av dette. Ihvertfall ikke mer enn overfladisk, ettersom sikkerheten fortsatt da beror på angripers manglende kunnskap om en nøkkel som kan brukes både til autentisering og autorisering.

[RulleRimfrost]

Så lenge autentiseringsstømmen går gjennom en server som kjenner bankens rutine, og kan plukke opp og behandle denne, vil vel ingen autentisering hindre MITM. Banken tror du logger på fra en russisk server, og du tror du er tilkoblet bankens server. Det vil jo være et brudd i den sikre tunnellen her.

 

Hva om du kunne godkjenne hvilket land nettbanken din godtar ? Det er vel ikke så mange Norske phishere. Jeg ser at min bank fint godtar at jeg logger inn via proxy i utlandet....

[qualbeen]

tror jeg hadde blitt rimelig forbanna hvis jeg ikke fikk logga på nettbanken om jeg var i utlandet på ferie etc.. Hele poenget med en nettbank er vel at den skal være tilgjenlig for kunden, når kunden har behov for det?

[mistercartman]

Jeg vil anta dette er på samme måte som vanlige kodekalkulatorer. De er tidsstyrt og gyldige i normalt 5 minutter. For å ungå problemer med at klokker går feil osv, så er det normalt at +-1 nøkkel blir godkjent (dvs at til enhver tid vil det finner 3 gyldige nøkler).

De er nok ikke det...

Jeg bruker BankID for å logge inn i min nettbank og har opplevd å trykke på knappen for å få en engangskode, for så å oppdage at nettbanken er nede. Denne koden må brukes, men det gikk fint å bruke den flere dager senere.

 

Så det virker ikke som den er tidsbegrenset, men om kunden prøver å logge inn med en kode som kommer "etter" en som ikke er brukt vil brukern bli sperret, og man må ringe til banken for å få resatt greiene.

 

Snodig. Min brikke bytter kode en gang i minuttet omtrent (GO3 brikke). Når den bytter blir den forrige koden ubrukelig. Jeg har vært borti at jeg har trykket på brikken for å få frem en kode, men så ventet bittelitt før jeg tastet den inn, for deretter å få beskjed om at koden er ugyldig. Et par kjappe trykk på brikken igjen viser at den så har byttet til ny kode.

Altså slik jeg opplever det genereres nye koder fortløpende med ett minutts varighet, og forrige kode utløper straks ny kode er på plass.

[mistercartman]

Når man betaler i en nettbank er det mange som nå har begynt å kreve at man taster inn enda en engangskode, denne fra samme kodebrikke/kodekort som den man logget inn med. And herein lies the problem. Når BankID bruker kundenummer og engangspassord til å godkjenne en betaling kommer dette fra samme kilde som det man bruker for å logge inn i nettbank, og godkjenne en betaling. Dette er, sett fra et kryptografisk synspunkt, hull i hodet.

Man må huske på at det ekstra step'et for å godkjenne en betaling ikke ble innført for å beskytte bankkunden, men for å beskytte banken .... Tidligere, når man hadde tastet inn feil kontonummer og først oppdaget det etter noen dager da pengene allerede var brukt opp av den heldige mottaker, da kunne man beklage seg over at nettbanken ikke beskyttet kundene mot slike ting. Ok, så bankene innførte enda et step: "Har du sjekket at kontonummerne er korrekte? Ja? Kryss av her, og tast inn neste kode + passord. Og kom ikke i ettertid og si at vi ikke advarte deg."

 

Vel, det er min versjon av historien ...

 

Det er feil. Det ekstra steget hvor betalingen skal bekreftes har vært på plass en god stund. Også uten å måtte taste inn kode. Som en annen nevner er dette noe som måtte på plass for at brukeren skulle få et ekstra ledd til å godkjenne betalingsinformasjonen.

Kode ved regningsbetaling gjør at man ikke får gjort noe som helst i nettbanken selv om man får kommet seg inn. Dette såfremt ikke brukeren klarer å gi fra seg to koder fortløpende som umiddelbart benyttes av den kriminelle.