login timing attacks...
Verfasst: Mittwoch 13. Mai 2015, 16:16
Ich möchte gern das Thema ganz allgemein nochmal aufgreifen...
Hab gerade entdeckt, das django einiges an Aufwand betreibt um timing attacks beim Login möglichst zu verhindern: https://code.djangoproject.com/ticket/20760
Das Prinzip ist einfach: Es wird versucht den selben Code-Pfad zu nehmen, egal. oder der Benutzername/Passwort richtig/falsch sind.
Somit sollte am Ende jeder Request ähnlich gleich lange dauern...
Im Ticket wird auch über eine Künstliche-Zufalls-Verzögerung gesprochen. Langsame wird mir auch klar, warum das nicht funktionieren kann:
Man müßte im Prinzip doch möglichst genau die Zeit eines normalen Logins treffen, damit der Unterschied nicht sichtbar ist.
Aber das bringt mich auf eine Idee: Warum nicht die Zeit messen, wie lange ein erfolgreicher Login benötigt und dann einen delay basierend darauf erzeugen?!?
Natürlich Live Messen und nicht einen Messwert Hardcoden
Evtl. die letzten x-erfolgreichen Logins mitteln...
Das muss ich mal testen
Aber zum eigentlichen Problem: Was versucht man da eigentlich zu verhindern?!? Bzw. was kann man durch einen "timing attack" überhaupt erreichen?
Doch letztlich nur prüfen, ob ein Benutzername existiert oder nicht... Oder? Das ist bei einigen Webseiten außerdem kein großes Geheimnis. z.B. die meisten Foren haben Benutzerlisten.
...und das ganze ist nur Praktikabel, wenn es keine DOS-Abwehrmaßnamen gibt. Denn man benötigt ja eine große Messbasis...
Würde also nicht ein "Login-Versuch-Zeit-Limit" nicht generell mehr Schützen?
Außerdem ist diese "Gleichezeit für Loginversuche" irgendwie eine Sinnlose CPU Verschwendung...
Hab gerade entdeckt, das django einiges an Aufwand betreibt um timing attacks beim Login möglichst zu verhindern: https://code.djangoproject.com/ticket/20760
Das Prinzip ist einfach: Es wird versucht den selben Code-Pfad zu nehmen, egal. oder der Benutzername/Passwort richtig/falsch sind.
Somit sollte am Ende jeder Request ähnlich gleich lange dauern...
Im Ticket wird auch über eine Künstliche-Zufalls-Verzögerung gesprochen. Langsame wird mir auch klar, warum das nicht funktionieren kann:
Man müßte im Prinzip doch möglichst genau die Zeit eines normalen Logins treffen, damit der Unterschied nicht sichtbar ist.
Aber das bringt mich auf eine Idee: Warum nicht die Zeit messen, wie lange ein erfolgreicher Login benötigt und dann einen delay basierend darauf erzeugen?!?
Natürlich Live Messen und nicht einen Messwert Hardcoden
Evtl. die letzten x-erfolgreichen Logins mitteln...
Das muss ich mal testen
Aber zum eigentlichen Problem: Was versucht man da eigentlich zu verhindern?!? Bzw. was kann man durch einen "timing attack" überhaupt erreichen?
Doch letztlich nur prüfen, ob ein Benutzername existiert oder nicht... Oder? Das ist bei einigen Webseiten außerdem kein großes Geheimnis. z.B. die meisten Foren haben Benutzerlisten.
...und das ganze ist nur Praktikabel, wenn es keine DOS-Abwehrmaßnamen gibt. Denn man benötigt ja eine große Messbasis...
Würde also nicht ein "Login-Versuch-Zeit-Limit" nicht generell mehr Schützen?
Außerdem ist diese "Gleichezeit für Loginversuche" irgendwie eine Sinnlose CPU Verschwendung...