suit: Fragwürdige Literatur (web & mobile Developer, Ausgabe 11/2013)

Beitrag lesen

Idealerweise werden alle Daten SSL-verschlüsselt übertragen.

SSL ist prinzipiell nicht mehr sicher.

Was willst du damit sagen? Dass SSL nunmehr sinnlos ist?

Nein, selbstverständlich - es ist eine zusätzliche Hürde, aber es kam so rüber als würdest du sagen "Nimm SSL, dann brauchst du dich um den rest nicht mehr scheren" :)

Ich habe ja den Eindruck, die kürzlichen »Leaks« haben hauptsächlich Fear, Uncertainty & Doubt über IT-Security verbreitet.

Nein, ich spielte nicht auf die kürzlichen NSA-"Leaks" ab - da gehts ja schon seit ein paar Jahren rund - z.B. vor 2 Jahren die Geschichte mit dem ehrlichen Achmed: http://www.heise.de/security/meldung/Der-ehrliche-Achmed-bittet-um-Vertrauen-1231083.html (wobei hier nicht SSL zwingend schuld ist).

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/

Mir scheint, du wirfst einiges durcheinander.

Ich habs nur kurz und sehr allgemein formuliert.

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.

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).