[lug-ld] PW+Salt jetzt geklärt

[Christian Boltz]

Hallo Heinz, hallo zusammen,

Am Mittwoch, 7. August 2019, 22:49:26 CEST schrieb Pahle Heinz:
> Also, wenn ich die Passwortdatei klaue, dann habe ich das
> Hash-Verfahren ($..$) und Salt ($..$) parat. Salt verhindert nicht im
> geringsten das Erlangen des PWs. Denn: Ich "kurbele" eine Variable
> durch, füge jedesmal Salt dazu, hashe und vergleiche was herauskommt
> mit dem was in der Datei steht. 

Wenn Du wirklich eine Liste von Passwörtern durchprobierst und jedesmal 
Salt + geratenes Passwort hashst, bringt der Salt tatsächlich nichts.
Daher: Ja, bei Brute Force ist ein Salt tatsächlich nutzlos.


Jetzt stell Dir mal vor, jemand hat z. B. die Passwort-Datenbank eines 
großen Mailproviders mit ein paar Millionen Passwörtern geklaut. Da für 
alle Benutzer eine Passwortliste per Brute Force durchzutesten und 
jedesmal zu hashen, braucht einiges an Rechenleistung. Wenn es für den 
Angreifer blöd läuft, wird das Datenleck entdeckt und alle Passwörter 
geändert, bevor er auch nur eins davon für den Spamversand missbrauchen 
kann.

Stattdessen wird ein Angreifer lieber eine "Rainbow Table" (also eine 
Liste von Passwörtern mit zugehörigem Hash) verwenden. Einen Hash in der 
Liste suchen geht deutlich schneller als auch nur die 100 beliebtesten 
Passwörter zu hashen ;-)

In solchen Fällen hilft ein Salt, weil es den Aufwand für den Angreifer 
hochtreibt - statt einer Rainbow Table bräuchte er für jeden möglichen 
Salt eine Rainbow Table. Sogar wenn Du der Salt nur zwei zufällige 
Großbuchstaben enthält, erhöht das den Aufwand um 26^2, also Faktor 676, 
bei zwei Groß- oder Kleinbuchstaben um (2*26)^2, also Faktor 2704.
Ein Salt mit drei Groß- oder Kleinbuchstaben kommt auf (2*26)^3, also 
Faktor 140608.

"Drei Groß- oder Kleinbuchstaben" hört sich harmlos an, macht aber 
Rainbow Tables selbst bei großen Mengen Passwort-Hashes eher nutzlos.


Ähnlich sieht es aus, wenn jemand gezielt das Passwort eines einzelnen 
Accounts knacken will - auch hier kostet ein Salt den Angreifer Zeit, 
weil er nicht vorher eine Rainbow Table bauen kann. Der zeitliche 
Abstand zwischen Passworthash klauen und Passwort missbrauchen wächst 
also von einer Sekunde Rainbow Table ablesen auf (geraten) mindestens 
Stunden, eher Tage für Brute Force. Und das alles nur wegen ein paar 
Byte Salt ;-)


Ich würde übrigens beim Passwort-Hashing zu z. B. Bcrypt raten, weil das 
bewusst langsam/aufwändig implementiert ist und daher Brute Force und 
das Erstellen von Rainbow Tables ausbremst. 
Leseempfehlung dazu: https://de.wikipedia.org/wiki/Bcrypt - 
hauptsächlich die Abschnitte "Hintergrund" (letzter Absatz) und "Design"

> Nebenbei: Salt erzeugen ist genauso
> eine Wissenschaft wie Init-Vektor erzeugen z.B. bei AES256 (ist bei
> mir schon jahrelang im Einsatz, bis auf AES-lib mein Werk).

Jein ;-) - sogar ein schlechter Salt (z. B. die ersten zwei Buchstaben 
des Vornamens - theoretisch 26^2, praktisch weniger, weil manche 
Buchstabenkombinationen oft und andere nie auftreten) ist deutlich 
besser als kein Salt. 

Ein zufälliger Salt (im Sinn von "kryptographisch zufällig") ist 
natürlich deutlich besser.

> Statt den einzigen Grund für Salt, wie ich glaube, gleich zu
> offerieren, wird in Artikeln Unzutreffendes genannt (brute force
> Erleichterung) und nebenbei nur angedeutet, was ich als einzigen
> Grund sehe. Also jetzt: Habe ich die PW-Datei und es gäbe keinen
> Salt, dann sähe ich gleich, wenn Müller, Maier, Schulze das gleiche
> PW hätten (natürlich nicht das PW selbst)!!! D.h.: Habe ich Müller
> geknackt, dann sind anderen 2 ebenfalls "offen".

Das ist ein (im wahrsten Sinn des Wortes) offensichtlicher Grund, aber 
- siehe oben - nicht der einzige.

> Wie man sieht, immer wieder das Gleiche (Verschleiern gleicher Daten),
> wie ich das mit WW2 beschrieb. "Keine besonderen Vorkommnisse"
> konnten sich die Briten denken, denn Bojen bombadieren, Trick,
> brachte andere Meldung als immer wieder die Gleiche, wenn nix los
> war.

Genau, da hätte eine Prise Salz geholfen ;-)


So, und jetzt noch eine kleine Aufgabe zum Abschluss: Welches Passwort 
steckt im (ungesalzenen) Hash 
b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9
?

Dazu zwei Tips:
- Das ist eine sha256sum - aber das ist fast egal
- Die Lösung kann jeder ohne Brute Force innerhalb von Sekunden 
  rausfinden

Für den unwahrscheinlichen Fall, dass niemand die Lösung findet, erkläre 
ich den Lösungsweg gern beim nächsten Treffen ;-)

> Jetzt noch ein Glas Wein auf alle, die mitmachten

Prost! ;-)


Gruß

Christian Boltz
-- 
I've been doing this 10.1 test work just like a real user:
In other words I never read any release notes or documentation :-)
[tomhorsley(at)adelphia.net in opensuse-factory]