Mindestens ein Teil des Hashings muss serverseitig erfolgen. Unabhängig davon, was der Client an den Server sendet, wird Zugriff gewährt. Wenn also derselbe Wert nur so wie er ist auf dem Server gespeichert wird, treten dieselben Probleme wie bei der Speicherung von Klartextkennwörtern auf, nämlich ein einziger schreibgeschützter Blick auf Ihren Server Die Datenbank bietet alle Zugriffe.

In den meisten Fällen wird das gesamte Hashing auf dem Server durchgeführt, da der Client ein Webbrowser ist, der bestenfalls Javascript ausführen kann, und Javascript ist bei kryptografischen Aufgaben nicht sehr gut. Der Client sendet das Kennwort selbst (natürlich über HTTPS), und der Server berechnet den Hash und vergleicht ihn mit dem gespeicherten Hashwert. Der Angreifer kann den Hash nicht einfach "weitergeben". Er muss einen Wert senden, der beim Hashing durch den Server den gespeicherten Hashwert ergibt.

Wenn die Clients gut darin sind, Krypto zu erstellen (z. B. ein schwerer nativer Client für ein Spiel), dann der Großteil des Der Hashing-Prozess kann auf der Clientseite durchgeführt werden, es muss jedoch noch eine endgültige Hash-Berechnung auf dem Server durchgeführt werden.

Wie das Anmeldekennwort-Hashing funktionieren soll

Beachten Sie, dass ich in allen Snippets absichtlich Sicherheitsfunktionen ausschließe, weil ich es kompakt halten möchte. Verlassen Sie sich bei nichts auf diese Codefragmente.

In normalen Netzwerkanwendungen, die Kennwort-Hashing verwenden, wird das Benutzerkennwort auf der Clientseite gehasht, bevor es an den Server gesendet wird, oder es wird ohne Hashing gesendet als Verschlüsselung des Nur-Text-Passworts für den Server?

Nein, es ist eine gehashte Serverseite. Sie senden das Kennwort im Klartext oder über HTTPS an den Server. Der Server generiert dann einen Hash für das Kennwort wie folgt:

  public void RegisterAccount (Zeichenfolgenbenutzername, Zeichenfolgenkennwort, Zeichenfolgen-E-Mail) {if (! Database.EmailExists (E-Mail) &&! Database .UsernameExists (Benutzername)) {Database.AddNewUser (Benutzername, Hash.GenerateHash (Passwort), E-Mail); }}  

Angenommen, Database.AddNewUser (Zeichenfolge, Zeichenfolge, Zeichenfolge); fügt den Benutzernamen, das Hash-Kennwort und die E-Mail in die Datenbank ein. Der Hash wird basierend auf dem Passwort generiert.

Nehmen wir an, Sie geben als Passwort "Hack mich bitte nicht" ein. bcrypt verwandelt daraus $ 2a $ 08 $ BOHyNdXAVkWOUgPG / hvsjew7ZpngqJIgueY6m76xd4y3UllXUZLBy oder eine andere Variante, die auf dem Salz basiert. Die Datenbank sieht jetzt folgendermaßen aus:

  + -------------- + ----------------- ----------------------------------------- + ---- ---------------- + | Benutzer | Passwort | E-Mail | + -------------- + -------------------------------- ------------------------------ + ------------------- - + | markbuffalo | $ 2a $ 08 $ BOHyNdXAVkWOUgPG / hvsjew7ZpngqJIgueY6m76xd4y3UllXUZLBy | mark@buffalo.gov | + -------------- + ---------------------------- ---------------------------------- + --------------- ----- +  

Normalerweise rufen Sie die Datenbank auf, um das Kennwort für diesen Benutzernamen zu lesen. Sobald Sie die Datenbank aufgerufen haben, verwenden Sie eine Funktion wie Hash.ValidateHash () , um festzustellen, ob sie übereinstimmt. Wenn es übereinstimmt, können Sie sich mit diesem nicht gehashten Passwort anmelden.

Warum können Sie den Hash nicht einfach übergeben, um sich anzumelden?

In einigen sehr unglücklichen Fällen.

Die Hauptfrage, die ich habe, ist, ob ein Angreifer die Hash-Passwörter entdeckt. Warum kann er dann nicht einfach Hash an den Server senden, um sich bei clientseitigem Hashing zu authentifizieren?

Dies ist möglich, kann jedoch nur in schweren Fällen von massiv epischen Fehlern im Auftrag der Entwickler auftreten. Tatsächlich habe ich das schon einmal gesehen und ich werde Ihnen zeigen, wie dies über Code geschehen kann:

  public void Login (String-Benutzername, String-Passwort) {if (Database.LoginMatches ( Benutzername, Passwort) || Database.LoginMatches (Benutzername, Hash.ValidateHash (Passwort))) {logMeIn (); }}  

Im obigen Snippet möchte der Login überprüfen, ob entweder der Benutzer den Hash oder das Kennwort hat, das in dem in der Datenbank gespeicherten Hash validiert wird. Dies ist nicht der richtige Weg, dies zu tun. Tatsächlich ist es einer der schlimmsten Fälle von epischem Versagen, die ich je in meinem Leben gesehen habe.

Mit diesem Code können Sie einfach den Hash oder das Passwort eingeben und sich anmelden Tabelle. Eine der folgenden Anmeldungen funktioniert ordnungsgemäß:

1. Login ("markbuffalo", "$ 2a $ 08 $ BOHyNdXAVkWOUgPG / hvsjew7ZpngqJIgueY6m76xd4y3UllXUZLBy");
2. Login ("markbuffalo", @ "hack mich bitte nicht");
ol>

Das ist der falsche Ansatz. Es soll nicht passieren. Beim. Alles. Trotzdem haben einige Entwickler diesen Ansatz aus Gründen gewählt, die ich nicht kenne.

---

Was ist der richtige Ansatz für die Hash-Validierung?

Wie Rápli András sagte, stimmt h (x) nicht mit h (h (x)) überein. Der richtige Ansatz besteht darin, das eingehende Kennwort anhand des Hashs zu überprüfen, um festzustellen, ob sie übereinstimmen. Wenn sie nicht übereinstimmen, verwenden Sie keine ODER Magie ( || ). Erlauben Sie ihnen einfach nicht, sich anzumelden.

Zu Ihrer ersten Frage:

Dies hängt von der Anwendung ab. In den meisten Fällen wird das Kennwort im Klartext an den Server gesendet (und dies ist unsicher, wenn die Anwendung ein unverschlüsseltes Protokoll wie HTTP verwendet). Der Server speichert jedoch möglicherweise einen Hash-Wert in der Datenbank. In diesem Fall berechnet die Anwendung den Hashwert des vom Benutzer empfangenen Klartextkennworts und vergleicht ihn mit dem in der Datenbank gespeicherten Wert.

Zu Ihrer zweiten Frage:

Der Server erwartet eine Kennworteingabe: X . Der Angreifer findet irgendwie heraus, dass h (X) . Wenn er diesen Hash-Wert zur Authentifizierung eingeben würde, würde die Hash-Funktion erneut gegen h (x) ausgeführt er würde nicht einsteigen können, da h (x) nicht mit h (h (x)) übereinstimmt.

Wie andere bereits betont haben, sendet der Client das Klartext-Passwort normalerweise über einen sicheren Kanal (der reversible Verschlüsselung verwendet, kein Hashing ) und dieses Passwort wird dann serverseitig mit demselben Salt wie der gespeicherte Hash gehasht.

  Client < ----- Sicherer Link ----- > ServerCleartext-Passwort Verschlüsseltes Passwort Hashed-Passwort  

1. Client hat das Klartext-Passwort.
2. Client verschlüsselt Passwort (über TLS)
3. Server empfängt verschlüsseltes Passwort, entschlüsselt es (über TLS)
4. Server-Hash-Passwort mit demselben Salt wie in der Datenbank für diesen Benutzer gespeichert
5. Server vergleicht berechneten Hash mit gespeichertem Hash.
ol>

Schutz:

• gegen Abhören (aufgrund der Verwendung eines sicheren Kanals)
• gegen MITM-Angriffe (wenn die TLS-Sitzung ordnungsgemäß eingerichtet, Zertifikate ordnungsgemäß überprüft usw.)
• gegen Diebstahl von Passwortdatenbanken

Jetzt die Problem ist, wenn Sie ein Kennwort über einen Kanal senden müssen, der keine Verschlüsselung bietet , wie dies bei einem Protokoll auf niedriger Ebene (z. B. PPP oder 802.1X) der Fall sein kann. Die traditionellen Optionen (für PPP) waren:

• PAP: Senden Sie das Kennwort im Klartext, das dann zum Vergleich mit dem serverseitig gehasht werden kann Hash-Passwort-Datenbank

• CHAP: Verwenden Sie ein Challenge-Response-Protokoll und senden Sie eine Hash-Version des Passworts (kombiniert mit der Challenge und einer ID) über Der Link erforderte jedoch, dass der Server den Klartext der Passwörter speichert.

Ersteres schützt also vor Diebstahl von Passwortdatenbanken, jedoch nicht vor Abhören, während die Situation umgekehrt ist Letzteres.

Abgesehen von EAP-Protokollen, die tatsächlich einen TLS-Tunnel (PEAP, EAP-TTLS, EAP-TLS ...) einrichten, um den Kennwortaustausch zu sichern, gibt es ein alternatives Protokoll, das das Senden eines nicht umkehrbaren "Hash" von ermöglicht das Kennwort für einen Server, auf dem auch ein "Hash" des Kennworts gespeichert ist: SRP und allgemeiner "erweiterte PAKE" - Protokolle.

Ein Angriff, der auf dem einfachen erneuten Senden erfasster Daten basiert (z. B. ein vom Client gehashtes Kennwort), ohne dass die Daten entschlüsselt werden müssen, wird als "Wiederholungs" -Angriff bezeichnet. Die Standardminderung für diesen Angriff besteht darin, ein sogenanntes "Nonce" in die Hash-Daten aufzunehmen. Dies kann eine vom Server bereitgestellte Zufallszahl oder ein vom Client generierter Zeitstempel mit angemessen hoher Auflösung sein. Der Server überprüft dann, ob die Nonce gültig ist oder in einem akzeptablen Bereich liegt. Wenn sie falsch oder zu alt ist, lehnt sie die Anforderung ab. Eine ausführliche Diskussion finden Sie hier Was nützt ein Client Nonce?