JavaScript Lokal Hashen mit Crypto-js

Demon0no schrieb:
googlecode unterstützt https, also verlinke es auch richtig.
Die absolut korrekte Lösung ist übrigens, WEDER http:// noch https:// fest anzugeben, sondern die URL mit // beginnen zu lassen, analog:
HTML:
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>

Kanibal schrieb:
Es mag empfohlen sein, es ist aber unpraktisch.
Regel Nummer 1: Löse nichts über JavaScript, dass du nicht auch problemlos ohne lösen könntest.

Egal, wie nutzlos Script-Blocker effektiv sind, sie haben eine recht weite Verbreitung. All diese User würdest du schon einmal von deinem Dienst ausschließen. Zusätzlich verdienst du dir mit so einer Lösung garantiert keinen BIENE-Award. Barrierefreiheit ist keine Option, sondern meiner Meinung nach ein Must-Have & oberstes Ziel.

_CH_K_1991_ schrieb:
Danke, Ja ich habe mir einfach auch dabei gedacht, dass wenn der Angreifer die Logindaten "erbeutet", sich zwar bei mir einloggen kann, aber auf anderen Websiten die Logindaten nicht durchprobieren kann.
Wie oft muss man den Leuten noch sagen, für kritische Dienste nicht dasselbe PW zu verwenden?

Wegen Heartbleed jetzt in Panikreaktionen zu verfallen und obskure Krypto-Lösungen selbst zu basteln, das bringt doch alles nichts.

_CH_K_1991_ schrieb:
Und dennoch ist ein Salt in Javascript aus meiner Sicht nicht so praktisch (kann ja von allen eingesehen werden)
Salts sind oftmals "öffentlich", im weitesten Sinne. Sie werden oft zusammen mit dem gehashten Passwort gespeichert. Warum auch nicht?
Ein Salt ist kein Geheimnis. Ein Salt soll nicht das Brute Force Cracking erschweren. Ein Salt soll lediglich den Aufbau von Rainbow Tables versauen bzw. erschweren.
 
@Daaron
Das stimmt, dass mit einer solchen Variante sämtliche Nutzer mit Javascript Blocker ausgeschlossen werden. Die Frage ist hier allerdings mMn (bei meinem Fall sowieso), darf man als Webapplikations Hoster Anforderungen an den Client stellen? Ich unterstützte z.B. auch keinen IE 6/ 7 und Firefox 3.x etc. mehr (aktiv), weil es schlicht für diese Applikation nicht rentabel wäre alle Browser komplett abzudecken.
Und dennoch müsstest du mir eine grosse Website zeigen, die komplett ohne Javascript auskommt (z.B. nur schon gmail.com und outlook.com).

Nur nebenbei -> Diese Lösung ist vor Heartbleed entstanden ;-)
 
Daaron schrieb:
Es mag empfohlen sein, es ist aber unpraktisch.
Regel Nummer 1: Löse nichts über JavaScript, dass du nicht auch problemlos ohne lösen könntest.

Egal, wie nutzlos Script-Blocker effektiv sind, sie haben eine recht weite Verbreitung. All diese User würdest du schon einmal von deinem Dienst ausschließen. Zusätzlich verdienst du dir mit so einer Lösung garantiert keinen BIENE-Award. Barrierefreiheit ist keine Option, sondern meiner Meinung nach ein Must-Have & oberstes Ziel.

kA, sag's dem OWASP-Projekt :freaky:
 
_CH_K_1991_ schrieb:
Die Frage ist hier allerdings mMn (bei meinem Fall sowieso), darf man als Webapplikations Hoster Anforderungen an den Client stellen?
Einige Anforderungen schon, z.B. HTML5-Support, wenn man <video> & Co verwendet.
Aber MUSS es denn unbedingt JS sein, wenn es einfach nicht notwendig ist?

Und dennoch müsstest du mir eine grosse Website zeigen, die komplett ohne Javascript auskommt (z.B. nur schon gmail.com und outlook.com).
Sie verwenden Gmail zurzeit in der einfachen HTML-Ansicht.
Geht wunderbar ohne JS. Sieht etwas rustikal aus, bedient sich etwas rustikal, aber es ist gut benutzbar. Keine Ahnung, ob MS so etwas auch können. Im Zweifel: nein.

Du glaubst gar nicht, wie viel man ohne JavaScript machen kann. Viele Entwickler sind doch einfach nur durch JQuery total verwöhnt und kriegen ohne JQuery & Co nicht einmal eine kleine Suckerfish-Navigation mit Einblend-Animation hin.

Kanibal schrieb:
kA, sag's dem OWASP-Projekt :freaky:
Ich sag nur, dass man kein JS voraussetzen sollte.
 
für alle die es interessiert:
http://cryptojs.altervista.org/

da gibt es eine Übersicht + Speedtests

Bei mir ist es so, dass CryptoJS im V1 Test immer langsamer ist als Pajs
Im V2 Test ist CryptoJS teils schneller und Pajs ist recht unstable
mal braucht es 150ms mal 1000ms.

Auch ist Firefox schneller als Chrome

Bei dem Test JS sind beim Testsatz einige angeblich falsch.
Gibt man was anderes ein, sieht man, dass sie dann richtig sind.
 
Zurück
Oben