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

[Christian Boltz]

Hallo Heinz, hallo zusammen,

Am Donnerstag, 8. August 2019, 10:22:42 CEST schrieb Pahle Heinz:
> schade, wollte mir einen abbrechen, um die Aufgabe zu lösen. Aus
> Erfahrung weiß ich, sind die 2 ersten und die 2 letzten Zeichen des
> sha256-hashes bei einem Vergleich auch noch gleich, dann
> hochwahrscheinlich BINGO! So habe ich mir b9 und e9 gemerkt und ein
> wenig mit einem "hasher" herumprobiert. Dann neugierig Christophs
> Link geklickt und sofort auf dieser site b9 und e9 entdeckt. Spiel
> abgebrochen, Lösung gesehen. Ich gebe zu, mit ein paar doofen
> Passworten mein Glück versuchen zu wollen, C.M Spielverderber :)) Nä,
> gar nicht, habe besseres zu tun, lasse mir von C. B. erklären, wie
> ich einen sha256-hash knacke. Da bin ich aber arg gespannt.
> Jedenfalls bräche für mich eine Welt zusammen, gäbe es eine
> Einfachlösung, Regenbogen-Tabelle zählt jetzt aber nicht dazu.

Doch, die zählen definitiv ;-) - und zumindest im Anwendungsfall "jemand 
hat 10 Millionen Mailadressen mitsamt Passworthash geklaut" sind sie die 
einfachste, schnellste und billigste Möglichkeit, einen Teil der 
Passwörter zu knacken. Auch wenn ein Angreifer "nur" 1000 der 10 
Millionen Postfächer knackt, kann er damit fleißig Spam verschicken ;-)

Einen sha256-Hash "knacken" im Sinn von "sage mir den Ausgangstext" kann 
ich (außer mit Brute Force) nicht. Das geht schon rein mathematisch 
nicht, weil beim Hashen Informationen über den Ausgangstext 
verlorengehen und nur die "Checksumme" behalten wird.
(Als bildlicher Vergleich: Aus einer Orange Orangensaft machen/"hashen" 
ist einfach, und sogar wenn Du 99% davon trinkst, ist am Rest noch 
erkennbar, dass das der "Hash" aus einer Orange ist. Im Gegensatz dazu - 
versuch mal, aus dem Orangensaft zu rekonstruieren, wie groß die Orange 
war, wie die genaue Form und Farbe aussah und wie viele Kerne sie 
hatte.)

Das ist aber auch gut so, weil sonst der nächste Schritt, eine 
Hashkollision zu finden und sha256 kaputtzuspielen, nicht mehr weit 
wäre. 
(Der Vollständigkeit halber: Hashkollisionen finden geht auch ohne den 
Ausgangstext beliebiger Hashes rausfinden zu können. Es reicht, wenn man 
rausfindet, dass in einem Ausgangstext z. B. bestimmte Bits für die 
Berechnung des Hashes ignoriert werden oder sich Änderungen von 
bestimmten Bits im Hash gegenseitig aufheben.)

> Rainbow Tables nehmen ja nur Zeichen auf, die man einfach eingeben
> kann. 

Typische Rainbow Tables enthalten *vermutlich* nur gängige Zeichen oder 
sogar nur gängige Wörter und Passwörter - so zumindest meine 
Einschätzung.

Grundsätzlich spricht nichts dagegen, auch Sonderzeichen in einer 
Rainbow Table zu berücksichtigen - ob sich das für den Angreifer lohnt, 
ist natürlich eine andere Frage.

Und genau das ist, was bei Verschlüsselung oft zählt - "lohnt sich der 
Aufwand?" Sobald der Angreifer das mit "nein, ich bin doch nicht 
verrückt" beantwortet, hast Du gewonnen ;-) 

Die Schwelle liegt natürlich je nach Angreifer und Angriffsziel 
unterschiedlich. Wenn es um meine Urlaubsbilder geht, würde ein 
vernünftiger Angreifer wohl nach 10 Minuten aufgeben. Meine 
Signatursammlung wäre manchen Leuten mindestens einen Tag Rechenzeit 
wert ;-) und bei militärischen Geheimnissen kann es sich lohnen, ein 
Jahr lang ein ganzes Rechenzentrum drauf rumrechnen zu lassen.

> Tut mir leid, ich verwende auch Binärzeichen, wobei linefeed
> mein Liebling ist. Gruß an die Konsolenhacker. Ergo: Kennt man ein
> Mittel, dann gibt es auch ein Gegenmittel. Kriege kann man auch nur
> durch einen bis dato unbekannten Trick gewinnen.

Du hast auf jeden Fall ein Mittel, das gegen die üblichen Rainbow Tables 
hilft, und auch gegen Brute Force mit beschränktem Zeichensatz. Damit 
machst Du es einem Angreifer zumindest deutlich schwerer ;-)

Falls es tatsächlich ein Angreifer speziell auf Dich abgesehen hat (was 
eher unwahrscheinlich sein dürfte) - gegen Brute Force mit allen Zeichen 
(incl. Binärzeichen) hilft alles nix, es kostet halt nur etwas mehr 
Rechenzeit.


Gruß

Christian Boltz
-- 
What do we learn from this: DO NOT use reiser4 with Suse Linux 10.0.
Shred and wipe offer easier ways to get rid of your data.
[nordi in opensuse]