Skrivet av Petterk:
Det du sade nej till var att du trodde det var ett säkerhetshål. Menar du att det är ett riktigt problem får du motivera varför, kan du inte visa det så är det väl ändå vad du tror eller trodde vid tiden du skrev inlägget. Har du inget argument att föra fram så finns det väl inget att diskutera?
Jag har inte sagt att det inte är ett säkerhetshål, jag har sagt att det inte är ett kryptografiskt säkerhetshål.
Skrivet av Petterk:
Nej du har inte länkat till principen bakom det du försökte beskriva, det du länkade hade inget med saken att göra.
Här är innehållet jag länkade till.
Skrivet av Wikipedia:
Understanding the problem
Main article: Birthday problem
As an example, consider the scenario in which a teacher with a class of 30 students (n = 30) asks for everybody's birthday (for simplicity, ignore leap years) to determine whether any two students have the same birthday (corresponding to a hash collision as described further). Intuitively, this chance may seem small. If the teacher picked a specific day (say, 16 September), then the chance that at least one student was born on that specific day is 1 − ( 364 / 365 ) 30 {\displaystyle 1-(364/365)^{30}} 1 - (364/365)^{30}, about 7.9%. However, counter-intuitively, the probability that at least one student has the same birthday as any other student on any day is around 70% (for n = 30), from the formula 1 − 365 ! / ( ( 365 − n ) ! ⋅ 365 n ) {\displaystyle 1-365!/((365-n)!\cdot 365^{n})} 1-365!/((365-n)!\cdot 365^n).[3]
Du får gärna förklara hur det inte är en beskrivning av principen bakom hur och varför en födelsedagsattack fungerar. Det finns en huvudartikel om det underliggande problemet också, men den är inte alls lika kortfattad. Här är länken till den.
Skrivet av Petterk:
Jag har beskrivit och motiverat varför dina inlägg inte var konsekventa och det är inte bara att jag inte kunde tro att du menade vad du försökte säga alltså att det skulle gå att kapa genom att försöka logga in samtidigt (precis före) och bli legitimerad istället för användarens session.
Det enda som inte har varit konsekvent är din tolkning av mina inlägg.
Skrivet av Petterk:
Att jag inte kunde tro på detta är för att det helt enkelt inte är en av svagheterna (bankerna hade inte tillåtet inloggning med Bankid om så var fallet, att det var ett grundläggande problem utan skydd) och jag trodde vi diskuterade verkliga scenarion.
Det är ett inherent problem med systemeringen. Du har ett steg i säkerhetsmodellen som bygger på att ett aktivt skydd utlöser (dubbelinloggning avbryter båda). Det viktiga här är skillnaden mellan "fallera öppen" och "fallera stängd", där ett system som antas sluta vara aktivt antingen släpper igenom respektive blockerar händelsekedjan.
I Mobilt BankID är det ett singulärt steg som avgör om det är en dubbelinloggning eller inte och i så fall avbryter händelsekedjan (i detta fall ett parallellt inloggningsförsök). Du har alltså ett enkelfel som kan ge resultatet att hela systemet fallerar öppet och att inloggningsförsöken inte avbryts. Det är ett högst reellt problem. Ingen kompetent utvecklare skulle systemera säkerhetslösningen på det sättet, oavsett hur många garantier som finns för att varje steg är buggfritt.
För att illustrera problemet, säg rent hypotetiskt att dina två inloggningsförsök går via två olika servrar av lastbalanseringsskäl. Det betyder att server 1 måste fråga server 2 om ett inloggningsförsök pågår på server 2 innan server 1 kan godkänna inloggningen.
När server 2 får frågan pågår inget inloggningsförsök, och server 1 skickar ett paket till telefonappen med en fråga om inloggning.
Server 2 får nu en fråga om inloggning på samma konto, men på grund av en bugg använder server 2 svaret den precis skickade till server 1 och avgör att server 1 inte känner till ett pågående inloggningsförsök. Server 2 skickar därför ett paket till telefonappen med en fråga om inloggning.
Telefonappen visar en fråga om inloggning på skärmen och användaren godkänner inloggningen med knappen.
Appen skickar då ett svar tillbaka till server 1 och server 1 skickar vidare svaret till tjänsten som efterfrågade inloggning.
Vad som händer med inloggningsförsöket via server 2 är odefinierat och ointressant, server 1 kan ha fått bedragarens inloggningsförsök. Därför är det ett allvarligt systemeringsfel.
Att bankerna kan använda det för inloggning säger inte lika mycket som du tror, har hört relativt nyligen om amerikanska banker som kör enkelt lösenord skickat i klartext över HTTPS. Där kan ett enkelfel (HTTPS) också sabba hela systemets säkerhet.
Riktiga säkerhetslösningar ska behöva minst dubbelfel och fallera stängt, till exempel genom att komplement till en asymmetrisk nyckel saknas. Som i första iterationen av BankID innan de förstörde allt till förmån av användarvänlighet.
Skrivet av Petterk:
Jag kan inte veta hur folk motiverar saker i sina egna huvuden, det är skribenternas jobb att göra sitt bästa för att göra sig förstådd och komma med åsikter och argument som går att tyda och kommunicerar vad de vill säga. Blandar man olika saker blir det svårare.
Visserligen sant, men när dina deltolkningar av mina inlägg börjar glida isär borde du å andra sidan också börja inse att du kanske har misstolkat något.
