In der Kryptographie ist ein Pepper ein geheimer Wert, der beim Hashing mit einer kryptografischen Hash-Funktion zu einer Eingabe wie einem Passwort hinzugefügt wird . Dieser Wert unterscheidet sich von einem Salt dadurch, dass er nicht zusammen mit dem Passwort-Hash gespeichert wird, sondern mithilfe eines separaten Mechanismus, beispielsweise eines Hardware-Sicherheitsmoduls, geschützt wird. [ 1 ] Das Nationale Institut für Standards und Technologie ( NIST) bezeichnet diesen Wert als geheimen Schlüssel und nicht als Pepper . Ein Pepper ist konzeptionell einem Salt oder einem Verschlüsselungsschlüssel ähnlich. Wie ein Salt ist er ein zufällig generierter Wert, der zu einem Passwort-Hash addiert wird, und wie ein Verschlüsselungsschlüssel muss er geheim gehalten werden.
Ein Pepper erfüllt eine vergleichbare Funktion wie ein Salt oder ein Verschlüsselungsschlüssel . Während ein Salt jedoch nicht geheim (sondern lediglich eindeutig) ist und zusammen mit dem Hashwert gespeichert werden kann, ist ein Pepper geheim und darf nicht zusammen mit dem Hashwert gespeichert werden. Hashwert und Salt werden üblicherweise in einer Datenbank gespeichert. Falls eine Speicherung erfolgt, muss der Pepper separat aufbewahrt werden, um zu verhindern, dass er im Falle eines Datenbankangriffs von einem Angreifer erlangt werden kann. [ 2 ]
Geschichte
Die Idee eines standort- oder dienstspezifischen Salts (zusätzlich zu einem benutzerbezogenen Salt) hat eine lange Geschichte. Bereits 1995 schlug Steven M. Bellovin in einem Bugtraq- Beitrag einen lokalen Parameter vor. [ 3 ] 1996 beschrieb auch Udi Manber die Vorteile eines solchen Schemas und bezeichnete es als geheimen Salt . [ 4 ] Er schlug jedoch vor, den Wert des geheimen Salts nicht zu speichern, sondern ihn stattdessen bei der Passwortverifizierung durch Ausprobieren wiederzuerlangen. Der Begriff „Pepper“ wurde analog zu Salt verwendet, allerdings mit verschiedenen Bedeutungen. Beispielsweise wurde Pepper bei der Diskussion eines Challenge-Response -Verfahrens für eine saltähnliche Größe verwendet, jedoch nicht zur Passwortspeicherung; [ 5 ] er wurde für eine Datenübertragungstechnik verwendet, bei der ein Pepper erraten werden muss; [ 6 ] und sogar als Bestandteil von Witzen. [ 7 ]
Der Begriff „Pepper“ wurde in einer Diskussion über den Schutz von Passwörtern vor Rainbow-Table -Angriffen für einen geheimen oder lokalen Parameter vorgeschlagen, der getrennt vom Passwort gespeichert wird. [ 8 ] Diese Verwendung setzte sich nicht sofort durch: So fügte beispielsweise Fred Wenzel Django Unterstützung für Passwort-Hashing mit Speicherung auf Basis einer Kombination aus bcrypt und HMAC unter Verwendung separat gespeicherter Nonces hinzu , ohne den Begriff zu verwenden. [ 9 ] Inzwischen ist die Verwendung jedoch üblicher geworden. [ 10 ] [ 11 ] [ 12 ]
Typen
Es gibt mehrere verschiedene Paprikasorten:
- Ein gemeinsames Geheimnis, das allen Benutzern bekannt ist. [ 2 ]
- Eine zufällig ausgewählte Zahl, die bei jeder Passworteingabe erneut ermittelt werden muss. [ 13 ]
Diese Mechanismen könnten mit Passwort-Salting, iterativem Hashing oder auch untereinander kombiniert werden. [ 11 ] [ 14 ]
Gemeinsames Geheimrezept für Pfeffer
Bellovin und Webster schlagen vor, dem Passwort vor dem Hashing ein gemeinsames Geheimnis voranzustellen, was die Verwendung bestehender Hash-Funktionen vereinfacht. [ 3 ] [ 8 ] Betrachten wir beispielsweise zwei Benutzer, die einer Datenbank hinzugefügt werden sollen.
| Benutzername | Passwort |
|---|---|
| Benutzer1 | password123 |
| Benutzer2 | password123 |
Diese Tabelle enthält zwei Kombinationen aus Benutzername und Passwort. Das Passwort wird nicht gespeichert, und der 8-Byte (64-Bit) Pepper 44534C70C6883DE2 wird an einem sicheren Ort getrennt von den Ausgabewerten des Hashwerts, in diesem Fall SHA256 , gespeichert .
| Benutzername | Hashing-Zeichenkette | Hash-Ausgabewert = SHA256 (Passwort + Pepper) |
|---|---|---|
| Benutzer1 | password123+44534C70C6883DE2 | D63E21DF3A2A6853C2DC675EDDD4259F3B78490A4988B49FF3DB7B2891B3B48D |
| Benutzer2 | password123+44534C70C6883DE2 | D63E21DF3A2A6853C2DC675EDDD4259F3B78490A4988B49FF3DB7B2891B3B48D |
Im Gegensatz zum Salt bietet der Pepper keinen Schutz für Benutzer, die dasselbe Passwort verwenden, sondern schützt vor Wörterbuchangriffen , es sei denn, der Angreifer kennt den Pepper-Wert. Da derselbe Pepper nicht zwischen verschiedenen Anwendungen geteilt wird, kann ein Angreifer die Hashes einer kompromittierten Datenbank nicht für eine andere wiederverwenden. Ein vollständiges Sicherheitskonzept für Passwörter kann sowohl Salt als auch Pepper verwenden. Beispielsweise wurde vorgeschlagen, den Pepper durch Verschlüsselung der gesalzenen Passwort-Hashes zu kombinieren, wodurch eine Rotation des Peppers ermöglicht wird. [ 11 ]
Bei einem gemeinsam genutzten Pepper kann ein einziges kompromittiertes Passwort (durch Passwortwiederverwendung oder andere Angriffe) zusammen mit dem Salt des Benutzers dazu führen, dass der Pepper aufgedeckt und somit wirkungslos gemacht wird. Kennt ein Angreifer das Klartextpasswort, den Salt des Benutzers und den Algorithmus zum Hashen des Passworts, kann er den Pepper durch Brute-Force-Angriffe ermitteln. Aus diesem Grund empfiehlt das NIST, dass der geheime Wert mindestens 112 Bit lang ist, um seine Ermittlung durch eine vollständige Suche extrem aufwendig zu gestalten. [ 1 ] Der Pepper muss für jede Anwendung, in der er eingesetzt wird, neu generiert werden, da eine Sicherheitslücke in einer Anwendung sonst die Sicherheit anderer Anwendungen beeinträchtigen würde. Ohne Kenntnis des Peppers ist es deutlich schwieriger, andere Passwörter in der Datenbank aus ihren Hashwerten zu extrahieren, da der Angreifer sowohl das Passwort als auch den Pepper erraten müsste.
Ein Pepper erhöht die Sicherheit einer Datenbank mit Salts und Hashes, denn ohne den Pepper ist es für einen Angreifer praktisch unmöglich, auch nur einen einzigen Hash zu knacken – unabhängig von der Stärke des ursprünglichen Passworts. Selbst mit einer Liste von (Salt, Hash)-Paaren muss ein Angreifer zusätzlich den geheimen Pepper erraten, um das zugehörige Passwort zu finden. Die NIST-Spezifikation für einen geheimen Salt empfiehlt die Verwendung einer passwortbasierten Schlüsselerzeugungsfunktion (PBKDF) mit einer zugelassenen Pseudozufallsfunktion wie HMAC mit SHA-3 als Hash-Funktion. Die NIST-Empfehlung sieht außerdem vor, mindestens 1000 Iterationen der PBKDF und weitere mindestens 1000 Iterationen mit dem geheimen Salt anstelle des nicht-geheimen Salts durchzuführen.
Eine zufällig ausgewählte Paprikasorte, die wiederentdeckt werden muss
Ziel dieses Mechanismus ist es, die Passwortverifizierung zu verlangsamen und dadurch Angriffe zu erschweren. [ 4 ] [ 14 ] Das Ziel ähnelt der Erhöhung der Iterationsanzahl bei bcrypt oder Argon2 , der Mechanismus selbst ist jedoch anders. Das geheime Salt oder Pepper muss vom Verifizierer oder Angreifer jedes Mal durch Raten neu ermittelt werden.
In dieser Situation wird die Passwort-Hashfunktion sowohl mit dem Passwort als auch mit dem Pepper berechnet. [ 4 ] [ 14 ] Bei der Passwortspeicherung wird der Pepper zufällig aus einem Bereich zwischen 1 und R gewählt, der Hashwert mit dem Passwort und dem Pepper berechnet und zusammen mit dem Benutzernamen gespeichert. Der Pepper wird anschließend verworfen. Bei der Passwortverifizierung erhält der Prüfer einen Benutzernamen und ein Passwort zur Überprüfung. Der ursprünglich berechnete Hashwert wird für den gegebenen Benutzernamen abgerufen, und anschließend wird der Hashwert des Passworts sowie jedes Wertes zwischen 1 und R berechnet. Stimmt einer dieser Hashwerte mit dem gespeicherten Passwort-Hashwert überein, gilt das Passwort als gültig. Wichtig: Die möglichen Werte des Peppers sollten nicht in einer dem Angreifer bekannten, festen Reihenfolge getestet werden, da sonst ein Timing-Angriff den Pepper aufdecken könnte. [ 14 ] Ist das Passwort korrekt, wird der richtige Pepper im Durchschnitt nach R/2 Hash-Auswertungen gefunden. Ist das Passwort falsch, müssen alle R Werte getestet werden, bevor das Passwort verworfen werden kann.
Siehe auch
Referenzen
- ^ a b „NIST Special Publication 800-63B“ . 16.12.2022. Abschnitt 5.1.1.2 . Abgerufen am 10.10.2023 .
... Prüfer SOLLTEN eine zusätzliche Iteration einer Hash- oder Verschlüsselungsoperation mit einem geheimen Schlüssel durchführen, der nur dem Prüfer bekannt ist.
- ^ a b Akhawe, Devdatta (21.09.2016). „Wie Dropbox Ihre Passwörter sicher speichert“ . Dropbox.tech . Abgerufen am 04.11.2020 .
- ^ a b Bellovin, Steve (1995-04-16). "passwd hashing algorithm" . seclists . Abgerufen am 11.11.2020 .
- ^ a b c Manber, Udi (1996). „Ein einfaches Schema, um Passwörter basierend auf Einwegfunktionen deutlich schwerer zu knacken“ . Computers & Security . 15 (2): 171–176 . doi : 10.1016/0167-4048(96)00003-x . Abgerufen am 11.11.2020 .
- ^ Blake, Ross; Jackson, Collin; Miyake, Nick; Boneh, Dan; Mitchell, John (2005). „Stärkere Passwortauthentifizierung durch Browsererweiterungen“ . USENIX Security Symposium : 17–32 . Abgerufen am 11.11.2020 .
- ^ Schöning, Lars (25. Januar 2006). „Nur Hash-Datenübertragung (Pepper)“ . Newsgroup : sci.crypt . Abgerufen am 27. Mai 2026 .
- ^ cyrusthevirus (7. Juni 2007). „Fakten über Bruce Schneier“. Newsgroup : it.test .
Die meisten Leute salzen ihr Haschisch. Bruce salzt und pfeffert es.
- ^ a b Webster, Craig (03.08.2009). „Passwörter mit Salt, Pepper and Rainbows schützen“ . Barking Iguana . Abgerufen am 11.11.2020 .
- ^ Wenzel, Fred (12.03.2011). „History for django-sha2/django_sha2/bcrypt_auth.py“ . GitHub . Abgerufen am 11.11.2020 .
- ^ Patrick Mylund Nielsen (30. Mai 2012). „Generierung von Salt für die Verschlüsselung mit Golang“ . golang-nuts (Mailingliste).
- ^ a b c Duong, Thai (05.09.2020). „Warum Sie Passwort-Hashes verschlüsseln sollten“ . vnhacker blogspot . Abgerufen am 11.11.2020 .
- ^ @Sc00bzT (18.09.2020). „Pepper bedeutete früher „ein nicht-kryptografisches Salt“." ( Tweet ) – via Twitter .
- ^ „Brute-Force-Angriff auf UNIX-Passwörter mit einem SIMD-Computer“ (PDF) . August 1999.
- ^ a b c d van Oorschot, Paul (2021). Computersicherheit und das Internet . Schweiz: Springer. ISBN 978-3-030-83410-4Abgerufen am 30.05.2026 .