JavaScript Hash-Algorithmen

ascer · 7. Februar 2015

Huhu Community,

ich entwickle aktuell eine Webapplikation, bei der ich gerne schon im FrontEnd vor dem AJAX http-request an den Server Sachen wie Passwörter hashen möchte.
Dazu wäre eine Javascript-Hashbibliothek ganz nett, unter anderem findet man da folgendes per Google:
-> https://code.google.com/p/crypto-js/

Hat da jemand eventuell Erfahrungen mit?
Da derartige libs immer recht viel Code beinhalten, wäre es natürlich ganz nett zu wissen, ob der Code vertrauenswürdig ist oder irgendwo in Zeile 69.412 "nach Hause telefoniert" wird..

Eventuell sonst noch andere/bessere Empfehlungen für ähnliche libs?

Zweite Frage: Auswahl des richtigen Hash-Algorithmus. Da md5 schon in die Jahre gekommen ist und es ja mittlerweile relativ "viele" dokumentierte Kollisionsattacken gibt wäre meine Wahl jetzt auf SHA-256 als Algorithmus gefallen.

Gibt es diesbezüglich Bedenken oder eine bessere Wahl?

viele Grüße & Danke

ascer

fz21z · 7. Februar 2015

oAuth wären sonst noch eine gute Wahl.

http://de.wikipedia.org/wiki/OAuth

Edit:

Das wäre Serverseitig, ... ob Clientseitig überhaupt nützlich ist k.A.
Wir nutzen ReST mit oAuth über SSL in der Firma.

Fritz · 8. Februar 2015

"nach hause telefonieren"

Würde ja selber nur über AJAX gehen. Denke, die Libs sind so offen, das wäre zu offensichtlich. Oder probier es mal zu testen aus, wirst ja mit Firebug und co sehen, ob irgendwelche Requests abgsetzt werden.

zu den Algorythemen

Würde MD5 nicht mehr empfehlen, dass wäre zu einfach über Rainbow Tabellen herauszufinden.
SHA2 oder 3 ist ok.

würde aber eher schauen, dass deine webapp HTTPS ist und das ganze üer POST übermitteln und dann auf dem Server hashen, speziell wenn du z.b. das passwort noch "salten" (salzen) willst. Das ist dann z.b. bei einem User welcher du in einer DB speicherst noch ein zusätzlicher String, der in der Tabelle mitgespeichert wird, kann eine Zufallszahl sein oder z.B. eine UUID. Damit erreichst du, dass wenn alle user z.B. "1234" als Passwort eingeben würden, jeder einen eigenen Hash hätte und nicht immer den gleichen.

-> nach "adding salt" suchen
[https://crackstation.net/hashing-security.htm]

Smug-P · 8. Februar 2015

Meinst du clientseitig zu hashen ist eine gute Idee? Was waere denn, wenn der Hash auf dem Weg zum Server veraendert wird?

ascer · 8. Februar 2015

@Smug-P: warum nicht? wenn der Hash auf dem Weg verändert werden sollte, würde das am Server ja auffallen. Salting findet natürlich erst auf dem Server selbst statt. Ich sehe da eigentlich nur den Vorteil, dass sensible Daten wie Passwörter nichtmal innerhalb der SSL-Verbindung in Klartext übertragen werden.

John Reese · 8. Februar 2015

Wenn du HTTPS verwendest, dann kann Hashing sogar kontraproduktiv sein.
Außerdem: SHA1/2/3 bzw. MD5 zum Hashen verwenden? Pah...

http://php.net/manual/de/faq.passwords.php (für PHP)

Kanibal · 8. Februar 2015

ascer schrieb:
Ich sehe da eigentlich nur den Vorteil, dass sensible Daten wie Passwörter nichtmal innerhalb der SSL-Verbindung in Klartext übertragen werden.

Das Problem ist: Wenn jemand deine HTTPS-Verbindung soweit knacken kann, dass er deine übertragenen Daten auslesen kann, könnte er auch die Javascript-Hashing Library vorher ausschalten.

fz21z · 8. Februar 2015

Kann mich dem Ganzen nur anschließen und nochmal auf oAuth und ReST mit SSL verweißen.
Token serverseitig generien und bei jeder Anfrage im Header mitschicken.

Smug-P · 8. Februar 2015

ascer schrieb:
@Smug-P: warum nicht? wenn der Hash auf dem Weg verändert werden sollte, würde das am Server ja auffallen. Salting findet natürlich erst auf dem Server selbst statt. Ich sehe da eigentlich nur den Vorteil, dass sensible Daten wie Passwörter nichtmal innerhalb der SSL-Verbindung in Klartext übertragen werden.

Wie denn? Machst du noch einen MAC über den Hash oder was?

ascer · 8. Februar 2015

CryNickSystems schrieb:
Wenn du HTTPS verwendest, dann kann Hashing sogar kontraproduktiv sein.

Wieso das? Magst du das erläutern?

CryNickSystems schrieb:
Außerdem: SHA1/2/3 bzw. MD5 zum Hashen verwenden? Pah...

Also auch nach dem Lesen des Links verstehe ich jetzt nicht ganz, was an SHA-256 verkehrt sein sollte?

Kanibal schrieb:
Das Problem ist: Wenn jemand deine HTTPS-Verbindung soweit knacken kann, dass er deine übertragenen Daten auslesen kann, könnte er auch die Javascript-Hashing Library vorher ausschalten.

Das stimmt, aber es sollte doch trotzdem zusätzliche Sicherheit bieten?!

fz21z schrieb:
Kann mich dem Ganzen nur anschließen und nochmal auf oAuth und ReST mit SSL verweißen.
Token serverseitig generien und bei jeder Anfrage im Header mitschicken.

Vielen Dank nochmal für den Hinweis, das hört sich in der Tat interessant an, werde ich weiter evaluieren.

Smug-P schrieb:
Wie denn? Machst du noch einen MAC über den Hash oder was?

Ich verstehe die Frage nicht ganz?

Clientseitig wird der SHA-256 Hash vom Passwort gebildet, dann wird der Hash gesendet.
Auf dem Server ist die Authentifizierung genau dann positiv, wenn der Hash vom (user unique) Salt + Benutzernamen + Passworthash den der Client sendet matched.

Daaron · 8. Februar 2015

Stell dir immer die Frage, ob deine Webapplikation wirklich unbedingt JavaScript voraussetzen muss/darf. Wenn es einen sinnvollen Anwendungsfall gibt, in dem JS deaktiviert ist (Braille-Terminal, Screen Reader, aktives NoScript, rigorose Firmenpolitik,...), dann ist dein gesamter Client-Side-Hash - Plan für die Tonne.

Kanibal · 8. Februar 2015

ascer schrieb:
Das stimmt, aber es sollte doch trotzdem zusätzliche Sicherheit bieten?!

Ehrlich gesagt, ich weiß es auch nicht. Es wird hin und wieder empfohlen, es gibt aber auch genügend Gründe, die dagegen sprechen.
Meine persönliche Meinung dazu: Es gibt effektivere Stellschrauben, an denen Du mit mehr Erfolg drehen kannst. TLS-Verfahren, Certificate Pinning, starkes Hashing in der Datenbank (kein md5/SHA_x, sondern scrypt und co.), nur um mal ein paar zu nennen.

Daaron · 8. Februar 2015

Ein Punkt spricht gegen Hashing vor dem Versand: der Zeichensatz und die Länge der übermittelten Informationen sind dadurch deutlich eingeschränkt. Für einen Brute-Force - Angriff ist das eine sehr lohnende Information.

ascer · 8. Februar 2015

Alles klar, vielen Dank!

Dann werde ich das hashen clientseitig mal sein lassen.

Smug-P · 8. Februar 2015

Versuche einfach bekannte und getestete Lösungen (wie schon genannt) einzusetzen. Wenn du keine Ahnung von Krypto hast und versuchst, durch eine eigene Implementierung mehr "Sicherheit" zu schaffen, geht das in 99% der Fälle nach hinten los.

ice-breaker · 9. Februar 2015

Daaron schrieb:
Ein Punkt spricht gegen Hashing vor dem Versand: der Zeichensatz und die Länge der übermittelten Informationen sind dadurch deutlich eingeschränkt. Für einen Brute-Force - Angriff ist das eine sehr lohnende Information.

Und diese starke Einschränkung beinhaltet für zB. SHA-256 immer noch 2^256 mögliche Passwortkombinationen. Dein Argument mag in der Theorie Bestand haben, aber in der Praxis wird es keine Rolle spielen.

Yuuri · 10. Februar 2015

ice-breaker schrieb:
Und diese starke Einschränkung beinhaltet für zB. SHA-256 immer noch 2^256 mögliche Passwortkombinationen.

Öhm... Nein? Bei Hashes (hier SHA-256) werden 64 Zeichen mit dem Wörterbuch [0-9a-f] übertragen. Da reicht n relativ gutes Passwort mit Unicode-Zeichen aus und du sprengst den Hash evtl. in der Länge, sowie im Wörterbuch. Vier Billionen mögliche Zeichen sind ein paar mehr als die eines Hashes. Per Bruteforce also einfacher zu knacken, da bedeutend weniger Zeichen und Kombinationen durchprobiert werden müssen.

ice-breaker · 10. Februar 2015

Ich weiß nicht auf welchem Planeten du lebst aber SHA-256 ist als ein Hash mit einer Ausgabelänge von 256 Bit [1] definiert. Und deine Angabe von einem "Wörterbuch" mit 16 Möglichkeiten und 64 Zeichen passt ebenso zu der Definition: 16^64 = 4^128 = 2^256

[1] http://en.wikipedia.org/wiki/SHA-2#Comparison_of_SHA_functions

Suche

JavaScript Hash-Algorithmen

ascer

Captain

fz21z

Lt. Junior Grade

Fritz

Cadet 3rd Year

Smug-P

Lt. Junior Grade

ascer

Captain

John Reese

Lt. Commander

Kanibal

Lt. Commander

fz21z

Lt. Junior Grade

Smug-P

Lt. Junior Grade

ascer

Captain

Daaron

Fleet Admiral

Kanibal

Lt. Commander

Daaron

Fleet Admiral

ascer

Captain

Smug-P

Lt. Junior Grade

ice-breaker

Commodore

Yuuri

Fleet Admiral

ice-breaker

Commodore

Ähnliche Themen