Die absolut korrekte Lösung ist übrigens, WEDER http:// noch https:// fest anzugeben, sondern die URL mit // beginnen zu lassen, analog:Demon0no schrieb:googlecode unterstützt https, also verlinke es auch richtig.
HTML:
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>
Es mag empfohlen sein, es ist aber unpraktisch.Kanibal schrieb:Tatsächlich ist Client-Side Hashing das empfohlene Verfahren: https://www.owasp.org/index.php/OWASP_Application_Security_FAQ#Should_I_use_40-bit_or_128-bit_SSL.3F
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.
Wie oft muss man den Leuten noch sagen, für kritische Dienste nicht dasselbe PW zu verwenden?_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.
Wegen Heartbleed jetzt in Panikreaktionen zu verfallen und obskure Krypto-Lösungen selbst zu basteln, das bringt doch alles nichts.
Salts sind oftmals "öffentlich", im weitesten Sinne. Sie werden oft zusammen mit dem gehashten Passwort gespeichert. Warum auch nicht?_CH_K_1991_ schrieb:Und dennoch ist ein Salt in Javascript aus meiner Sicht nicht so praktisch (kann ja von allen eingesehen werden)
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.