Server 1 och server 2 tillhör inte banken, de tillhör inloggningstjänsten (till exempel de som Finansiell ID-Teknik BID AB har för Mobilt BankID).
Det bygger på att appen själv kan hantera dubbla inloggningsförsök om inloggningstjänstens servrar inte gör det, alltså att båda har fungerande logik för att stoppa dubbla försök. I en enkeltrådad app kommer ju paketen hanteras i den ordning de kommer, och paket som kommer in ligger i en paketbuffert tills någon kod läser det eller eventuell tidsgräns uppstår och paketet kastas. För att skydda mot dubbelinloggning på telefonsidan måste alltså appen antingen fortsätta läsa paket ur bufferten och jämföra med paketet som den håller på att hantera.
Nu var det ju ett hypotetiskt exempel för att demonstrera faran med att ha aktiv säkerhet som kan fallera öppen, men sannolikt kan samma inherenta säkerhetshål uppstå med Mobilt BankID.
Men detta blir bara mer icke underbyggd FUD. Det finns ingen anledning till varför ditt scenario skulle fungera, skulle kräva att både servrarna och telefonappen är trasig och att banken inte vet att två förfrågningar skickades samtidigt/nära varann, och att det är förfrågning ett som du godkänner i appen. Det är väl mer sannolikt att banken förväxlar två försök med inloggningssättet koddosa.
Principen bakom en födelsedagsattack är att det finns en icke-intuitiv sannolikhet att någon delar samma signifikanta nummer i en begränsad mängd. Alltså; om ett botnät testar personnummer finns det en icke-intuitiv sannolikhet att den testar samma personnummer som någon annan faktiskt använder samtidigt. Det är alltså en metod för att hitta en kollision av personnummer som har ett aktivt inloggningsförsök.
Hoppas det är tillräckligt tydligt denna gång då...
Fast detta är ingen födelsedagsattack, det är bara ett sätt att observera bankens system. BankID själv läcker inget där och du tar inte över inloggningen.
