CouchDB Authentifizierung

Question

Ich habe eine Menge über die Authentifizierung in CouchDB gelesen, insbesondere über die Cookie Authentifizierung. Ich mache noch einige Tests und alles scheint gut zu funktionieren, zum Beispiel mit diesem Befehl:

curl -vX POST $HOST/_session -H 'application/x-www-form-urlencoded' -d 'name=foo&password=bar'

Ich bekomme einen Cookie, den ich verwenden kann. Aber ich will damit sagen, dass immer, wenn ich solche Beispiele im Internet sehe, der Benutzername und das Passwort im Klartext gesendet werden.

Ich bin wirklich neu in der Sicherheit, aber was ist das Interesse der Cookie Auth-Methode, wenn ich zuerst meine Anmeldeinformationen im Klartext senden muss?

Gibt es eine Möglichkeit, zumindest das Passwort gehasht zu senden? Mit so etwas wie dem IDK :

curl -vX POST $HOST/_session -H 'application/x-www-form-urlencoded' -d 'name=foo&hashed_password=hashed_bar'

Prost

Arnaud

Answer 1

Wenn Sie Ihr Kennwort gehasht senden, muss der Angreifer nur Ihr gehashtes Kennwort kennen, so dass das Problem des Versendens Ihres Kennworts im Klartext nicht gelöst wäre - jetzt hätten Sie das Problem des Versendens Ihres Hashs im Klartext.

Denken Sie auch daran, dass Sie, selbst wenn das Problem damit gelöst wäre, Ihr Cookie immer noch im Klartext senden würden und damit anfällig für Session Hijacking wären.

(Es gibt auch die HTTP-Digest-Zugriffsauthentifizierung, die aber nicht ganz unproblematisch ist - aber CouchDB unterstützt sie nicht, als ich das letzte Mal nachgesehen habe).

Sie sollten immer HTTPS f�r jeden authentifizierten CouchDB Zugriff verwenden, egal in welchem Netzwerk, außer vielleicht dem 127.0.0.0 Netzwerk.

(Und ja, so gut wie alle Beispiele im Internet y in Büchern zeigen die Verwendung von Basic- oder Cookie-Authentifizierung über HTTP, was meiner Meinung nach eine Katastrophe ist, die nur darauf wartet zu passieren).

Answer 2

Die Verwendung von Https ist die richtige Antwort.

Ich werde eine Klarstellung über die Bedeutung der Berechnung eines Hashes auf der Server-Seite hinzufügen. Der Hash ist eine Einwegfunktion, die die Eingabe in den auf dem Server gespeicherten Schlüsselwert umwandelt. Wenn jemand den Server hackt und die gehashte Eingabe (Schlüsselwert) erhält, kann er daraus nicht den Eingabewert ableiten und sich als Sie ausgeben.

Wenn Sie den Schlüsselwert auf der Client-Seite berechnen und auf dem Server keine Einwegumwandlung durchgeführt wird, ist dies gleichbedeutend mit der Speicherung von Kennwörtern im Klartext. Jemand, dem es gelungen ist, eine Kopie des auf dem Server gespeicherten Schlüsselwerts zu erhalten, kann sich leicht als Sie ausgeben, indem er einfach den Schlüsselwert sendet.

Daher muss auf der Serverseite eine kryptografisch sichere Einwegfunktion (z. B. sha256) mit einem Salt/Zufallswert auf das übermittelte Passwort angewendet werden, um die Passwortdatenbank zu sichern.

Die Verschleierung des gesendeten Kennworts durch Hashing, zusätzlich zum Hashing auf der Serverseite, hilft nicht viel, wenn der gesendete Hash-Wert immer derselbe ist. Das Ausspähen von Daten, die über eine SSL-Verbindung gesendet werden, ist jedoch nicht trivial.

Das Hashing von Passwörtern auf der Client-Seite hat jedoch einen erheblichen Vorteil. Ein Brute-Force-Angriff auf den Server, bei dem versucht wird, das Passwort mit Hilfe eines gängigen Passwort-Wörterbuchs zu erraten, wäre aussichtslos, da das Hashing auf der Client-Seite das Passwort nach dem Zufallsprinzip generiert.

Wir können dem Hash ein Salz hinzufügen, um uns vor der Verwendung eines gehashten Passwort-Wörterbuchs zu schützen. Wenn der Benutzer seine Benutzerkennung eingegeben hat, fragen Sie den Server nach dem benutzerspezifischen Salt-Wert. Verwenden Sie dann den zurückgegebenen Salt- oder Hash-Seed-Wert, um das gehashte Passwort auf der Client-Seite zu generieren.

Das Erraten von Passwörtern mit roher Gewalt kann auf der Serverseite verhindert werden, indem das Zeitintervall zwischen den Wiederholungsversuchen verlängert wird. Dies funktioniert jedoch im Allgemeinen nur für eine bestimmte Verbindung. Der Angreifer kann die Verbindung nach jeweils zwei Versuchen wiederherstellen. Um diese Art von Angriffen zu erkennen, ist es erforderlich, die IP-Adressen zu verfolgen.

Answer 3

Seit der Version 1.1 unterstützt CouchDB den API-Zugang über HTTPS. Anstatt einen HTTPS Proxy zu verwenden, kann man HTTPS auch direkt verwenden und so die über die Leitung übertragenen Passwörter schützen. Siehe die Leitfaden für 1.1.