Ist es schlau ein Hash wieder zu hashen?
z.B. SHA256(SHA256(string))
5 Antworten
WPA nutzt zB eine derartiges mehrfaches hashen. In dem Fall nicht 2x sondern 4096x (wenn ich mich recht erinnere)...
Das Ergebnis kann man hier gut sehen: https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a270c40
Ob das prüfen eines Passworts bei der Eingabe 0,001 oder 0,4 Sekunden dauert ist für den Login-Vorgang unerheblich aber beim Knacken des hashes wird der Angreifer deutlich ausgebremst. Das kann den Unterschied ausmachen ob ein Bruteforce-Angriff "nur" ein paar Tage oder ein paar Jahre dauert...
Es gibt aber diverse andere Techniken die das PW oder die Login-Session erbeuten können:
- Phising / Social Engeneering
- Trojaner die Session-Cookies oder gespeicherte PW stehlen
- XSS in der Seite um Cookies zu erbeuten
- Keylogger
- usw.
Mehrfaches Hashen sorgt also m.M.n. für mehr Sicherheit da Angriffe einfach länger dauern und oftmals scheitern Scriptkiddies an derartigen Hürden da eben keines der 0815-Tutorials funktionieren wird...
Es kommt drauf an was du erreichen willst
Mehr Sicherheit bringt das nicht wirklich, nein.
Die Schwachstelle ist meist sowieso das Passwort selbst und nicht der Hash.
- SHA256 ist sowieso nur „security by obscurity“ AFAIK...
- d. h.: es ist nicht bewiesen, dass es nicht leicht ist, eine Eingabe zu konstruieren, die einen bestimmten SHA256-Wert hat...
- das doppelte hashen hilft nicht, glaube ich... es könnte vielleicht sogar schädlich sein... nur weil es obskurer ist, bedeutet es nich, dass es sicherer ist... grins
"SHA256 ist sowieso nur „security by obscurity“ AFAIK..."
Dann hast du da wohl was falsches gehört.
SHA256 ist sowieso nur „security by obscurity“ AFAIK...
Da verwechselst du wohl SHA256 und MD5 miteinander.
es ist nicht bewiesen, dass es nicht leicht ist, eine Eingabe zu konstruieren, die einen bestimmten SHA256-Wert hat...
Es ist ebenfalls nicht bewiesen, dass es leicht ist...
Das Problem ist eher die Definition von leicht. Und vielleicht gibt es auf diesem Planeten einfach noch keinen der die Schachstelle in xyz gefunden hat. Das kann sein. Auch Beweise könnten ja fehlerhaft sein.
Die Praxis und die Wmpfehlungen der Behörden zeigen jedoch: SHA256 gilt bisher als recht sicher, wobei man langsam schon auch SHA384 oder SHA512 gehen sollte für kritische Anwendungen.
- One Time Pad kann man bestimmt auch zum Hashen verwenden...
- man bildet zum Beispiel die Summe der Bytes modulo (2^512) und dann XOR-t man diese Summe mit den nächsten 512-Zufalls-Bits...
- LOL
- oda? ist jetzt nur son Schnellschuss von mir...
- wenn man verhindern will, dass bei bekannter Prüf-Summe die Zufalls-Bits einfach ausgerechnet werden, dann macht man es eben so wie ich es da mal getippt hab... gleich nach „vllt doch lieber so: *kicher*“: Link
- Collision resistance (CR): ja... hast recht... da du nur die Summe zu fälschen brauchst... hm... da gibt es aber bestimmt schon was, das erweislich sicher ist... ich find es nur grad nich... wenn man das unter meinem Punkt (5) verlinkte Verfahren verwendet, sind Manipulationen ziemlich unmöglich, so dass man auf Hash-Werte zur Integritätsprüfung ohnehin verzichten kann...
- begrenzt ist die Länge des Hash-Wertes doch immer... oda? was meinst du überhaupt mit „kryptographisch sicher“? ich kenn das nur im Zusammenhang mit Zufallszahlengeneratoren (da könnte man sich ja auf echten Zufall zurückziehen) und „kryptographische Hash Funktionen“ (da fehlt aber das „sicher“) (da geht es aber nur um CR): Cryptographic hash function
Ein Prüfbit? Lustige Idee. Hashfunktionen werden auch benutzt im Prüfsummen zu berechnen. Da ist dann das Prüfbit 128bit und länger und das ist mitunter schon problematisch.. weil CR.
Ansonsten ist das Problem an einem XOR und dann der Summe zum Hashen, dass man nicht garantiert erkennen kann wenn 2 Zwichen vertauscht wurde. Ups. Und dann siehe den letzten Absatz, ein Prüfbit löst dieses grundliegende Problem auch nicht.
PS: Auch noch zu deinem Algorithmus: hash(abc) sollte immer == hash(abc) ein. Keine Ahnung wie das mit Zufallsbits im Hash funktionieren soll.
Man merkt wie viel Ahnung du hast. OTP ist keine Lösung für alles. Sonst gäb es keine Probleme mit Kryptographie. Aber schön, dass du zufällig genau einen Alogirthmus zur Verschlüsselung kennst.
- Frechheit! LOL
- wo schreib ich was von nem „Prüfbit“?
- ich schreib, dass man OTP verwenden kann, um eine Nachricht nich nur zu verschlüsseln sondern auch deren Echtheit nachzuweisen...
- und meine OTP-Hash-Funktion von vorhin ist tatsächlich keine „kryptographische Hash Funktion“... hab ich doch schon zugegeben... warum reitest da noch drauf rum? nich gesehn? grins
- wofür du „kryptographische Hash Funktionen“ brauchst, weiß ich nich...
- das Gute an mir ist, dass meine Lösung funktioniert, während man deiner „Lösung“ nur derzeit mit öffentlich zugänglicher Forschung nich nachweisen kann, dass sie Schrott ist...
Dann schildere mir bitte doch nochmal genau was dein Algorithnus tut. Ziel ist es zB
1.) ein Passwort unlesbar zu machen
Und
2.) Eine kurze Repräsentation einer Nachricht zu bekommen um Änderungen zu erkennen.
Bitte überzeuge mich, dass du da etwas geniales erfunden hast.
- |das Passwort kann man na klar mit dem von mir unter Punkt (5) verlinkten Verfahren unlesbar machen... damit könnte man sogar ne einfache Prüfsumme (also nur die Bytes addieren in ner Restklassengruppe) sicher machen, weil du aus dem Chiffrat die Prüfsumme nich rausfindest, wenn du keinen Zugang zum Pad hast... mit Zugang zum Pad ist OTP na klar transparent... aber das wäre ja ohnehin der Fall, wenn man Zugang zu nem Passwort-File hat, dann würd ich ohnehin die Geheimhaltung für zerstört halten... d. h. bei mir sind diese lächerlichen SIP bezogenen Passwörter für jeden sichtbar, der Zugang zur Console hat...
- eine „kurze Repräsentation“ kriegt man mit dem von mir unter Punkt (5) verlinkten Verfahren gar nich hin... es ermöglicht nur, dass Änderungen erkannt werden... aber dazu muss man bis zum ersten falschen Bit lesen.... von vorn oder von hinten oder kunterbunt...
Kleine Frage: Was it otp und was ist ktb? Und du verschlüsselt im Prinzip was? Eine Menge an Bytes in EIN Byte?
Ganz nebenbei holt das nur ein Byte aus einer Liste an Bytes. Verschlüsseln tut das leider gar nichts.
Tut mir leid, dass du von deiner Kompetenz so überzeugt bist.
- ey! du bist aber emotional...
- hast also noch Verständnis-Fragen, bist dir aber schon sicher über dein abschließendes Urteil... witzig... find ich...
- also... „otp“ ist eine Deque, die die Zufalls-Bytes (also das Pad eben) enthält... und „ktb“ ist das „KlarTextBit“, das als nächstes verschlüsselt werden soll...
Das macht es zumindest sicherer
Naja, wenn du z.B an den Angriff mit Regenbogentabellen denkst, wird der Angreifer länger brauchen um den richtigen Hash zu finden.
Ich glaub hier kann man dazu noch etwas finden https://en.wikipedia.org/wiki/Key_stretching
Es bringt also schon ein Wenig mehr Sicherheit (auch wenn es nur marginal ist...)
Sinnvoller als 2 Mal zu hashen wäre es daher eher das zB 1.000 Mal zu machen. Zumindest würde das eher etwas gegen brute-force Angriffe bringen.
So ist es... aber wie du selbst schon angemerkt hast, ist das Problem meist das unsichere Passwort des Endnutzers.
- das setzt voraus, dass SHA256 wirklich sicher ist...
- es ist auch die Frage, ob man nicht eher die Rechenleistung lieber in einen aufwändigeren Hash-Algorithmus stecken sollte (aber dann nur einmal)...
Weder besonders schlau noch besonders unschlau.
Eher nutzlos.
Die einzige "sinnvolle" Verwendung für einen "Mehrfachhash" wäre mMn. die Ableitung eines KeyStreams aus einer Passphrase.
Mehr SIcherheit