JavaScript Hash-Algorithmen

[ascer]

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]

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]

"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]

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

 

[ascer]

@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]

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]

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]

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]

@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]

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

Wieso das? Magst du das erläutern?

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?

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?!

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.

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]

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]

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]

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]

Alles klar, vielen Dank!

Dann werde ich das hashen clientseitig mal sein lassen.

 

[Smug-P]

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]

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]

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]

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