Säkerhetshål Bank-ID

Återkom när du förstår att bankid-appen använder kanal som är helt separerad från webbsessionen som blir inloggad och att dessa inte ens behöver gå över samma nätverk. Tills dess kan du väl låta de vuxna prata, ska vi säga så?

Ja, du har rätt, om du med autentisering menar något som sker med sådan kontroll över hela proceduren som kan ske t ex med android appar och tokens. Men som jag skrivit ovan så är det väl problem med sådan kontroll i en så fritt blandat miljö som bankid.

I exemplet du citerar så är det alltså pensionsmyndighetens kösystem, och inte kön i bankid, som är problemet.

Jag har sett några andra underligheter på olika webbsidor som använder bankid. En är att inloggningen sker med personnummer, men inte på ett konsekvent sätt. Ibland krävs att personnumret anges med århundrade, ibland krävs att detta inte sker. Denna brist på standard kanske låter ofarlig, men skulle kunna exploateras på något finurligt sätt. En annan underlighet är att anropet av bankid sker genom ett direkt brott mot "same origin policy" https://en.wikipedia.org/wiki/Same-origin_policy. Denna kan vara så klantigt implementerad på vissa sidor att man kan få en varning för cross side scripting exploit i webbläsaren!

Ja och det finns även fördelar rent säkerhetsmässigt med att använda en separat kanal för identifiering så att bara lyfta fram det som ett problem är inte balanserat. Det gäller att inse att det inte finns någon säkerhetslösning utan svagheter, speciellt inte när man inkluderar en mindre begåvad användare i lösningen. Det är ofta de mänskliga elementen i lösningen som attackeras och inte de rent tekniska.

Kanal? Så varje server som hanterar tusentals klienter måste ha en separat kanal för varje en av dessa? Det måste bli en riktigt fet kabel då som borde bli flera meter i diameter. Jag ska förklara så att även du fattar. När du besöker en sida så skapas en nyckel för att hålla reda på vilken klient det är som efterfrågar informationen, men informationen går på samma lina som alla andras.

Felet Bank-ID gjort är att de inte använder nycklar, därför kan en inloggad persons sida visas av alla.


Och det är just därför man använder nycklar och inte "kanaler"


Tycker du ska gå till Akademibokhandeln och köpa dig en riktigt fet datorbok innan du postar mer, ska vi säga så?

Jaså kan en inloggad persons sida visas av alla med bankid, hur skulle det gå till menar du? När man väl är inloggad har bankid överhuvudtaget inget med den saken att göra.

Bankid används för identifiering och signering, inte för att hantera sidaccess.

Det är så mycket du inte förstår när det gäller detta så du behöver börja med en grundkurs.

Nej, finns inget problem med implementeringen eftersom autentisering går att göra på dator, android, iphone, dessa operativsystem har färdiga API:er för detta.


Bank-ID och E-leg(pensionsmyndigheten exemplet ovan) är samma sak. De går under namnet E-legitimation.
https://sv.wikipedia.org/wiki/E-legitimation

Du kritiserar användandet av begreppet kanal här, och det lägger jag mig inte i, för ni två har något eget tjaffs på gång som kräver att ni hyr ett rum. Men jag undrar vad du menar med nycklar i detta specifika sammanhang.

"När du besöker en sida så skapas en nyckel"

För att ta en annan teknik, 2-Step Verification med Google Authenticator, vad är nyckeln där?

Det är uppenbart ingenting som har med http att göra, ej heller med kryptering. Det har inget som helst att göra med någon sessionshantering genom cookies eller andra objekt.

Vad jag kan se så skapas helt enkelt ingen 'nyckel' av det slag du antyder med google's 2 step. Och inte heller med bankid.

Tack för upplysningen. Jag har ju inte bara redogjort för detta i detalj i tidigare trådar, utan även återgivit information om upphandling m.m som jag inhämtat genom kommunikation med E-legitimationsnämnden och andra myndigheter.

Men det är ju helt irrelevant för vad jag talar om, nämligen skillnaden mellan kösystemet i bankid och kösystemet i en webbapplikation. Bankid har ett kösystem där de har en spärr mot två samtidiga inloggningar.

En webbserver kan sätta detta kösystem ur spel genom att implementera sitt eget kösystem, och inte tala om för de som implementerar bankid att det finns flera sessioner igång. Och det är vad pensionsmyndigheten gjorde, och trodde att de var finurliga.

För att du ska lära dig begreppet kanal:

Grundtesen är att de flesta knappar in sitt lösenord och sedan kontrollsiffrorna från bankdosan direkt i sin webbläsare. Du skickar all din inloggningsinformation på en kanal. I Ubiqo Usafe delas informationen upp på två separata kanaler och den blir därför också svårare att avlyssna, säger Patrik Hall, vd på Sigma.
http://computersweden.idg.se/2.2683/...tter-bankdosan

Här tycker jag att du har missförstått något ganska ordentligt. Du talar som jag skrev tydligen om en enda miljö där man har full kontroll. Men det vi talar om i tråden är multi-factor authentication i en miljö med flera olika system och inte bundna till något som kan identifieras som en viss session m.m.

Nej, att överföra all inloggningsinformation över en kanal är INTE osäkert, förutsatt att implementationen är säker.

Tvärtom, är det faktiskt säkrare att överföra allt över en kanal, eftersom då kan inloggningsinformationen som överförs låsas till information som har med kanalen att göra (ex: IP-adress, browser, tidpunkt, annan information som t.ex. ifyllda uppgifter m.m.), och därmed omöjliggöra att sessionen stjäls/manipuleras.
Det gör att även om en angripare lyckas avlyssna eller manipulera sessionen, så kommer genererad inloggningsinformation bli ogiltig, till skillnad från tvåkanals där det inte finns någon sådan koppling.

Problemet med att överföra allt över 2 kanaler är att det inte finns någon inbördes koppling mellan de 2 kanalerna. Det är det som är osäkerheten i BankID, eftersom man inte kan avgöra vilken den andra kanalen är. Om BankID istället hade varit konstruerat via t.ex. scanning av QR-kod och sedan kommer det upp information i mobilens skärm som man ska fylla i vid legitimering, så hade det varit säkrare. (Signering skulle kunna ske genom scanning av QR och sedan skickas den signerade informationen via nätet).

Det viktiga är inte att förhindra att inloggningsinformationen avlyssnas, för förr eller senare kommer någon komma fram till ett sätt att avlyssna informationen, oavsett om det sker via röjande signaler, skadlig mjukvara, axelsurfning eller vanlig avlyssning av radiosignaler eller över nätet.
Det viktiga är att den avlyssnade inloggningsinformationen skall vara värdelös i en angripares händer.

Att använda 2-kanals-autensitering är vettigt som en nekande åtgärd, till exempel vid kreditkortsköp, möjlighet att godkänna eller neka köpet.
Här läggs autensiteringen över ett system som redan har mycket säker autensitering (chippet med utbyte av nycklar över samma kanal), med andra ord läggs ett tvåkanals system över ett tvåfaktors.

Med andra ord, skall, om man vill ha det säkert, tvåkanals autensitering användas som komplement till tvåfaktors autensitering.

Allting är osäkert i något avseende och bankid har valt att använda två kanaler eftersom det ger en del fördelar, både säkerhetsmässiga och användarmässiga.

Man ska heller inte glömma bort att det är en stor utmaning att göra något så enkelt att alla kan använda det, även de mest korkade användarna. Trots enkelheten ska det ge hög säkerhet.

Mobilt bankid gjorde stora framsteg här jämfört med tex den ursprungliga bankid på fil eller kort. Sedan har lösningen för fil och kort gått mot samma lösning som mobilt bankid.