Verschlüsseltes Passwort in der Datenbank und im Browser digest auth

Question

Ich habe einen kleinen Webserver geschrieben, der momentan basic auth over ssl verwendet. Bis jetzt funktioniert alles super. Jetzt will (muss) ich zu Digestauth wechseln. Aber ich kann mir nicht vorstellen, wie das funktioniert, wenn Passwörter nicht als Klartext in der Datenbank gespeichert werden? Ich habe nur das Passwort Digest (generiert mit bcrypt) von den Passwörtern meiner Benutzer gespeichert. Ist http Digest Auth überhaupt möglich?

Answer 1

Ich habe gerade erst gerade nachgesehen. Zuerst lese ich RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication durch, um einen Einblick in die Spezifikation zu erhalten und zu sehen, wie sie für eine REST-API-Authentifizierung angepasst werden kann.

Ran in die gleiche Frage wie Sie - Ist Digest-Authentifizierung bedeutet, dass der Server das Passwort des Benutzers im Klartext speichern muss?

This Stack-Überlauf Antwort macht deutlich: Nein. Der Server ist nicht das Klartext-Passwort speichert - it should store the hash of (username|realm|password).

Das wäre gut gewesen, außer für eine Sache - die kanonische Spezifikation unterstützt nur die Verwendung von MD5 als Hash-Funktion.

Natürlich könnte man speichern sowohl die bcrypt Hash und der MD5-Hash, aber tut so untergräbt nur die Sicherheit des bcrypt Hash effektiv es unbrauchbar machen (da ein Angreifer seine Anstrengungen in Brute verschieben, um den MD5-Hash zwingen stattdessen).

---

Also nahm ich einen Schritt zurück und dachte, warum nicht die Spezifikation außer Acht lassen und verwenden bcrypt auf beiden Seiten als die Hash-Funktion (bcrypt(username|realm|password))?

Nun, neben absichtlich langsam, bcrypt has a maximum password length die makes it unsuitable for use as a general digest algorithm.

Puh, mein Kopf schwamm inzwischen, aber ich dachte immer noch daran, es noch einmal zu versuchen. Einige der Vorschläge waren die Verwendung von TLS mit SRP oder authentifizierter Verschlüsselung, insbesondere EAX, aber ich hatte das Gefühl, dass die Benutzer die Dinge für einen einfachen Web-Service vielleicht nur einen Schritt zu weit nahmen.

Um es einfach auszudrücken, wenn Sie wirklich dazu neigen, dies zu tun, können Sie work around bcrypt's character limitation by using a preliminary hash.

---

Lange Rede kurzer Sinn scheint es, dass Sie tun können:

bcrypt(sha256(username|realm|password)) 

Und das von H(A1) in einer bastardized Version der Spezifikation anstelle verwenden.

Die Frage wird jetzt - war all das zusätzliche Komplexität wirklich wert? Haben wir eine zusätzliche Sicherheitsebene über Basic Auth über HTTPS erhalten?