Timing-Angriffe bedrohen viele Web-Anwendungen

Sicherheitslücken Auf der Hackerkonferenz "Black Hat" wollen die Security-Forscher Nate Lawson und Taylor Nelson zeigen, dass zahlreiche Web-Anwendungen anfällig gegen so genannte Timing-Angriffe sind. mehr...

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
öhm... wenn die anwendung blöd genug ist, das pw im klartext zu speichern, oder wie?
 
@tofu-sensei: Nee, es geht ja nur um die Reaktionszeit des Authentifizierungs-Systems. Stell dir das so vor, dass jede mögliche Anfangsziffer 1 Nanosekunde für die Reaktion des Systems braucht, um dieses Passwort als falsch zu erkennen. Die richtige Anfangsziffer aber länger, z. B. 4 Nanosekungen.

Nachtrag: Welches Zeichen also eine längere Reaktionszeit verursacht, ist richtig.
 
@ska-fighter: eigentlich hat tofu-sensei aber recht.
Das sollte so nur auftreten, wenn das Passwort im Klartext gepspeichert ist, denn so wird das Passwort direkt verglichen und je mehr Buchstaben von Anfang an übereinstimmen, desto länger dauert die Überprüfung.
Wenn ein Passwort allerdings nur als Hash abgespeichert ist, so stimmen beide Hashes nur bei 100% gleichen Passwörtern überein.
Wenn das eingegeben Passwort auch nur 1 falschen Buchstaben hat, so wird daraus ein völlig anderer Hash erstellt, sodass man diese Timing-Methode eigentlich nicht mehr anwenden können sollte.
 
@t-master: du hast leider nur bedingt recht. ich kann durch die antwortzeit auf den hash schließen und es ist sehr wahrscheinlich, dass dieser hash mit klartext sich in einer guten rainbowtable finden lässt. (Eine Rainbowtabelle enthält sehr viele Hashes mit dem dazugehörigen pw, sowas kann man kaufen - es sind teils GB bis TB große Dateien. Bis ca. 6 Zeichen kann man das auch so noch locker selber generieren auf die "Schnelle")
 
@orioon: ich behaupte mal, daß du genau das eben nicht kannst.

edit: na sowas, es geht gar nicht um paßwörter...
http://u.nu/3g3dd
 
@ska-fighter: Wenn ich das richtig Verstanden habe, müsste ich an meinen Prüfalgorythmus nur einen Random-Timer hängen der ein paar ms wartet und schon habe ich das Problem umgangen?
 
@ska-fighter: Ist es nicht so, dass die übertragenen Passwörter in den Hash-Wert umgewandelt und dann mit dem Hash-Wert des Passworts der Datenbank vergleichen werden? Da aber ein Buchstabe schon den gesamten Hash-Wert verändert braucht das System keine längere Reaktionszeit wenn ein Buchstabe richtig ist. Das Ganze funktioniert wirklich nur, wenn die Klartextpasswörter verglichen werden, oder sehe ich das falsch?

Edit:// Ah, da war jemand schneller^^
 
@Jack992: Siehe t-master vor dir. Wer die Passwoerter im Klartext speichert gehoert eh gepruegelt.
 
boah, wenn mit zunehmender Länger die Anzahl der Möglichkeiten/Zeitaufwand nur noch linear steigt, dann sollten die Webanwender schleunigst diese Sicherheitslücke schließen...
 
@XP SP4: Diese Sicherheitslücke besteht nur bei Passwörtern die im Klartext gespeichert werden. Das allerdings, ist schon eine Sicherheitslücke, die gar nicht auftreten sollte. Als Beispiel mit md5: aus Hallo wird "d1bf93299de1b68e6d382c893bf1215f" und aus Hallo1 "41913350e6b4f576ce9329aad5cba548". So kann diese Methode nicht funktionieren ;)
 
Warum brauchen die Mechanismen alle länger, wenn das erste Zeichen stimmt? Hat das halbe Internet Kacke programmiert oder wie kann das sein?
 
@Zaru: Das Authentifizierungs-System braucht länger, um zu erkennen, dass das Passwort falsch ist. Das System fängt wahrscheinlich beim ersten Buchstaben an und geht dann immer weiter...
 
@Zaru: Nein - ganz einfach, ein Vergleich des Passworts passiert Zeichen für Zeichen (für Entwickler hier, der String ist ja ein Char-Array und wir einfach in einer Zählschleife verglichen) verglichen. Das heißt, wenn mein Passwort "JohnDoe" ist und ich gebe "Horst" als Passwort ein, dann stimmen die ersten beiden Zeichen nicht überein und somit weiß das System, dass das kein korrektes Passwort sein kann. Wenn ich jedoch "James" als Passwort angebe, dann erkennt die logik den Fehler erst beim Vergleich des zweiten Zeichens... somit benötigt es einige Nanosekunden länger.
 
@patrick_schnell: ok, Denkfehler, siehe o:4 re:5
 
@t-master: Wieso denkfehler? in o:4 re:5 hat er genau das beschrieben, was ich gemeint habe. Siehe o:4 re:10.
 
Kann eigentlich nicht passieren wenn die Passwörter verschlüsselt abgespeichert werden (md5, SHA oder dergleichen)!
 
@LinuXfr3ak: Hab mich auch gewunder wie das denn bei nem Hash funktionieren sollte.
 
@Grospolina: Ein Hash ist auch nur eine Zeichenfolge... ob ich nun ein Passwort in Reintext entschlüssel oder mittels dem Hashwert ist da ziemlich egal. Es dauert halt bei einem Hashwert nur wesentlich länger (länge des Hashwertes ist größer als beim reinen Passwort, sowie die "Tiefe" des Passworts, wie Sonderzeichen, Zahlen usw...)
 
@patrick_schnell: nur das der Hashwert schon bei einem einzelnen unterschiedlichen Zeichen vollkommen anders aussieht
 
@zwutz: Das ist aber volkommen irelevant. wenn man den Hashwert kennt, den das gegenüber erwartet, kann man ihm diesen einfach zur verfügung stellen. Auch komplett ohne das Passwort zu kennen. Wenn man das passwort auch noch braucht -> Rainbowtable
 
@BlackCat: ok, das heißt die Konsequenz ist, entweder zufällig ein paar ms vor der Antwort an den Clienten abwarten oder das Passwort vom Clienten als Hash schicken (damit das Passwort nicht im Klartext geschickt wird) und dann auf dem Server nochmal einen Hash daraus zu erstellen, oder?
 
@BlackCat: ja, nur muss man es dann irgendwie schaffen, dass vom übergebenen Wert selbst kein Hash-Wert generiert wird. Wird schwierig, wenn das Passwort vor der weiteren Verarbeitung in Hash umgewandelt wird
 
@t-master: Das mir dem Delay dürfte funktionieren. Den einwand mit dem Hash nehm ich zurück, weil ich nicht richtig nachgedacht hab ^^
@zwutz: Ok, logischer denkfehler meinerseits. Da das passwort vom server, und nicht vom client errechnet wird hast du natürlich recht.
 
@BlackCat: So war das auch gemeint. Ändert man in dem Passwort einen Buchstaben so ändert sich der gesamte Hash. Da der Hash erst vom Server berechnet wird sollte es bei solchen Systemen also keine Möglichkeit geben, über dieses Verfahren ein Passwort zu knacken. Sobald man einen Hash an direkt an die Anwendung schicken kann ist diese natürlich anfällig.
 
@zwutz: Ich rede hier von dem letztendlichen Hashwert und nicht von dem Inhalt, aus dem der Haswert gebildet wird.
 
@Grospolina: "Sobald man einen Hash an direkt an die Anwendung schicken kann ist diese natürlich anfällig." Und genau das kann man bei WinFuture. Da haben sie beim Programmieren nicht nachgedahcht. hahaha.
 
@LinuXfr3ak:

auch ein hash muss Zeichen für Zeichen geprüft werden. sollte nun der erste Wert des hash mit dem gesendeten übereinstimmen, dann gibt mir die Einheit, die das PW überprüft für das erste zeichen einen korrekten wert zurück und prüft die weiteren zeichen. Warum soll der hash wert also ein unterschied sein ... ob ich nun "12345" oder mittels einer kodierung (wie du sagtest beispielsweise per MD5 oder ähnlichem) "51721" in die PW spalte rein schreibe ist rein Programmtechnisch kein unterschied ... MD5 wird in der regel nur genommen, damit man nicht beim auslesen einer datenbank an die passwörter ran kommt (ist ja offiziell nicht Rückentschlüsselbar und somit sind die PW's recht sicher, was dich aber nicht vor der überprüfungsroutine schützt(die greifen nicht PW's an sondern das system dahinter ... recht klever :)
 
Aber es ist doch bei den meisten Anwendungen etc so, dass nach einer recht geringen Zahl von Fehlversuchen das Konto gesperrt wird. Wie soll das also funktionieren?

Ernst gemeinte Frage. Kenne mich mit sowas nicht aus.
 
@jawe: nicht überall
 
@jawe: Stichwort "Brute-Force". Wer dagegen gesichert ist, ist auch recht sicher ggü. Timing-Attacks. Leider ist Brute-Force immernoch ein recht offenes Tor, was von nur wenigen Entwicklern berücksichtigt wird.
 
Theoretisch sollte es doch dann sicherer sein, wenn man in seine Auth-Funktion bei falschen Password ein zufälliges Delay auslöst, bevor eine Fehlermeldung kommt, oder?! Sollte doch dann wenigstens bei solchen Attacken helfen. Jemand sonst noch eine Erleuchtung?
 
@Mordy: Ich glaube nicht. Eine Verzögerung hätte bei den meisten Implementierungen einen statistischen Erwartungswert (mittlere Verzögerung). Wenn man nur oft genug probiert, dann kennt man diesen Erwartungswert mit der nötigen Genauigkeit, um ihn von der mittleren Antwortzeit zu subtrahieren. Dann tritt wieder die "nackte" Differenz zu Tage, abzüglich einer gewissen statistischen Ungenauigkeit. Aber so wie ich die Methode einschätze, ist da eh viel Statistik dabei, denn die Antwortzeiten übers Netz fluktuieren ja auch und man muß diese Fluktuationen irgendwie abziehen. Das wird vermutlich über die gleiche Schiene laufen.
 
Das hat nichts mit Klartext oder MD5 zu tun sondern daran wie die Ueberpruefung des Passworts implementiert ist (Algorithmus). Hab erst neulich einen Vortrag zu Seitenkanalattacken gehoert da ging es genau um das Thema. In einer Livedemonstration hat der Vortragende dann gezeigt wie man durch solche Timing-Angriffe einen Schluessel bzw. ein Passwort rekonstruiert. War schon ziemlich unglaublich wie schnell das ging. Man kann sich aber davor schuetzen wenn man sich an Secure Coding haelt.
Kommentar abgeben Netiquette beachten!

Video-Empfehlungen

WinFuture Mobil

WinFuture.mbo QR-Code Auch Unterwegs bestens informiert!
Nachrichten und Kommentare auf
dem Smartphone lesen.

Folgt uns auf Twitter

WinFuture bei Twitter

Interessante Artikel & Testberichte

WinFuture wird gehostet von Artfiles