nicht angemeldet
Moin!
Auf was ich angespielt habe sind Man-in-the-Middle-Angriffe über öffentliche WLAN-Verbindungen, die seit Jahren bekannt sind - es reicht hier einfach gesagt sich dazwischenzuhängen und den Handshake mitzuschneiden und schon kann man schaun, was hier so passiert. Eine recht verbreitete, fertige Lösung ist hier sslstrip von Moxie Marlinspike:
http://www.thoughtcrime.org/software/sslstrip/
Das Tool greift nicht SSL an. Es verhindert, dass der Client HTTPS-Links in Webseiten sieht, und stattdessen nutzt der dann die mitlesbare HTTP-Variante, sollte er ihnen folgen.
Verschlüsselung, die der Client direkt benutzt, wird dadurch also nicht betroffen. Und auch das Vortäuschen von SSL-Zertifikaten ist damit nicht möglich.
Mir scheint, du wirfst einiges durcheinander.
Ich habs nur kurz und sehr allgemein formuliert.
Und falsch.
SSL ist nach wie vor sicher. Die Verschlüsselung an sich wurde nicht geknackt.
Was problematisch ist, ist die unabdingbare Infrastruktur:
- der implizite Vertrauensvorschuss gegenüber allen im Browser vorinstallierten CA-Zertifikaten
- das Browserverhalten bei Veränderung des Zertifikats eines zuvor schon besuchten Servers
- die Angreifbarkeit des Browser-UI, die unerfahrene Benutzer über die tatsächliche Unsicherheit täuschen könnte
- und sicherlich noch eine ganze Menge mehr
Deine pauschale Aussage "SSL ist nicht mehr sicher" ist falsch.
Das Hashing mag vielleicht das Passwort während der Übertragung schützen, wenn ich davon ausgehe, dass die SSL-Verschlüsselung kompromittiert wurde. Es schützt z.B. nicht die Session bzw. den Account. Liest der Angreifer den Hash mit, so kann er sich damit beliebig oft authentifizieren. Es muss sogar erst der Salt zum Client übertragen werden, damit der Client denselben Hash produzieren und der Server beide Hashes vergleichen kann.
Selbstverständlich - wenn nur noch der komplette crypt-String (mit Algorithmus, Salt und Hash) gemeinsam übergeben wird, kann man gleich das Klartextpasswort übergeben - das macht dann nicht mehr viel Unterschied. Da muss zwischenzeitlich etwas Ping-Pong stattfinden.
Es bringt nichts, clientseitig zu hashen. Zumal man, weil es für sowas nichts "out of the box" gibt, ja wieder selbst was stricken müsste.
Außerdem steht der Aufwand in keinem Verhältnis. Wenn das, was man hinter dem Passwort versteckt, unverschlüsselt übertragen wird, braucht man sich kein komplexes Login-Hashing ausdenken. Wenn es hingegen Verschlüsselung gibt, braucht man sich kein komplexes Login-Hashing ausdenken.
Wenn es wirklich um Sicherheit geht kommt man mit einem "statischen Passwort" ohne hin nicht weit, üblich sind hier dann 2-Faktor-Systeme wo z.B. bei jedem Login ein Bestätigungs-SMS mit einem zusätzlichen Einmal-Passwort geschickt wird, welches nur in einem begrenzen Zeitfenster gültig oder aber man verwendet Token-Liste, die jeweils nur 1x verwendet werden kann (bzw. man hat einen Token-Generator wie z.B. SecurID).
Das ist aber nur dann implementierenswert, wenn man die Basis-Sicherheit durch SSL herstellt. Und durch all die ganzen weiteren Maßnahmen im Umfeld von SSL, die heutzutage Standard sein sollten. Beispielsweise das Senden von HSTS-Headern, um den Browser beim unverschlüsselten Zugriff darüber zu informieren, dass er grundsätzlich und in der Zukunft immer nur HTTPS benutzen soll.
Mit HSTS wird das Angreifen mit SSLStrip schon extrem erschwert, würde ich meinen.
- Sven Rautenberg
Matthias Apsel