it-swarm.com.de

Passwort-Hashing im Frontend oder Backend?

Ich habe einen Java Server mit Spring Boot und einem JS Frontend in AngularJS.

Mein Lehrer sagte mir, ich solle HTTPS für Passwörter verwenden, weil ich sie nicht sicher genug hashen kann, damit niemand sie hacken kann.

Wenn ich es mit HTTPS richtig mache, muss ich es nicht extra hashen. Meine Quelle: Ich sende nur Benutzername und Passwort über https. Ist das in Ordnung?

Nun zu meiner Frage: Ich speichere das pw natürlich in einer DB. Wo soll ich sie hashen? Frontend oder Backend?

  • Wenn ich es im Frontend hashe, muss ich im Backend nichts anderes machen; aber wenn das HTTPS-Zertifikat abläuft, bin ich unsicher.
  • Wenn ich es im Backend mache, muss ich im Frontend nichts anderes machen; aber wenn das HTTPS-Zertifikat abläuft, bin ich unsicher.

Ich würde Scrypt verwenden, das für Passwort-Hash gemacht ist.

11
rala

@ John hat die Weitergabe des Passworts über das Netzwerk bereits sehr gut beschrieben (benutze HTTPS).

Zur Beantwortung Ihrer Frage:

Wo soll ich sie hashen? Frontend oder Backend?

Das Backend . Wenn Sie sie nur im Frontend hashen, sind Sie anfällig für einen Pass-Hash-Angriff.

Der Grund, warum Sie Kennwörter in Ihrer Datenbank hashen, besteht darin, zu verhindern, dass ein Angreifer, der Ihre Datenbank bereits kompromittiert hat, diese Kennwörter verwendet.

Wenn Sie die Passwörter im Backend hashen, muss ein Angreifer sie zuerst knacken, um sie auf Ihrer Website zu verwenden. Wenn Sie sie jedoch im Frontend hashen, muss ein Angreifer dies nicht tun. Er kann den Hash einfach so übergeben, wie er in der Datenbank gespeichert ist.

19
tim

Sie verwechseln zwei Dinge: Transportsicherheit und Datenbanksicherheit. HTTPS mit TLS schützt nur den Transport der Daten vom Client zum Server. Dies bedeutet, dass ein Lauscher nicht weiß, was Client und Server sich gegenseitig senden (vereinfacht). Das Speichern von Passwörtern ist ein ganz anderes Thema. Sie möchten sicherstellen, dass ein Angreifer auch dann keinen Zugriff auf die Klartextkennwörter erhält, wenn er Zugriff auf Ihre Datenbank erhält.

Unabhängig davon, wie Sie die Passwörter speichern, sollten Sie immer TLS verwenden. Andernfalls kann ein Lauscher aufzeichnen, was der Client zur Authentifizierung an den Server sendet. Dann spielt es keine Rolle, ob Sie das Passwort-HASHING auf der Client- oder der Serverseite ausführen. Der Angreifer kann einfach aufzeichnen, was über das Kabel geht, und die Kommunikation erneut abspielen, um Zugriff zu erhalten, und sich als Client ausgeben.

(Beachten Sie, dass Sie das Passwort-HASHING und nicht die Verschlüsselung ausführen möchten. Das Hashing erfolgt in eine Richtung, die Verschlüsselung nicht.)

Das Hashing sollte am Backend erfolgen. Das Back-End befindet sich unter Ihrer Kontrolle, sodass Sie sicherstellen können, dass das Hashing wie vorgesehen stattfindet. Zusätzlich können Sie clientseitiges Hashing durchführen. Sie sollten clientseitiges Hashing nicht alleine verwenden, da der Prozess z. Dies kann in JavaScript erfolgen, das der Benutzer blockieren oder bearbeiten kann. Es scheint keine vernünftige Bedrohung zu sein, aber Sie sollten niemals den vom Benutzer bereitgestellten Daten vertrauen. Daher sollten Sie nicht davon ausgehen, dass der Client das Hashing ordnungsgemäß durchführt. Dies bedeutet, dass Sie dies auf jeden Fall im Backend tun müssen.

10
John

HTTPS bietet Sicherheit nur für die Transportschicht. Es hat nichts mit den für die Speicherung erforderlichen Sicherheitsmechanismen zu tun.

Sie sollten keine Passwörter verschlüsseln. Sie sollten sie hashen, damit Sie sie später nicht entschlüsseln können (noch einen Angreifer).

Der Hash-Schritt wird immer im Backend ausgeführt, da ein Angreifer, der Zugriff auf Ihre Hashes hat, auf jeder Clientseite eine Methode zum Anmelden bei jedem Konto erhalten kann.

3
Benoit Esnard

HTTPS (HTTP über TLS/SSL) bietet Sicherheit für Daten während der Übertragung/Daten in Bewegung. Es bietet KEINE Verschlüsselung für ruhende Daten (Datenbank, Dateien auf einer Festplatte) -> Verschlüsselt mit AES, 3DES, BlowFish usw.

Sie können eine Verschlüsselung für die Datenbank bereitstellen, jedoch nicht für die gesamte Datenbank, da dies Ihre Ressourcen verschlingt (verschlüsselte Dateien sind größer als unverschlüsselt). Verschlüsseln Sie einfach ein bestimmtes Feld, d. H. Kunden-PII -> Kreditkarteninformationen.

Es ist keine bewährte Methode, Benutzerkennwörter zu verschlüsseln, sondern nur HASH und SALT.

Wenn Ihr HTTPS-Zertifikat abläuft, kann der Angreifer die Kennwörter im Klartext abhören. Geben Sie einfach die Sicherheitsebene für Ihren Code an.

Wenn der Benutzer das Kennwort angibt, sollte Ihr Code über eine gespeicherte Prozedur (SQL) verfügen, die mit dem Wert HASHED + SALT des Kennworts des Benutzers in Ihrer Datenbank übereinstimmt. Wenn der HASH + SALT-Wert nicht übereinstimmt, handelt es sich offensichtlich um ein falsches Passwort.

Hinweis: Hashes sorgen für Integrität.

Die SALT-Funktion verringert das Risiko, dass der Angreifer einen Rainbow-Tabellenangriff ausführt, da der Angreifer den SALT-Wert nicht kennt.

Der Schlüssel: HASH + SALZ

https://en.wikipedia.org/wiki/Salt_ (Kryptographie)

1
vulnerableuser