Mange forskjellige innloggingsrutiner samtidig

[sda030]

Jeg har lett både her og andre steder men finner ikke svar på disse viktige spørsmålene for oss:

Kan man ha flere forskjellige innloggingsmekanismer på samme nettsted (f.eks. brukernavn/passord, kodebrikke, digital signatur, osv) utifra de forskjellige ID-kravene i ymse stater og utifra de forskjellige brukerbehovene (stilles inn av bruker i kontrollpanelet) uten at det "totale" sikkerhetsnivået blir lavere enn summen av enkeltdelene?

Gjøres ikke dette kun fordi det krever mye ekstraarbeid i å programmere inn de ulike mulighetene, eller fordi det er en ulempe for sikkerheten og derfor frarådes?

Noen nettsteder lar brukerne selv velge om man skal logge inn med SSL eller ikke, kan dette også gjøres med f.eks. bankenes kodebrikker - da særlig å tillate brukeren å skru ned sikkerheten?

 

Til dere som svarer, legg gjerne kort til om dere har erfaring dette fra nettbanker eller lignende, siden svarene her skal brukes i investorøyemed for et meget stort prosjekt (om det fungerer).

[iChristian]

De fleste nettbanker tilbyr både med og uten bankid-innlogging. Og på altinn.no kan du velge mellom 5-7 innloggingsformer ved varierende sikkerhetsgrad.

[nomore]

Det er ikke et "problem" i seg selv å lage flere innloggingsrutiner på en og samme website/portal. Og det er heller ikke et "problem" at brukeren selv velger rutine og derav nivå på sikkerhet.

 

Problemet kommer når hver enkelt innloggingsrutine skal sikres.

 

Hva er vitsen om en webside er sikret med en løsning sikret med BankID, dersom samme webside også tilbyr pålogging via et enkelt brukernavn og passord? Websiden vil være like utsatt for eksterne trusler som om det kun var mulig å logge inn via et brukernavn og passord.

 

Så for å lage en god og brukbar løsning mener eg at man først og fremst må sette et minstekrav til sikkerhet. Hva er det minste du kan akseptere av sikkerhet for å godkjenne en bruker?

 

Du sier ikke så veldig mye om bakgrunnen for spørsmålet og derav er det også vanskelig å gi et konkret svar. Kort oppsummert, ja, det er mulig å lage en løsning med flere metoder for pålogging. Utfordringen ligger i å få kunden som krever den høyeste sikkerheten til å godta at det også er mulig til å logge seg på med den laveste sikkerheten dere har.

 

Du kan jo sjekke med BankID, MinID, BuyPass og ikke minst OpenID. Alle disse tilbyr en autentiseringsløsning som det er mulig å implementere på samme sted samtidig.

[sda030]

Det er ikke et "problem" i seg selv å lage flere innloggingsrutiner på en og samme website/portal. Og det er heller ikke et "problem" at brukeren selv velger rutine og derav nivå på sikkerhet.

 

Problemet kommer når hver enkelt innloggingsrutine skal sikres.

 

Hva er vitsen om en webside er sikret med en løsning sikret med BankID, dersom samme webside også tilbyr pålogging via et enkelt brukernavn og passord? Websiden vil være like utsatt for eksterne trusler som om det kun var mulig å logge inn via et brukernavn og passord.

 

Så for å lage en god og brukbar løsning mener eg at man først og fremst må sette et minstekrav til sikkerhet. Hva er det minste du kan akseptere av sikkerhet for å godkjenne en bruker?

 

Du sier ikke så veldig mye om bakgrunnen for spørsmålet og derav er det også vanskelig å gi et konkret svar. Kort oppsummert, ja, det er mulig å lage en løsning med flere metoder for pålogging. Utfordringen ligger i å få kunden som krever den høyeste sikkerheten til å godta at det også er mulig til å logge seg på med den laveste sikkerheten dere har.

 

Du kan jo sjekke med BankID, MinID, BuyPass og ikke minst OpenID. Alle disse tilbyr en autentiseringsløsning som det er mulig å implementere på samme sted samtidig.

 

Takk for svar. For å presisere, det skal altså ikke være mulig å kunne logge inn med lav-sikkerhetsløsning om man har stilt inn på høy-sikkerhet. Om man i fremtiden vil skru ned nivået må man først logge inn med sin f.eks. BankID for så å justere i kontrollpanelet. Takk for OpenID tipset, skal sjekke det ut. Antar at det er bedre tilrettelagt og mer åpent for private initativ.

[nomore]

Men, hvem skal kunne justere sikkerhetsnivået? Om det er pr applikasjon så er det sikkert. Men om det er pr bruker så er jo applikasjonen kun så sikkert som det svakeste leddet.

[iChristian]

Hos altinn.no så har de jo gjort det slik at jo mer usikker innloggingsmuligheten er jo færre ting får du lov til å gjøre når du er innlogget.

[sda030]

Men, hvem skal kunne justere sikkerhetsnivået? Om det er pr applikasjon så er det sikkert. Men om det er pr bruker så er jo applikasjonen kun så sikkert som det svakeste leddet.

 

Er snakk om dataene til den enkelte bruker som er sensitivt, og ikke selve applikasjonen (opensource). Men er nettopp din kommentar jeg prøvde å fiske frem fordi jeg har overhørt noe lignende før. Det jeg/vi ikke forstår er hvordan hele applikasjonen blir svakere om noen få brukere har kun énfaktorinnlogging for sine egne data? Akkurat de dataene er riktignok svakt beskyttet, men blir det så et bristepunkt i hele strukturen? Om det er snakk om tilgang til kildekoden og endring av denne så får vel hackeren tilgang til denne uansett med sin BankID-konto?

 

Hos altinn.no så har de jo gjort det slik at jo mer usikker innloggingsmuligheten er jo færre ting får du lov til å gjøre når du er innlogget.

 

Æsj, det hadde vi jo "oppfunnet" allerede. men takk for tipset

[nomore]

Problemet, slik eg ser det, er at om du har for eks 20 brukere med kun brukernavn og passord, mens du har 80 brukere med BankID, da vil evnt innbrudd forsøke å få tilgang til systemet via de minst sikre brukerene. Ikke de mest sikre. Spørsmålet er jo, som du er inne på, hva får de tilgang til?

 

Vel, det er vanskelig å tenke ut alle mulige scenario. Men om man klarer å logge seg på som en bruker så er det jo ikke utenkelig at enkelte funksjoner/løsninger laget i applikasjonen er mer tilgjengelig enn om en ikke var pålogget i det hele tatt.

 

For eks. Om man har en medlemsdatabase med fullt navn, brukernavn, e-post, adresse og telefonnr som kun er tilgjengelig for påloggede brukere. La oss så tenke oss at 9 av 10 brukere bruker OpenID, mens en har valgt brukernavn og passord. Dersom en utenforstående da enten klarer å skaffe seg brukernavn og passord på en eller annen måte, eller klarer å kjøre brute-force angrep for å skaffe passordet, så vil den utenforstående ha tilgang til hele medlemsdatabasen. Dette er et enkelt og lett tenkelig eksempel.

 

Andre, mer avanserte muligheter, vil for eks være om man klarer å få tilgang til en større funksjon som kanskje sjekker brukernavn og passord direkte i applikasjonen. Eller lister kredittkortnummer. Eller fødsels og personnummer. Mulighetene er uendelige. Og informasjonen de kan få tilgang til trenger ikke å være åpenbart nyttig, men sammenhengen med flere informasjonskilder kan gi verdifull info(for enkelte). For eks om man klarer å hente ut ei liste med brukernavn og brukerid som man så kobler opp mot ei liste med transaksjoner koblet mot brukerid'er. Hver for seg har informasjonen liten eller ingen verdi, men samlet har den en sammenheng.

 

Og så er det muligheten for å kunne utnytte systemet for videre angrep ut. Kanskje det finnes en funksjon som ved via en brukerid gir en lov til å laste opp fil eller kode som kjøres skjult på serveren på alle besøkende? Eller tilgang til utsendelse av e-post. Osv. Mange scenarioer. Det kan være uskyldig.

 

Et eksempel her har jo vært Tele2 som tidligere tillot sjekk av fødsels og personnummer ved registrering. Dette ble raskt oppdaget og utnyttet for å generere lister med gyldige personnummer. Det hadde nok ikke utviklerene tenkt på når de lagde funksjonen. Koblet mot en annen datakilde, som for eks gulesider og skattelister så vil man fort kunne sitte med fullt navn, adresse, e-post, telefonnummer, personnummer, inntekt, gjeld osv. Informasjon som hver for seg er en kuriositet, men samlet kan gjøre mye skade.

[sda030]

Problemet, slik eg ser det, er at om du har for eks 20 brukere med kun brukernavn og passord, mens du har 80 brukere med BankID, da vil evnt innbrudd forsøke å få tilgang til systemet via de minst sikre brukerene. Ikke de mest sikre. Spørsmålet er jo, som du er inne på, hva får de tilgang til?

 

Vel, det er vanskelig å tenke ut alle mulige scenario. Men om man klarer å logge seg på som en bruker så er det jo ikke utenkelig at enkelte funksjoner/løsninger laget i applikasjonen er mer tilgjengelig enn om en ikke var pålogget i det hele tatt.

 

For eks. Om man har en medlemsdatabase med fullt navn, brukernavn, e-post, adresse og telefonnr som kun er tilgjengelig for påloggede brukere. La oss så tenke oss at 9 av 10 brukere bruker OpenID, mens en har valgt brukernavn og passord. Dersom en utenforstående da enten klarer å skaffe seg brukernavn og passord på en eller annen måte, eller klarer å kjøre brute-force angrep for å skaffe passordet, så vil den utenforstående ha tilgang til hele medlemsdatabasen. Dette er et enkelt og lett tenkelig eksempel.

 

Andre, mer avanserte muligheter, vil for eks være om man klarer å få tilgang til en større funksjon som kanskje sjekker brukernavn og passord direkte i applikasjonen. Eller lister kredittkortnummer. Eller fødsels og personnummer. Mulighetene er uendelige. Og informasjonen de kan få tilgang til trenger ikke å være åpenbart nyttig, men sammenhengen med flere informasjonskilder kan gi verdifull info(for enkelte). For eks om man klarer å hente ut ei liste med brukernavn og brukerid som man så kobler opp mot ei liste med transaksjoner koblet mot brukerid'er. Hver for seg har informasjonen liten eller ingen verdi, men samlet har den en sammenheng.

 

Og så er det muligheten for å kunne utnytte systemet for videre angrep ut. Kanskje det finnes en funksjon som ved via en brukerid gir en lov til å laste opp fil eller kode som kjøres skjult på serveren på alle besøkende? Eller tilgang til utsendelse av e-post. Osv. Mange scenarioer. Det kan være uskyldig.

 

Et eksempel her har jo vært Tele2 som tidligere tillot sjekk av fødsels og personnummer ved registrering. Dette ble raskt oppdaget og utnyttet for å generere lister med gyldige personnummer. Det hadde nok ikke utviklerene tenkt på når de lagde funksjonen. Koblet mot en annen datakilde, som for eks gulesider og skattelister så vil man fort kunne sitte med fullt navn, adresse, e-post, telefonnummer, personnummer, inntekt, gjeld osv. Informasjon som hver for seg er en kuriositet, men samlet kan gjøre mye skade.

 

Ah, nå forstår jeg. Ditt første eksempel med felles sensitiv informasjon for medlemmene er ikke relevant for oss. Det blir personlig sensitiv informasjon for hvert medlem og alle andre medlemmer vil være usynlige for den enkelte bruker. Det skal jo helst ikke være åpne sikkerhetshull som tillater at en bruker laster opp skript eller lignende (ditt tredje eksempel), [og vi kommer ikke til å åpne for den slags "fancy men usikre" funksjoner heller]. Uansett vil jeg si dette er en feil som utvikler gjør (menneskelig svikt) fremfor strukturell svikt? I hvert fall, om altinn.no og andre offentlige sider åpner for innlogging med flere sikkerhetsnivåer (fra smartkort til brukernavn/passord) så antar jeg det er mulig.

 

 

Tusen takk for svarene, det ser hittil ut som at det kan bli en forretning av dette.