Klara sig utan Bank-ID

Risken finns ju att det finns nån bugg där. det går inte utesluta till 100% men det bör vara en del av koden som är testad och granskad mycket omsorgsfullt.

Jo, bedragaren försöker logga in på din bank, du startar bankid-appen o knappar in koden och sen trycker på login på browsern. Det är ju så de flesta bedrägerierna går till men du gör då aldrig det sista steget. Sen finns det i realiteten ingen anledning att göra på det sättet annat än att bedragaren säger att man ska göra det.

BankID på fil finns i varianter från 3 månader till 2 år.

I grunden är OTP sårbart för race-attack, men idag kräver det att också att den krypterade förbindelsen är kompromissad. Hinner du först spelar det ingen roll vilket skydd som finns mot att använda lösenord mer än en gång.

På precis samma sätt som telefoners identitet brukar klonas efter hackning? Kopiera informationen som identiteten byggs från (IMEI, privat nyckel, salt, etc.).

Det bör det ju vara ja, men just det faktum att en bugg skulle tillåta inloggningen istället för att stoppa den är det som är fel i systemeringen. Alla steg i säkerhetsmodellen ska bygga på att det finns ett särskilt utfall som går igenom. I detta fall finns det minst ett steg där det finns ett särskilt utfall som inte går igenom.

Att bygga en säkerhetsmodell som fungerar på det viset är inte på något sätt trivialt och det läggs massor av tid och pengar på att utveckla dem, men när de är färdiga att implementeras brukar de vara väldigt väl genomtänkta.

Så om du startar appen först och gör alla förberedande steg innan du klickar på inloggningsknappen på din dator, ser den inte det dubbla försöket då? Är det korrekt tolkat?

Nej. Den "token" som OTP genererar är giltig exakt en gång och genereras genom en kryptografisk irreversibel funktion. För att ett kapplöpningsscenario ska uppstå måste angriparen kunna skicka en identisk (eller likvärdig beroende på implementation) "token". För att det läget ska kunna uppstå rent matematiskt har du redan haft en lyckad attack i ett tidigare steg, till exempel MITM eller klonad identitet (nyckel/salt/implementationsberoende etc.). Ansvar för säker förvaring och transport av en "token", eller identiteten den genereras från, ligger inte i OTP.

Bankerna använder i hög grad inte challenge-response för inloggning, så banken har inte skickat någon kontrollkod till användaren eller bedragaren. Bankerna kan alltså inte göra någon skillnad mellan olika sessioner.

Flera OTP-system som använts var såbara för flera attacker, bland annat en race-attack. I dagsläget kräver det som sagt att krypteringen som skyddar kommunikationen är ur funktion eller sårbar, men det har funnits flera allvarliga sårbarheter när det gäller implementeringarna av krypteringsprotokoll genom åren. Attacken kräver bara att du är först, så jag syftar inte på en replay-attack. Det är alltså något som går att utnyttja utan att köra MITM och är ett grundläggande problem i OTP-modellen.

S/KEY t.ex.

Du får ju uppmaningen att mata in säkerhetskoden från bankid också, så förutsätter att du gör det. Då kommer bedragaren in. Sen klickar du på inloggningsknappen på datorn. Då får du igen mata in säkerhetskoden för den "andra" inloggningen. Iom att du gjort det så kommer du in och bedragaren blir utestängd.

Så är det telefon-bedrägeri gäller det för bedragaren att se till att du *inte* går in själv innan han hinner göra det ha ska.

Nä, så funkar det inte annat än om tjänsteleverantören ("hemsidan") valt att bygga det så, dvs att man själv håller koll på att samma användare loggar in igen. Man måste komma ihåg att BankID handlar om autentisering, inte auktorisering. Det är upp till applikationen att sköta det senare.

Det kan tilläggas att e-legitimation från början byggde på riktiga klientcertifikat som behövde vara tillgängliga vid varje sidladdning och fanns dom inte längre så klippte man direkt (typ om någon dragit ur kortet ur kortläsaren). Så är det inte längre.

Jo, ska kanske tillägga det gäller Swedbank, har inte provat mot mot nån annan. Men då betyder det att det kan vara två inloggade samtidigt beroende på bank/sida då? Alternativet vore att neka den andra inloggningen... men lär bli problem för kunden om browsern/datorn kraschat strax efter inloggning.

Det går att logga in flera olika sessioner med BankID, det är helt upp till de du loggar in hos hur de gör där, men är du snabb och t.ex. trycker på logga in samtidigt som du precis skrev in din säkerhetskod så kommer den pågående legitimeringen att avbrytas. Tar någon sekund eller så efter du legitimerat dig i appen innan sidan som vill ha legitimeringen får svar från BankIDs system.

Säkraste bör vara att använda BankID på samma enhet som du loggar in med om de inte stödjer QR-kod, länken (från sidan/appen) som öppnar BankID-appen innehåller en unik token och är inte något helgalet så ska det vara denna sida/app och således sessionen du startade du legitimerar. Det är väl därför QR-kod inte är något krav om man kör BankID på samma enhet, @improwise bör ha bättre koll på RP än vad jag har dock.

Telefoner från ~2013 kan köra Android L/5 med tillverkarens egna officiella uppdateringar. 5-6 år gamla telefoner alltså. Köpa ny telefon en gång var femte år för att kunna använda dagens tjänster är acceptabelt. Att logga in med BankID på fil eller kort är ungefär lika mycket jobb som med koddosan, och för de banker där BankID:t ligger på bankkortet så måste du ju ändå använda dosan med kortläsare BankID på fil hjälper dig ju inte att betala kaffet på kaféet som tar Swish.

Det är helt och hållet upp till till det aktuella systemet. I en internetbank är det kanske lämpligt att förhindra det, men om man t.ex. loggar in hos frisören för att boka en tid för hårinpackning är det kanske inte lika kritiskt.

Min bild är att man ofta missförstår vad BankID är och inte är. Det vanliga är att man, som en del diskussioner i denna tråd, utgå ifrån att det handlar om säkerhet osv. Det gör det på sätt och vis, men då i form av autentisering/identifikation. Det kan lika väl vara att man identiferar sig för att t.ex. fylla i en låneansökan på nätet där det inte finns någon inloggning alls. Det är med andra ord upp till applikationen att hantera säkerheten, med hjälp av BankID som identifikation. De säkerhetsfunktioner som finns inbyggda i BankID och dess tjänst handlar främst om attt säkerställa identifiationen, dvs att jag inte kan påstå mig vara någon annan än den jag är. Att däremot hålla koll på sessioner och annat är inte BankIDs uppgift.

Det är tom så att QR koden ÄR den unika token. QR koden genereras med samma token som används för ifall klienten körs på samma enhet som webbläsaren (eller vad det nu är man kör). Är rätt övertygad om att QR koder i framtiden kommer bli det enda sättet att legitimera sig med "BankID på annan enhet" (i folkmun ofta kallat för Mobilt BankID).

Ja, så jag verkar ha fattat rätt där.

Är man uteslutande GNU/Linux-användare och vill logga in på banken på datorn säkert får man alltså köra Handelsbanken, eller nöja sig med att använda internetbanken i telefonen eller med en sladdlös koddosa. Hur som är det ju ändå bättre situation än när BankID-appen fanns till Linux eftersom alla tjänster finns i telefonen idag. Själv ser jag dock ingen större risk för att någon skulle raca mitt inloggningsförsök även utan token, görs två försök inom någon ospecificerad tidsram så avbryts t.o.m. en legitimering där fingeravtryck eller säkerhetskod redan har hunnit användas. Görs det med 5-10 sekunder emellan så visst, då kan du logga in både bedragare och dig själv. Ganska säker på att detta redan gällde 2009-2011 när bankerna började tillåta BankID för inloggning dock, alltså att du hade kunnat logga in flera gånger på samma tjänst.

Så ja, jag kan inte direkt tycka att det blivit sämre än när BankID-appen fanns till Linux. Vill man inte längre använda BankID för att det inte längre finns till Linux, så ja då får man vara utan BankID i telefonen och alla tjänster som bara finns där, så som Swish, Kivra, SecureCode, Masterpass o.s.v. Mastercard SecureCode och Verified by Visa kan du köra 2FA över SMS istället, Swish och digital brevlåda kan du inte använda utan BankID (någon digital brevlåda tillåter Telia e-leg, men det ges ju inte ut till privatpersoner längre). Hur som helst, jag ser inte varför man vill måla upp det som en mer osäker lösning än när BankID version 4.19* fanns till Linux och fortfarande gick att använda.

Verified by VISA kräver väl inte BankID heller. Jag har använt PIN-kod och koddosa, inte BankID.
Jag skrev det i min kommentar på första sidan.

Åh, har du någonsin sniffat en IP-adress som varit kopplad direkt till nätet utan brandvägg emellan?
Det finns mängder av servrar där ute som kontinuerligt går igenom IP-adressrymder efter öppna portar.

Gör inte Mastercard SecureCode heller som sagt, de flesta banker kan köra tvåfaktor över SMS för det. Verified by Visa får du nog lov att använda med BankID om du befinner dig hemifrån också eller tvåfaktor över SMS. Du går nog inte runt med din bankdosa. Min bank kan köra antingen BankID eller kod över SMS oavsett om du har VISA eller Mastercard. Jag skrev alltså (#17844658) att Verified by Visa inte kräver BankID långt innan inlägget du citerade, och har förtydligat att man kan välja vilket man vill köra i de senare inläggen.

Ja, men då har du motsagt dig själv.

Det inlägget handlade nog mer om BankID på kort vs Mobilt BankID. Alltså Mobilt BankID bär man med sig och då bär man också med sig nämnda tjänster. I inlägget innan ditt från igår kväll så var jag tydlig med att engångskod via SMS är ett alternativ för både Mastercard och Visa. Mitt första inlägg i tråden var att påpeka att Swedbank (och sparbankerna) inte kräver Mobilt BankID för att använda sig av säkerhetsfunktionerna från kortföretagen, eftersom TS (@Youma) var av uppfattningen att det krävdes. När dessa system inte används av handlarna/betallösningen så går såklart betalningen igenom utan att du godkänner den med engångskod eller Mobilt BankID, och det skapade lite förvirring i tråden.

Vet inte hur det är på din bank, men på min behöver jag mata in två koder från bankens inloggningssida i dosan innan den ger en kod tillbaka. Det tyder ju hyfsat definitivt på challenge-response och utan de två koderna kommer du inte in alls (om du inte har slagit på BankID då).

Det du beskriver är en attack av implementationen. Närmare bestämt bygger det på att sista tecknet tidsmässigt går att separera ut från resten av strängen, att du har lyckats fånga de tidigare tecknen och att du hinner köra "brute force" på sista tecknet innan rätt tecken kommer från användaren. Det är visserligen en kapplöpningsattack men den tillkommer genom en svag implementation, inte som en inherent svaghet i OTP.

Åter igen måste du skilja på svagheter i säkerhetsmodellen och i implementationen.

Ok, då förstår jag.

Så nu säger du att det finns en kapplöpningsattack mot säkerhetsmodellen i Mobilt BankID? Bra, då var den saken avklarad.

Jag ser det inte som en acceptabel situation att det ska ställas krav på proprietär mjukvara för något som ska vara "säkert". Gemene man behöver betala pengar till ett amerikanskt företag för proprietär mjukvara innan de kan köra BankID, oavsett om det är för Windows/Mac OS eller en telefon med stängda drivare.

Är det säkert på riktigt ska det inte finnas något tekniskt hinder för att fritt släppa källkoden och/eller tillräcklig dokumentation för tredjepartsimplementationer.

Det är nog för att du har missat eller missförstått signifikansen i att skilja på hål i säkerhetsmodell och hål i implementation.

• Hål i en säkerhetsmodell måste aktivt arbetas runt i en implementation för att den inte ska släppa igenom angripare.

• Hål i en implementation kan gå åt båda hållen beroende på den individuella buggen.

Den tidigare gör att du måste lägga ner tid på att lösa teoretiska säkerhetsproblem när du skriver i implementationen. Den senare betyder att du på något sätt ignorerar säkerhetsmodellen i implementationen.

Du kan likna det efter konstruktionen av en klassisk ficklampa;
"Säkerhetsmodellen":

• Det ska gå ström genom lampan när strömbrytaren är i läget "på"

• Det ska inte gå ström genom lampan när strömbrytaren är i läget "av"

Implementationen:

• När strömbrytaren är i läget "på" kopplas batteriets ena pol genom två metalltungor i brytaren till ena änden av lampan

• När strömbrytaren är i läget "av" separeras metalltungorna ovan genom att den ena lyfts från den andra

• Allt monteras i ett hölje så att bara det interna batteriet kan driva lampan

Det uppstår nu två "säkerhetsproblem"; den första är att om man trycker hårt ned på strömbrytaren tänds lampan även i läget "av", den andra är att man kan koppla ett batteri till mellan två delar av höljet så att lampan lyser utan ett internt batteri.

Det första problemet beror på implementationen; metalltungorna i strömbrytaren kan pressas ihop igen trots att den står i läget "av". Strömbrytaren uppfyller helt enkelt inte kraven för säkerhetsmodellen.

Den andra beror på säkerhetsmodellen; att lampan inte skulle gå att slå på med ett annat batteri än det interna var inte en del av säkerhetsmodellen och är istället en efterhandskonstruktion i implementationen.

Hoppas det klarar upp situationen för dig.

Det är snarare en feature. Det är bankerna som tillåter flera inloggningar, det gör de med koddosa också. Bankerna kan låsa det till en inloggning, och de kan låsa så man inte kan logga in utan token (QR-kod eller att man kör BankID på samma enhet). Jag har aldrig påstått att bankerna inte tillåter flera inloggningar, så du kommer bara med ett argumentationsfel.

Inga alternativ stödjer alternativa mobiloperativsystem. SecMakers Net iD stödjer visserligen Linux när du kör med smartkort som inte längre går att skaffa som privatperson (Telia E-legitimation), så gör även Gemaltos Sconnect som används för AB Svenska Pass smartkort. Deras mobila varianter är uteslutande för Android och iOS däremot. Freja eID+ från Verisec stödjer bara Android och iOS.

Forex kör Forex ID-appen istället för koddosa, ger skydd mot MitB och MITM (delvis) då det blir tydligt vad du godkänner, men i dagarna har de börjat ge ut Mobilt BankID och du kan såklart använda det istället.

Givetvis har de som utvecklar dessa program inget intresse av att stödja hur gamla operativsystem som helst, eftersom det är extra jobb. Har nog väldigt lite med säkerhet att göra. Blir givetvis mer jobb att hålla reda på fler klienter för den delen, och det är kommersiella företag som utvecklar lösningarna, så de vill såklart sälja de också.

Missförstod vad du menade, trodde att du beskrev samtida inloggningsförsök. Var ganska trött när jag läste inlägget första gången.

Är inte intresserad av en telefonapp. Är intresserad av säkerhetslösningar som fungerar i GNU/Linux (eller annat fritt OS) och helst utan en proprietär implementation (tillåter bara undantagsfall på mina datorer).

Eller så kan man statiskt länka in de bibliotek som behövs på egen hand. Skulle till exempel inte säga nej till nyare version av OpenSSL än vad som ingår i Android. Om det behövs mer än hårdvaruabstraktion så förlitar den sig på att existerande bibliotek är säkra (vilket de ofta är, men samtidigt är det inte en försumbar attackvektor). Dynamiska länkare har missbrukats för att introducera säkerhetshål tidigare och metoden kommer antagligen att fortsätta användas så länge dynamiska länkare existerar.

Argumentet att det blir mer jobb att hålla efter fler klienter är inte riktigt applicerbart på en öppen specifikation om du har en bra säkerhetsmodell. Fler klienter betyder att fler använder lösningen, vilket leder till att fler företag vill implementera lösningen, vilket leder till fler som använder lösningen. Enda säkerhetsmässing anledningen till att de inte skulle vilja släppa specifikationen öppet är om en del av säkerhetsmodellen hänger på klientsidan, alltså i detta fall telefonappen Mobilt BankID.

Till exempel skyddet mot dubbelinloggning som du tidigare har påstått finns i telefonappen.

Jag förstår det, men det är ett ställningstagande du gjort och som du inte gjorde medan BankID 4.19 (och tidigare) fortfarande fungerade på Linux. Det har alltså inte med säkerhet att göra.

Ser inte att ställningstagandet är i konflikt med den tidigare implementationen av BankID på dator. Aldrig använt Mobilt BankID och BankID på dator var en av de undantagna proprietära programmen.

Det har absolut med säkerhet att göra. Jag skulle aldrig utföra bankärenden genom en Windows-baserad klient i dagsläget. Vidare är bankdosan fortfarande relativt säker.

Dessutom är säkerhetsmodellen i Mobilt BankID skräp, såsom jag tidigare har förklarat. Att den nuvarande implementationen står mot den uppenbara kapplöpningsattacken är en mycket liten tröst i sammanhanget.

Nej, allt är inte implementationsberoende och det är ett väldigt bisarrt påstående. Säkerhetsmodeller är inte implementationsberoende, det är liksom en del av definitionen. Det enda som är implementationsberoende kring säkerhetsmodeller är huruvida de faktiskt implementerar säkerhetsmodellen eller inte.

Du har inte ens lyckats framföra något stöd för det påståendet. Att dina åsikter om proprietär mjukvara skiljer sig från mina blidar inte ett objektivt argument för att mina slutsatser är fel.

Nej det var den inte heller.

Vid ett inloggningsförsök skickade browsern en sessionsbaserad förfrågan till klienten på samma dator, som generarade ett svar med hjälp av signering med den lokala privata nyckeln (challenge-response). Det gick inte att svara med en annan dator även om den hade din privata nyckel, eftersom sessionens förfrågan inte var känd.

Den klient som vi diskuterar, Mobilt BankID, bygger på en helt annan säkerhetsmodell som jag inte tänker upprepa ytterligare en gång.

Skickades från m.sweclockers.com

Återigen, använder du BankID på samma enhet öppnas BankID-programmet med en unik token och du kan inte godkänna något annat än hemsidan/programmet efterfrågar.

Måste du använda BankID på annan enhet än du loggar in på så använd bara tjänster som aktiverat QR-kod. Handelsbanken är enda banken i dagsläget, men andra banker använder leverantörer som redan har stöd för QR-kod i produkten och behöver bara aktivera det. Detta har redan sagts i klartext minst ett par gånger tidigare.

Kan du använda en telefon (du postar här med telefon) kan du rimligen använda BankID. Kanske inte för att logga in på din bank på Linux, men väl i telefonen.

Och du tror att jag besöker banken via telefonen om jag har ett val? Såsom jag skrev för några inlägg sedan kantas Android av proprietär kod.

Eller så kan man begränsa inloggningarna till de som alltid är challenge-response med dosan.

Till att börja med är Android ett låtsasöppet OS utvecklat nästan enbart av Google sedan många år tillbaka. Detta är min sista Androidbaserade telefon, så att skaffa på sig Mobilt BankID (även om jag hade haft något förtroende kvar för lösningen) hade varit tvättäkta vansinne.

Värt att nämna är att SweClockers mobila sida även fungerade med både Ubuntu Touch senast jag testade och framtvingat i vanlig webläsare (relevant för diverse små enheter jag har, t.ex. Raspberry Pi med pekskärm).

Om du sedan på något sätt försöker dra argumentet att jag bör använda Mobilt BankID eftersom jag ändå loggar in på SweClockers med telefonen, saknar jag ord för att ordentligt besvara ett så tondövt påstående.

Skickades från m.sweclockers.com