@rexcolo: Nein, hab ich nicht.
Klassischerweise ist der Pepper ein String, der im Quellcode oder einer Config-Datei hinterlegt wird, und damit nur zur Laufzeit im Arbeitsspeicher der Anwendung vorhanden ist. Wird die Datenbank gedumpt, sorgt der Pepper dafür, dass trotz der bekannten Salts und der bekannten Hashes die Kennwörter nur sehr viel schwerer gebrochen werden können.
Natürlich KANN man einen Pepper über eine zweite Datenbank abbilden, damit ist er aber de facto nur ein zweiter Salt, und der Zugriff auf die Datenbank zur Laufzeit ist das nächste Problem, denn wenn ich als Angreifer eine Datenbank dumpen kann, kann ich üblicherweise auch die zweite dumpen, damit hast du also nicht wirklich viel gewonnen. Deshalb ja Config-Datei, die dumpt man nämlich nicht, sondern liest sie beim Start ein bzw. bekommt bei solchen Dingen die Werte via Umgebungsvariable rein, weil die Anwendung selbst nichtmal Zugriff auf die Konfigdatei hat, damit tut sich ein Angreifer sehr schwer.
So, und jetzt noch der Punkt mit Peppering mit randomisierten Daten. Kann man machen. Skaliert nur scheiße. Grund: Statt einen Hash zu rechnen, muss ich (bei den genannten 8bit-Peppers) 256 Hashes rechnen und jeden einzelnen vergleichen. Das ist DUMM. So richtig haarsträubend dumm, weil mit jedem weiteren Nutzer dein Aufwand exponentiell ansteigt. Serverseitig, wohlgemerkt. Was das zusätzlich Traffic auf eine Datenbank bedeutet, ist nicht ohne. Woher ich das weiß? Sagen wir, ich hab in meiner aktuellen Arbeit eine etwas größere Replikationsstruktur rumstehen, wir reden hier vom oberen dreistelligen Bereich, und wenn der ein oder andere Kollege eine etwas interessantere Datenbankabfrage startet, kreischt das Monitoring, dass die Slaves hinterher hinken. DUMME Idee.
Ziel eines Hashes ist üblicherweise, die Berechnung für legitime Parteien so schnell und einfach wie möglich zu machen, und einen Angriff darauf trotzdem so komplex wie irgend möglich zu gestalten. Daher ist es bedeutend sinnvoller, einfach nur nen besseren Algorithmus zu nehmen. bcrypt zum Beispiel wird extrem schnell sehr rechenintensiv, weil zum eigentlichen Hashing ein Kostenfaktor kommt, der die Anzahl der Iterationen festlegt. Warum ist das besser als 256 einfache Rechnungen? Weil die WAITs geringer ausfallen - ich schubse die Funktion und die Parameter einmal in die CPU, und dann rechnet die, ich bekomme ein Ergebnis, das ich mit einer Datenbankabfrage abfrühstücke. Bei der Methode mit randomisierten Peppers sind das 256 Pushes mit den entsprechenden Random-Peppers (das sind damit auch 256 waits, mit der du den Serveradmins viel Freude machst), plus 256 Abfragen an die Datenbank, die auch immer ganz toll sind. Oder, alternativ, was konzeptionell z. B. bei LDAP gar nicht mehr funktioniert, erst den Hash aus der DB lutschen, und dann mit for i in 256; do if RESULT = HASH; then LOGIN=OK; break; done in der Anwendung drüberiterieren. Scheißidee. Ach, und natürlich kannst du die Berechnung abbrechen, wenn einmal OK zurück kommt - das ist aber noch rechenintensiver, weil mit noch mehr Wartezeit verbunden, weil das dann definitiv sequentiell abgearbeitet werden muss und nichtmal Parallelisierung zulässt.
Der einzige Punkt, bei dem die Random-Pepper-Methode theoretisch besser ist als die mit statischem Pepper ist folgendes Szenario:
Ist die Verschmelzungsmethode von Pepper, Salt und Passwort bekannt, die Methode selbst eine Verschachtelung aus Hashingfunktionen, und es liegen Hash, Salt UND das Passwort im Klartext vor, lässt sich mit vergleichsweise geringem Aufwand eine BruteForce-Attacke schreiben, welche den Pepper zum Ziel hat. Ein Beispiel wäre z. B. "md5(PEPPER+md5(SALT+md5(PASS)))". Ist der Pepper erraten, kann die BruteForce-Attacke zweistufig gefahren werden, nämlich indem eine Rainbow-Table für die unbekannte Komponente erstellt wird (d. h. mit dem Ziel X=md5(PASS)), während nur noch Hashes für die unbekannten Komponenten erbrütet werden, was durch den Wegfall der äußeren Hashfunktionen einfacher ist. Caveat: Funktioniert nur mit annehmbarem Aufwand, wenn der Pepper schwach ist. Ergo: NIE.
Ja, ich kenne Peppering. Ziemlich gut sogar, und nicht erst seit gestern. Und da ich auch schon die ein oder anderen Algorithmen/Hashes mit der Brechstange bearbeitet habe, kann ich da denke ich auch etwas mitreden.