[Netzwerk/Sicherheit] Übertragung des Passwortes

cwriter

Erfahrenes Mitglied
Hallo Welt

Ich habe zum Thema Netzwerksicherheit einige Modelle gesehen und davon gehört, doch ich bin mir nicht ganz sicher, ob ich alles richtig verstanden habe.

  • Möglichkeit 1: Unverschlüsselt
    Das Passwort wird über TCP im Klartext geschickt.
    Vorteile:
    + Einfach
    Nachteile:
    - Anfällig für MitM
    - Server kennt Klartext-Passwort
  • Möglichkeit 2: TLS
    Das Passwort wird über TLS geschickt.
    Vorteile:
    + Sicher vor MitM
    + Bibliotheken können alles erledigen
    + Datenübertragung generell ist sicher
    Nachteile:
    - Server kennt Passwort
    - 3rd-Party CA
  • Möglichkeit 3: Client hasht Passwort
    Das Passwort wird vom Client (möglicherweise mit Salt) gehasht und dann über TCP geschickt. Der Server salzt den Hash dann mit einem für jeden Nutzer unterschiedlichen Salzstreuer und hasht nochmals.
    Vorteile:
    + Das Nutzerpasswort ist nicht einfach herzuleiten
    + Server kennt das Passwort zu keinem Zeitpunkt
    Nachteile:
    - Ein MitM hat ein gültiges Passwort und damit Zugang
  • Möglichkeit 4: 2-Way One-Time-Pads
    Der Client verschlüsselt das Passwort mit Zufallswerten, schickt es dem Server, der Server verschlüsselt wiederum mit eigenen Zufallswerten, schickt es zurück, der Client entfernt seine Verschlüsselung, schickt es zurück, der Server kann entschlüsseln und das Passwort nutzen.
    Vorteile:
    + Es werden nie nutzbare Daten übertragen
    + Durch die Zufallswerte ist das Herleiten der gesendeten Daten (fast) unmöglich.
    Nachteile:
    - Viel Datenverkehr
Verbesserungen/Ergänzungen willkommen.

Dann kann man die Möglichkeiten noch kombinieren, um mit einem Mischling die Vorteile aller kombinieren zu können.

Nur zu den eigentlichen Fragen:
  • Warum hat sich SSL/TLS durchgesetzt, wenn es doch eigentlich unsicherer ist als OTPs? (Bei der Schlüsselübertragung, bei grossen Dateistreams ist klar, dass OTPs zu langsam sind)
  • Wie einfach sind MitM-Angriffe zwischen zwei Routern (also ausserhalb der "eigenen" Infrastruktur, sondern bei Provider und Kabeln) durchzuführen?

Gruss
cwriter
 
Hallo,

ganz kurz zu deiner Möglichkeit 3:

Möglichkeit 3: Client hasht Passwort
Das Passwort wird vom Client (möglicherweise mit Salt) gehasht und dann über TCP geschickt. Der Server salzt den Hash dann mit einem für jeden Nutzer unterschiedlichen Salzstreuer und hasht nochmals.
Vorteile:
+ Das Nutzerpasswort ist nicht einfach herzuleiten
+ Server kennt das Passwort zu keinem Zeitpunkt
Nachteile:
- Ein MitM hat ein gültiges Passwort und damit Zugang

Ein MitM-Angriff kann mittels HTTPS (also durch Benutzung von TLS) verhindert werden.
Allerdings: Wer den Hash kennt, kann sich anmelden. Folglich ist der Hash nun zum Passwort geworden. Einziger Vorteil aus deiner Sicht wäre, dass das Nutzerpasswort nie dem Server überlassen wird. Das wäre aber nur dann ein Vorteil, wenn der Server nicht vertrauenswürdig ist, d. h. entweder das Passwort weitergeben würde oder es ungesichert speichert (d. h. ohne richtigen Hash-Algorithmus + Salt).
 
Einziger Vorteil aus deiner Sicht wäre, dass das Nutzerpasswort nie dem Server überlassen wird. Das wäre aber nur dann ein Vorteil, wenn der Server nicht vertrauenswürdig ist, d. h. entweder das Passwort weitergeben würde oder es ungesichert speichert (d. h. ohne richtigen Hash-Algorithmus + Salt).
Ja, zudem verhindert aber die clientseitige Mutation, dass das Passwort schon während der Übertragung nicht lesbar ist. D.h.: Wenn man TLS nutzt, und TLS auch funktioniert, wie es soll, ist alles gut. Doch wenn Lenovo wieder mit Bloatware um sich schmeisst, ist es manchmal gut, auch die Daten zu mutieren, bevor man sie in den Verschlüsselungstunnel schickt. Oder mache ich da einen Denkfehler?

Und ja, diese Art der Verschlüsselung schützt eigentlich nur andere Dienste, auf der anderen Seite: Würden alle Dienste die Passwörter mit von mir aus immer gleichen Salts versehen (für jeden Nutzer gleich, nicht für jeden Dienst) und dann hashen, wären Datenbankdiebstähle schon um einiges weniger schlimm, oder?

Gruss
cwriter
 
Zuletzt bearbeitet:
[..] ist es manchmal gut, auch die Daten zu mutieren, bevor man sie in den Verschlüsselungstunnel schickt
Lassen wir mal HTTPS außer Betracht, denn im schlimmsten Fall ist das Host-System betroffen und erlaubt MitM-Angriffe (wie bei dem von dir verlinkten Superfish-Debakel).

Fall A: Wir schicken das Nutzer-Passwort ("mein-geheimes-PW") ganz normal. Was passiert, wenn jemand das Nutzer-Passwort mitliest? Er kann sich
  • (a) im jeweiligen System damit authentifizieren und im Namen des Nutzers agieren sowie
  • (b) das Passwort möglicherweise als Anhaltspunkt für andere Nutzeraccounts desselben Nutzers verwenden, um auch diese zu knacken.

Fall B: Wir schicken das Nutzer-Passwort ("mein-geheimes-PW") gehasht an den Server (etwa "aks²³[9]ldj}\´`sdf"). Was passiert, wenn jemand das gehashte Passwort mitliest? Er kann sich
  • (a) im jeweiligen System damit authentifizieren und im Namen des Nutzers agieren,
  • (b) das Passwort definitiv nicht als Anhaltspunkt für andere Passwörter desselben Nutzers nehmen.
Wir sehen, das Problem (a) besteht in jedem Fall. Im Gegensatz dazu existiert Problem (b) nur, wenn der Nutzer Passwörter bei mehreren System identisch oder nur leicht abgewandelt wiederverwendet. Die Nutzung einer Passwort-Datenbank eliminiert letzteres Problem beispielsweise gänzlich.

Würden alle Dienste die Passwörter mit von mir aus immer gleichen Salts versehen (für jeden Nutzer gleich, nicht für jeden Dienst) und dann hashen, wären Datenbankdiebstähle schon um einiges weniger schlimm, oder?
Im Gegensatz, Datenbankdiebstähle wären um einiges verheerender! Im Allgemeinen vehrindern Salts, dass Rainbow Tabellen für jedes Nutzeraccount und Passwort (d. h. auch bei PW-Änderungen seitens des Nutzers) neu erstellt werden müssten. Dies erfordert natürlich viel (Rechen-)Zeit. Wenn wir dagegen für jeden Nutzer einen einzigen Salt verwenden, so bedarf es für einen Nutzer nur einer einzigen Rainbow Tabelle, was wesentlich effizienter für den Angreifer ist.
 
Wir sehen, das Problem (a) besteht in jedem Fall. Im Gegensatz dazu existiert Problem (b) nur, wenn der Nutzer Passwörter bei mehreren System identisch oder nur leicht abgewandelt wiederverwendet.
Das tun allerdings die meisten.

Im Gegensatz, Datenbankdiebstähle wären um einiges verheerender!
Wenn wir dagegen für jeden Nutzer einen einzigen Salt verwenden, so bedarf es für einen Nutzer nur einer einzigen Rainbow Tabelle, was wesentlich effizienter für den Angreifer ist.
Ich denke, da besteht ein Missverständnis.

Ich habe aber dennoch meinen Denkfehler gefunden. Kleine Erläuterung:
Jeder Dienst salzt die eingegebenen Passwörter clientseitig mit einem eigenen (also pro Dienst spezifischem) Hash. Dann wird nochmals gesalzen und gehasht, diesmal aber mit zufälligem Salt.
In meinen irren Hirnwindungen hätte das pro-Dienst Hashtables erfordert; macht aber wenig Sinn, wenn die pro-Dienst Salts immer gleich sind, da es nur vergleichsweise wenig Arbeit erfordern würde, das Ganze einfach nochmals zu tabellieren.

Hm. Wenn ich mir das jetzt so überlege, macht es vielleicht doch Sinn, da die Tables ja mehrfach angelegt werden müssten. Ich bin verwirrt; liegt vielleicht auch an der Uhrzeit. Ich werde morgen früh nochmals über die Bücher gehen.

Hier noch kurz das Schema:
Code:
Client (Salt immer "abc")                               SENDEN Server (Salt zufällig)
______________________________________________|_________|________________________
Nutzerpasswort wird gesaltet + gehasht     |   ---->   | Hash wird gesaltet und gehasht (endgültiger hash + salt werden gespeichert, nichts davon, was der Client geschickt hat)




Hacker klaut DB -> Hat die "Gleichung" x+salt = hash
Er macht daher einen Rainbowtable für jeden Salt (was schwierig ist, da die meisten Rainbowtables nur "einfache" Passwörter enthalten und keine 32-256 Byte-lange (je nach Encoding/Hashalgorithmus).
Dann hat er aber erst den Hash, der aus dem ursprünglichen Hash entstanden ist, d.h. er braucht mehr, um das eigentliche Passwort zu bekommen. Er muss also wieder einen Rainbowtable anlegen, was diesmal zwar schneller geht, da er statt einer Variablen nun x+"abc" = hash hat, was ein weiteres Mal eine Tabelle erfordern würde, obgleich diese ein Klacks sein würde, verglichen mit den random salts.
Und jetzt denke ich wieder, dass es keinen Sinn macht, da es sehr schwach ist. Naja. Ich sollte mich wohl erst morgen wieder damit beschäftigen; momentan schwirrt mir der Kopf :p

Gruss
cwriter

/EDIT:
Es macht nach genauerer Betrachtung teilweise Sinn - allerdings weniger, als wenn die Clientside-Salts auch zufällig sind.
 
Zuletzt bearbeitet:
Zurück