it-swarm.com.de

Welche Art von Hashing muss zum Speichern von REST API-Token in der Datenbank verwendet werden?

Wir haben eine REST API, die mit einem mobilen Front-End kommuniziert. Nach dem Senden eines Einmalkennworts gibt das Backend ein Token (zufällige UUID v4-Zeichenfolge) aus, das die mobile App als Authentifizierung verwenden kann Bei nachfolgenden Anforderungen speichert der Server eine Hash-Version dieses Tokens in der Datenbank mit dem Benutzer.

Wir möchten sicherstellen, dass die Authentifizierung des Tokens so wenig Zeit wie möglich in Anspruch nimmt.

FRAGE
Welche Art von Hashing/Verschlüsselung reicht aus, um die Token in der Datenbank zu speichern? Ist ein schneller Hash wie SHA256 gut genug oder sollten wir einen langsamen Hash wie bcrypt verwenden? Müssen wir bei Verwendung von SHA256 ein Salt einfügen, da das ursprüngliche nicht verwaschene Token nur eine zufällige 16-Byte-UUID ist?

13
maniciam

TLDR; SHA256 ist gut genug

Um dies zu beantworten, müssen wir zunächst untersuchen, warum wir mehrere Iterationen des Hashs salzen, hashen und verwenden.

  • Warum salzen wir? Um Benutzer mit schwacher Kennwortentropie vor dem Knacken ihres Kennworts zu schützen (z. B. Rainbow-Tabellen oder zwei Benutzer mit demselben Kennwort). Dies ist kein Problem, da UUID4 122 Entropiebits aufweist1.

    Wenn wir eine Rainbow-Tabelle mit allen UUIDv4-Werten erstellen möchten, die SHA256-gehasht wurden, und 1 Billion Hashes pro Sekunde durchführen könnten2. Es würde 168,6 Billiarden Jahre dauern, um den Regenbogentisch zu erstellen. Wir müssen uns also keine Sorgen machen.

  • Warum haschen wir? Um zu verhindern, dass Klartextkopien des Passworts gespeichert werden. Das scheint eine gute Idee zu sein. Sie möchten nicht, dass jemand Ihre Datenbank lesen kann3 sich als Benutzer ausgeben zu können.

  • Warum verwenden wir mehrere Iterationen? Um Brute-Force-Angriffe zu verlangsamen. Wie bereits erwähnt, hat UUID4 122 Entropiebits. Das Knacken dieser Hashes ist selbst bei hoher Geschwindigkeit nicht möglich.


[1] 128 Bit - 6 Bit, die vorbestimmt sind

[2] Die derzeit schnellsten Hashing-Raten verketten sich ständig, sodass ich nicht versuchen werde, die aktuellste Geschwindigkeit zu finden, die in einigen Monaten veraltet sein wird.

[3] Dies kann SQL Injection oder eine durchgesickerte Kopie eines Backups oder eines Insiders oder was auch immer sein.

16
Hybrid