nicht angemeldet
Sicherer Javascript Passwortschutz ?!
0 0 0 
JürgenB
2 
Der Martin
0 0 1 Don't feed the Trolls
0 0
Sicherer Javascript Passwortschutz ?!
Hallo Leute,
auf so ziemlich jeder Website, die sich mit Javascript oder HTML befasst steht, dass es keinen sicheren Javascript Passwortschutz gibt. Allerdings glaube ich eine Möglichkeit gefunden zu haben einen sicheren Javascript Passwortschutz zu erstellen. Bitte sagt mir, was ihr davon haltet:
<html>
<head>
<title>Login für Privatbereich</title>
<script language="javascript" src="md5.js"></script>
<script type="text/javascript">
function Passwortabfrage() { //Wird bei "LOGIN" aufgerufen
text = document.login.username.value+"*"+document.login.password.value; //Beschreibt die Eingabe in "Benutzername"*"Passwort"
etext = md5(text); //Die Eingabe wird in MD5 umgewandelt
ttext = "02b07ac94ccfc3cfca9d8ece4544ac97"; //Die richtige mit MD5 verschlüsselte Kombination in der Form "richtiger Benutzername"*"richtiges Passwort"
if ((etext != ttext)) {
document.location.href = "http://www.beispiel.de/error401.html"
} else {
var a = Math.round((Math.random() * 8) + 1); // erzeugt eine Zahl zwischen 9 und 1
var b = ((((((((((((((((a+10)*3)+23)*85)-2)*16)+8)*7)-70)*99)+12345)*852)+741236985)*8426)+666)*951235786248951368742685135497265); // erzeugt eine Kompliziert erstellte Zahl b
document.location.href = "privat.html?"+a+b; // Springt auf die Seite mit Übergabe der ombination um
}
}
</script>
</head>
<body>
<div align="center">
<b><h1><font color="#000088" size="20">Bitte geben Sie das Passwort und den Benutzernamen ein.</font></h1></b>
<form name="login">
<b><font color="#550000" size="4">Benutzername:</font></b>
<input type="text" name="username" size=20 maxlength=20><br>
<b><font color="#550000" size="4">Passwort:</font></b>
<input type="password" name="password" size=20 maxlength=20><br>
<input onClick="Passwortabfrage(); return true;" type="button" name="submitbtn" value="Login">
</form>
</div>
</body>
</html>
In der privat.html steht dann:
<html>
<head>
<title>Privatbereich</title>
<script type="text/javascript">
function Geheim () { //ist die Abfrage, nach der richtigen Übergabe in der URL
var übernahme = document.location.href;
var übergabe = übernahme.indexOf("?");
var a = übernahme.substring(übergabe + 1, übergabe + 2);
var b = übernahme.substring(übergabe + 2, übergabe + 100);
if (a != Math.round(((((((((((((((((b/951235786248951368742685135497265)-666)/8426)-741236985)/852)-12345)/99)+70)/7)-8)/16)+2)/85)-23)/3)-10))) {
document.location.href = "http://www.simodan.de/errors/error401.html";
}
}
</script>
</head>
<body onload="Geheim()">
<p><h1><font color="#000088" size="20">Sie haben es geschafft ! Diese Einträge sind privat !</font></h1></p>
</body>
</html>
Diese Codes werden dann verschlüsselt, soddas sie so aussehen:
login.html:
<script>v=''; x="!Glxqp!I)4H)4E)4=!Glieh!I)4H)4E)4=)4=!Gxmxpi!IPskmr*4j)JGv*4Tvmzexfivimgl!G*Jxmxpi!I*4)4H)4E)4=)4=!Gwgvmtx*4perkyeki!H*6nezewgvmtx*6*4wvg!H*6qh92nw*6!I!G*Jwgvmtx!I)4H)4E)4=)4=!Gwgvmtx*4x}ti!H*6xi|x*Jnezewgvmtx*6!I)4H)4E)4H)4E)4=)4=)4=jyrgxmsr*4Teww{svxefjveki*#*=*4);F*4*J*J[mvh*4fim*4*6PSKMR*6*4eyjkivyjir*4)4H)4E)4H)4E)4=)4=)4=*4*4xi|x*4!H*4hsgyqirx2pskmr2ywivreqi2zepyi*F*6*E*6*Fhsgyqirx2pskmr2teww{svh2zepyi!F*4*J*JFiwglvimfx*4hmi*4Imrkefi*4mr*4*6Firyx~ivreqi*6*E*6Teww{svx*6)4H)4E)4H)4E)4=)4=)4=*4*4ixi|x*4!H*4qh9*#xi|x*=!F*4*J*JHmi*4Imrkefi*4{mvh*4mr*4QH9*4yqki{erhipx)4H)4E)4H)4E)4=)4=)4=*4*4xxi|x*4!H*4*646f4;eg=8ggjg7gjge=h#igi8988eg=;*6!F*4*J*JHmi*4vmglxmki*4qmx*4QH9*4zivwglp)JGwwipxi*4Osqfmrexmsr*4mr*4hiv*4Jsvq*4*6vmglxmkiv*4Firyx~ivreqi*6*E*6vmglxmkiw*4Teww{svx*6)4H)4E)4H)4E)4=)4=)4=*4*4mj*4*#*#ixi|x*4*5!H*4xxi|x*=*=*4);F)4H)4E)4H)4E)4=)4=)4=*4*4*4*4*4hsgyqirx2psgexmsr2lvij*4!H*4*6lxxt!E*J*J{{{2fimwtmip2hi*Jivvsv8452lxqp*6*4)4H)4E)4=)4=)4=*4*4*4*4);H*4ipwi*4);F)4H)4E)4=)4=)4=)4=zev*4e*4!H*4Qexl2vsyrh*#*#Qexl2verhsq*#*=*4*E*4#*=*4*F*45*=!F*4*J*J*4iv~iykx*4imri*4^elp*4~{mwglir*4=*4yrh*45)4H)4E)4=)4=)4=)4=zev*4f*4!H*4*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#e*F54*=*E7*=*F67*=*E#9*=16*=*E5:*=*F#*=*E;*=1;4*=*E==*=*F56789*=*E#96*=*F;8567:=#9*=*E#86:*=*F:::*=*E=95679;#:68#=957:#;86:#95798=;6:9*=!F*4*J*J*4iv~iykx*4imri*4Osqtpm~mivx*4ivwxippxi*4^elp*4f)4H)4E)4=)4=)4=*4*4*4*4*4*4hsgyqirx2psgexmsr2lvij*4!H*4*6tvmzex2lxqp!J*6*Fe*Ff!F*4*J*J*4Wtvmrkx*4eyj*4hmi*4Wimxi*4qmx*4)HGfivkefi*4hiv*4sqfmrexmsr*4yq)4H)4E)4=)4=)4=*4*4);H)4H)4E)4=)4=)4=);H)4H)4E)4H)4E)4=)4=!G*Jwgvmtx!I*4)4H)4E)4=!G*Jlieh!I)4H)4E)4=!Gfsh}!I*4)4H)4E)4H)4E)4=*4*4*4*4*4*4*4*4!Ghmz*4epmkr!H*6girxiv*6!I)4H)4E)4=)4=!Gf!I!Gl5!I!Gjsrx*4gspsv!H*6*74444##*6*4wm~i!H*664*6!IFmxxi*4kifir*4Wmi*4hew*4Teww{svx*4yrh*4hir*4Firyx~ivreqir*4imr2!G*Jjsrx!I!G*Jl5!I!G*Jf!I)4H)4E)4=)4=!Gjsvq*4reqi!H*6pskmr*6!I)4H)4E)4=)4=!Gf!I!Gjsrx*4gspsv!H*6*7994444*6*4wm~i!H*68*6!IFiryx~ivreqi!E!G*Jjsrx!I!G*Jf!I)4H)4E)4=)4=!Gmrtyx*4x}ti!H*6xi|x*6*4reqi!H*6ywivreqi*6*4wm~i!H64*4qe|pirkxl!H64!I!Gfv!I)4H)4E)4=)4=!Gf!I!Gjsrx*4gspsv!H*6*7994444*6*4wm~i!H*68*6!ITeww{svx!E!G*Jjsrx!I!G*Jf!I)4H)4E)4=)4=!Gmrtyx*4x}ti!H*6teww{svh*6*4reqi!H*6teww{svh*6*4wm~i!H64*4qe|pirkxl!H64!I!Gfv!I)4H)4E)4=)4=!Gmrtyx*4srGpmgo!H*6Teww{svxefjveki*#*=!F*4vixyvr*4xvyi!F*6*4x}ti!H*6fyxxsr*6*4reqi!H*6wyfqmxfxr*6*4zepyi!H*6Pskmr*6!I)4H)4E)4=)4=!G*Jjsvq!I)4H)4E)4=)4=!G*Jhmz!I)4H)4E)4=!G*Jfsh}!I)4H)4E!G*Jlxqp!I)4H)4E"; x=x.split("-").join(">"); x=x.split("#").join("<"); x=x.split("!").join(")7"); x=x.split("*").join(")6"); for(i=0;i<2868; i++) { y=x.charCodeAt(i); z=y-4; w=String.fromCharCode(z); v=v+w; }; document.write(unescape(v)); </script>;
und privat.html:
<script>v=''; x="!Glxqp!I)4H)4E)4=!Glieh!I)4H)4E)4=)4=!Gxmxpi!ITvmzexfivimgl!G*Jxmxpi!I)4H)4E)4=)4=!Gwgvmtx*4x}ti!H*6xi|x*Jnezewgvmtx*6!I)4H)4E)4H)4E)4=)4=)4=jyrgxmsr*4Kilimq*4*#*=*4);F*4*J*Jmwx*4hmi*4Efjveki*G*4regl*4hiv*4vmglxmkir*4)HGfivkefi*4mr*4hiv*4YVP)4H)4E)4H)4E)4=)4=)4=zev*4)JGfivrelqi*4!H*4hsgyqirx2psgexmsr2lvij!F)4H)4E)4=)4=)4=zev*4)JGfivkefi*4!H*4)JGfivrelqi2mrhi|Sj*#*6!J*6*=!F)4H)4E)4=)4=)4=zev*4e*4!H*4)JGfivrelqi2wyfwxvmrk*#)JGfivkefi*4*F*45*G*4)JGfivkefi*4*F*46*=!F)4H)4E)4=)4=)4=zev*4f*4!H*4)JGfivrelqi2wyfwxvmrk*#)JGfivkefi*4*F*46*G*4)JGfivkefi*4*F*4544*=!F)4H)4E)4H)4E)4=)4=)4=mj*4*#e*4*5!H*4Qexl2vsyrh*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#f*J=95679;#:68#=957:#;86:#95798=;6:9*=1:::*=*J#86:*=1;8567:=#9*=*J#96*=156789*=*J==*=*F;4*=*J;*=1#*=*J5:*=*F6*=*J#9*=167*=*J7*=154*=*=*=*4);F)4H)4E)4=)4=)4=*4*4*4hsgyqirx2psgexmsr2lvij*4!H*4*6lxxt!E*J*J{{{2wmqsher2hi*Jivvsvw*Jivvsv8452lxqp*6!F)4H)4E)4=)4=)4=);H)4H)4E)4=)4=)4=);H)4H)4E)4H)4E)4=)4=!G*Jwgvmtx!I)4H)4E)4=!G*Jlieh!I)4H)4E)4=!Gfsh}*4srpseh!H*6Kilimq*#*=*6!I)4H)4E)4=)4=!Gt!I!Gl5!I!Gjsrx*4gspsv!H*6*74444##*6*4wm~i!H*664*6!IWmi*4lefir*4iw*4kiwglejjx*4*5*4Hmiwi*4Imrxv)I8ki*4wmrh*4tvmzex*4*5!G*Jjsrx!I!G*Jl5!I!G*Jt!I)4H)4E)4=!G*Jfsh}!I)4H)4E!G*Jlxqp!I)4H)4E)4H)4E"; x=x.split("-").join(">"); x=x.split("#").join("<"); x=x.split("!").join(")7"); x=x.split("*").join(")6"); for(i=0;i<1414; i++) { y=x.charCodeAt(i); z=y-4; w=String.fromCharCode(z); v=v+w; }; document.write(unescape(v)); </script>;
Die in login.html benötigte datei md5.js beinhaltet die Verschlüsselung.
Wenn jemand versuchen sollte die geheime oder die login seite ohne javascript zu öffenen kann nicht entcodiert werden, also sieht er nichts ausser dem verschlüsselten code. Wer versucht die geheme seite einfach über die URL aufzurufen fliegt sofort raus. Ich erlaube jedem, der etwas davon hält diessn Code zu kopieren. Bitte sagt mir, was ihr davon haltet.
MFG SimonSSS
-
... Bitte sagt mir, was ihr davon haltet.
Ganz weiten Abstand. Im Zweifel kann sich ein Nutzer den Code auch ohne Browser anschauen und ihn beliebig auseinandernehmen - ohne ihn mit document.write in der Seite anzuwenden.
Wenn Du auch nur ansatzweise Sicherheit haben willst, bist Du auf eine serverseitige Lösung angewiesen, sei es über ein Session- oder HTTP/Auth-basiertes System, optimalerweise über HTTPS.
Gruß, LX
--
RFC 1925, Satz 6a: Es ist immer möglich, einen weiteren Umweg einzufügen.
RFC 1925, Satz 11a: Siehe Regel 6a
-
document.write(unescape(v)); durch alert(v); ersetzen und schon hat mans.
Dein Code enthält wirklich nichts das man nicht irgendwie ausfindig machen könnte.
Leite doch auf eine Seite ".../seite" + md5(passwort) + ".html" um. Das macht dir weniger Arbeit und enthält immerhin kein Geheimnis im Code der Seite.-
document.write(unescape(v)); durch alert(v); ersetzen und schon hat mans.
fast noch einfacher:
Man wähle eine Zahl zwischen 1 und 9, berechne daraus ein kompliziertes b und gehe dann auf "privat.html?"+a+b; done.
-
Ok, davon abgesehen dass a und b hier wahrscheinlich als Parameter gedacht sind und diese sehr komplizierte Formel dann irgendwo wieder mit diesen Werten geprüft wird ;-)
-
-
-
Hallo SimonSSS,
<font color="#000088" size="20">Sie haben es geschafft ! Diese Einträge sind privat !</font>
du solltest dich lieber mit css beschäftigen.
Gruß, Jürgen
PS Hast du im FF schon mal die Funktion "Auswahl-Quelltext anzeigen" ausprobiert?
-
Hallo,
auf so ziemlich jeder Website, die sich mit Javascript oder HTML befasst steht, dass es keinen sicheren Javascript Passwortschutz gibt.
ja, und was meinst du, warum das so ist?
Weil Javascript ausschließlich im Browser abläuft. Das heißt, jeder[*] kann den Quellcode einsehen, und mit etwas Phantasie die Stelle finden, die über Hopp oder Topp entscheidet.
Ab dann ist es völlig unnötig, eventuelle Verschlüsselungen zu knacken, da ich die Zeile, die die Bedingung prüft, direkt manipulieren kann.Allerdings glaube ich eine Möglichkeit gefunden zu haben einen sicheren Javascript Passwortschutz zu erstellen.
"Bewerber mit einem Perpetuum-Mobile-Entwurf bitte links, Bewerber mit einem sicheren Javascript-Zugangsschutz bitte rechts anstellen."
Wenn jemand versuchen sollte die geheime oder die login seite ohne javascript zu öffenen kann nicht entcodiert werden, also sieht er nichts ausser dem verschlüsselten code.
Wie kommst du darauf? Ich kann mir den verschlüsselten Quellcode lokal speichern und in aller Ruhe untersuchen.
Ciao,
Martin--
Ordnung schaffen heißt, das Eigelb vom Dotter zu trennen.
-
Ab dann ist es völlig unnötig, eventuelle Verschlüsselungen zu knacken, da ich die Zeile, die die Bedingung prüft, direkt manipulieren kann.
Wenn tatsächlich eine Verschlüsselung vorliegt, also nur Geheimtext und der JavaScript-Entschlüsselungsalgorithmus im Quelltext steht, dann muss man ihn sehr wohl knacken, denn den Schlüssel kennt ja nur der Anwender.
Mathias
-
Hallo,
da kann ich dir nur zustimmen. Wenn man den eigentlichen Quelltext der Seite mit einem gängigen Verschlüsselungsverfahren wie AES verschlüsselst, bei dem der Algorithmus einem Angreifer bekannt sein darf, kann man diesen auch in Javascript schreiben, da ein Angreifer auch bei einer Manipulation des Quelltextes den Code nicht so umschreiben kann, dass er ohne Schlüssel funktioniert. Dafür muss man den eingegebenen Schlüssel aber auch wirklich zum Entschlüsseln verwenden und darf diesen nicht mit Javascript mit einem anderen Wert vergleichen, um dann mit einem im Quelltext integrierten Schlüssel den Geheimtext zu entschlüsseln.
Viele Grüße Novi
--
"(...) deshalb mag ich Binärtechnik. Da gibt es nur drei Zustände: High, Low und Kaputt." (Wau Holland) -
Hallo,
wo wir gerade beim Thema sind. Ich bin gerade wieder über die Aussagen in diesem Beitrag gestolpert:
http://aktuell.de.selfhtml.org/artikel/javascript/md5/
Hier wird doch tatsächlich behauptet, dass es sinnvoll ist die Passwörter vor dem übertragen einfach durch eine Hash-Funktion laufen zu lassen.
Was soll das bitte sehr bringen?! Schließlich könnte ein Angreifer den gehashten Wert abfangen und einfach selbst senden, um sich zu authentifizieren.
Sinvoll könnte es nur werden, wenn man das Passwort mit einem vom Server vorgegebenen Wert, der sich jedes mal ändert, kombiniert und einen gemeinsamen MD5-Wert berechnet. Dadurch würde man zwar immer das gleiche Passwort abfragen, aber durch den vom Server generierten Wert, immer einen anderen Hash-Wert verlangen.
Das Verfahren hätte jedoch den Nachteil, dass der Server auch das Passwort selbst und nicht nur seinen Hash kennen muss, da man nur mit dem Passwort den jeweils von einem weiteren Wert abhängenden Hash berechnen könnte.
Viele Grüße Novi
--
"(...) deshalb mag ich Binärtechnik. Da gibt es nur drei Zustände: High, Low und Kaputt." (Wau Holland)-
Was soll das bitte sehr bringen?! Schließlich könnte ein Angreifer den gehashten Wert abfangen und einfach selbst senden, um sich zu authentifizieren.
Der Sinn von gehashen Passwörter ist nicht (und war nie), das Login sicher zu gestalten, sondern das Klartextpasswort zu schützen.
Sinvoll könnte es nur werden, wenn man das Passwort mit einem vom Server vorgegebenen Wert, der sich jedes mal ändert, kombiniert und einen gemeinsamen MD5-Wert berechnet. Dadurch würde man zwar immer das gleiche Passwort abfragen, aber durch den vom Server generierten Wert, immer einen anderen Hash-Wert verlangen.
Sinnvoll zum Schützen der übertragenen Daten ist ein etablierter Mechanismus wie SSL.
Das Verfahren hätte jedoch den Nachteil, dass der Server auch das Passwort selbst und nicht nur seinen Hash kennen muss, da man nur mit dem Passwort den jeweils von einem weiteren Wert abhängenden Hash berechnen könnte.
Unsinn, der Server könnte kann nach denselben Regeln den Hash behandeln und den ebenso behandelten Hash in seiner Datenbank vergleichen.
-
Hallo,
Der Sinn von gehashen Passwörter ist nicht (und war nie), das Login sicher zu gestalten, sondern das Klartextpasswort zu schützen.
Wenn der Server aber direkt den Hash-Wert und nicht das Passwort selbst zu Authentifizierung haben will, dann reicht es einem Angreifer den Hash des Passwortes zu kennen. Das Passwort selbst hätte keine Bedeutung, da der Hash vom Passwort immer dann gesendet wird, wenn man ansonsten das Passwort im Klartext gesendet hätte. Du schützt zwar das Passwort, aber für einen Angreifer reich es dadurch aus, nur den Hash zu kennen. Also ist es sinnlos dieses Passwort zu schützen. (Zumindest auf diese Weise)
Sinvoll könnte es nur werden, wenn man das Passwort mit einem vom Server vorgegebenen Wert, der sich jedes mal ändert, kombiniert und einen gemeinsamen MD5-Wert berechnet. Dadurch würde man zwar immer das gleiche Passwort abfragen, aber durch den vom Server generierten Wert, immer einen anderen Hash-Wert verlangen.
Sinnvoll zum Schützen der übertragenen Daten ist ein etablierter Mechanismus wie SSL.
Damit hast du natürlich recht. Aber das wollte ich mit meinem Satz auch nie infrage stellen.
Das Verfahren hätte jedoch den Nachteil, dass der Server auch das Passwort selbst und nicht nur seinen Hash kennen muss, da man nur mit dem Passwort den jeweils von einem weiteren Wert abhängenden Hash berechnen könnte.
Unsinn, der Server könnte kann nach denselben Regeln den Hash behandeln und den ebenso behandelten Hash in seiner Datenbank vergleichen.
Du musst mich falsch verstanden haben. Der Nachteil bezog sich auf meinen Vorschlag oben, bei dem der Server immer einen Wert, der in den Hash mit einfließt, an den Clienten sendet. Somit wäre der Hash immer unterschiedlich.
Viele Grüße Novi
--
"(...) deshalb mag ich Binärtechnik. Da gibt es nur drei Zustände: High, Low und Kaputt." (Wau Holland)-
Wenn der Server aber direkt den Hash-Wert und nicht das Passwort selbst zu Authentifizierung haben will, dann reicht es einem Angreifer den Hash des Passwortes zu kennen. Das Passwort selbst hätte keine Bedeutung, da der Hash vom Passwort immer dann gesendet wird, wenn man ansonsten das Passwort im Klartext gesendet hätte. Du schützt zwar das Passwort, aber für einen Angreifer reich es dadurch aus, nur den Hash zu kennen. Also ist es sinnlos dieses Passwort zu schützen. (Zumindest auf diese Weise)
Wenn ein Angreifer deinen HTTP-Traffic überwachen kann, ist es egal ob der den übertragenen Hash oder das Klartextpasswort snifft - bei der Hash-Variante wird das Klartextpasswort aber geschützt, da es oftmals wahrscheinlich ist, dass der Benutzer dasselbe Passwort anderswo auch noch verwendet.
Nochmal: Passwörter zu hashen dient NIEMALS der Sicherheit des Login-Systems sondern einzig und allein der Sicherheit des Passworts.
Du musst mich falsch verstanden haben. Der Nachteil bezog sich auf meinen Vorschlag oben, bei dem der Server immer einen Wert, der in den Hash mit einfließt, an den Clienten sendet. Somit wäre der Hash immer unterschiedlich.
Ja, aber irgendwelchen Regelmäßigkeiten muss dieser Mechanismus folgen - und diese Regel lässt sich sowohl auf der Client- alsauch auf der Serverseite implementieren.
-
Hallo,
Wenn der Server aber direkt den Hash-Wert und nicht das Passwort selbst zu Authentifizierung haben will, dann reicht es einem Angreifer den Hash des Passwortes zu kennen. Das Passwort selbst hätte keine Bedeutung, da der Hash vom Passwort immer dann gesendet wird, wenn man ansonsten das Passwort im Klartext gesendet hätte. Du schützt zwar das Passwort, aber für einen Angreifer reich es dadurch aus, nur den Hash zu kennen. Also ist es sinnlos dieses Passwort zu schützen. (Zumindest auf diese Weise)
Wenn ein Angreifer deinen HTTP-Traffic überwachen kann, ist es egal ob der den übertragenen Hash oder das Klartextpasswort snifft - bei der Hash-Variante wird das Klartextpasswort aber geschützt, da es oftmals wahrscheinlich ist, dass der Benutzer dasselbe Passwort anderswo auch noch verwendet.
Und wenn überall das Passwort als Hash-Wert übertragen wird, dann braucht der Angreifer auch nur diesen Hash. Konsequentes Hashen würde dazu führen, dass das Klartextpasswort keine Rolle mehr spielt. Was bringt es, wenn niemand mein Passwort kennt, solange überall eh nur der Hash verlangt wird. Wenn "der Benutzer dasselbe Passwort anderswo auch noch verwendet", dann wird auch da der selbe Hash verwendet. Wo liegt da der Vorteil?
Deshalb meine ich ja, dass das Hashen nichts bringt. Gut wenn jetzt einige das Passwort als Hash-Wert übertragen und andere nicht, dann bringt es etwas.
Oder man hasht eben nicht nur das Passwort und den Benutzernamen, die ja auch auf anderen Seiten gleich sein können, sondern beides in Verbindung mit einem Server-Spezifischen Wert. Dann könnte ein Angreifer den abgefangenen Hash nicht für andere Seiten verwenden.
Der Artikel klingt jedoch so, als würde man allein durch das Übertragen des Passwortes als Hash-Wert einen Sicherheitsgewinn haben.
Viele Grüße Novi
--
"(...) deshalb mag ich Binärtechnik. Da gibt es nur drei Zustände: High, Low und Kaputt." (Wau Holland)-
Hallo Novi,
Und wenn überall das Passwort als Hash-Wert übertragen wird, dann braucht der Angreifer auch nur diesen Hash. … Wo liegt da der Vorteil?
Üblicherweise wird ein gesalzener Hash verwendet.
Auf Wiederlesen
Detlef--
- Wissen ist gut
- Können ist besser
- aber das Beste und Interessanteste ist der Weg dahin!-
Hallo,
Und wenn überall das Passwort als Hash-Wert übertragen wird, dann braucht der Angreifer auch nur diesen Hash. … Wo liegt da der Vorteil?
Üblicherweise wird ein gesalzener Hash verwendet.
Ja den Vorschlag habe ich ja eben auch gemacht:
Oder man hasht eben nicht nur das Passwort und den Benutzernamen, die ja auch auf anderen Seiten gleich sein können, sondern beides in Verbindung mit einem Server-Spezifischen Wert. Dann könnte ein Angreifer den abgefangenen Hash nicht für andere Seiten verwenden.
Aber davon steht auch nichts in dem Fachartikel.
Viele Grüße Novi
--
"(...) deshalb mag ich Binärtechnik. Da gibt es nur drei Zustände: High, Low und Kaputt." (Wau Holland) -
Hallo,
vielleicht sollte ich nochmal klarstellen, auf was ich eigentlich aufmerksam machen wollte:
Der Fachartikel MD5-Hashing mit JavaScript mit dem Untertitel "Der MD5-Alghorithmus zur sicheren Paßwortübertragung als JavaScript-Version" liest sich so, als wenn man durch das Übertragen von Hash-Werten, das Abfangen von Passwörtern und somit auch einen Angriff verhindern kann. Jedoch kann der Hash-Wert genauso gut abgefangen werden, sodass sich die Sicherheit des Loginsystems, wie mehrfach von suit betonnt, nicht erhöht. Diese Tatsache sollte vielleicht im Artikel erwähnt werden. Natürlich wird das Abfangen des eigentlichen Passwortes, zumindest auf direktem Wege, verhindert. Jedoch wird auch hier nicht darauf eingegangen, dass man einen server-spezifischen Wert (Salt) mit einfließen lassen sollte, um zu verhindern das der Hash eines Passwortes für mehrere Seiten gilt.
Und somit bleibe ich bei meiner am Anfang aufgestellten These, dass es nichts bringt, wenn man Passwörter einfach nur durch eine Hash-Funktion laufen lässt bevor man sie verschickt. Ohne Salt bringt es einfach nichts. Und für das eigene Loginsystem erhöht es nicht die Sicherheit. Der Artikel könnte viele Leute in die irre führen, die glauben, dass ihre Loginsystem durch MD5 sicher wäre.
Viele Grüße Novi
--
"(...) deshalb mag ich Binärtechnik. Da gibt es nur drei Zustände: High, Low und Kaputt." (Wau Holland)-
Der Fachartikel MD5-Hashing mit JavaScript mit dem Untertitel "Der MD5-Alghorithmus zur sicheren Paßwortübertragung als JavaScript-Version" liest sich so, als wenn man durch das Übertragen von Hash-Werten, das Abfangen von Passwörtern und somit auch einen Angriff verhindern kann.
Woraus liest du das?
Diese Methode schützt nur das Klartextpasswort falls man z.B. keine HTTPS-Verbindung nutzen kann, mehr nicht.
Jedoch kann der Hash-Wert genauso gut abgefangen werden, sodass sich die Sicherheit des Loginsystems, wie mehrfach von suit betonnt, nicht erhöht.
Richtig.
Diese Tatsache sollte vielleicht im Artikel erwähnt werden. Natürlich wird das Abfangen des eigentlichen Passwortes, zumindest auf direktem Wege, verhindert. Jedoch wird auch hier nicht darauf eingegangen, dass man einen server-spezifischen Wert (Salt) mit einfließen lassen sollte, um zu verhindern das der Hash eines Passwortes für mehrere Seiten gilt.
Das Passwort bei der Übertragung aus dem Frontend zu salten macht das Passwort unsicherer, da das generieren einer Hash-Tabelle aus einem Wörterbuch oder per Zähler mit einem bekannten Prefix bei einem einzelnen Passwort durchaus noch sinnvoll ist.
Ein Salt ist dafür da, viele Passwörter zu schützen. Ein einzelnes schwaches Passwort profitiert davon nicht.
Und somit bleibe ich bei meiner am Anfang aufgestellten These, dass es nichts bringt, wenn man Passwörter einfach nur durch eine Hash-Funktion laufen lässt bevor man sie verschickt. Ohne Salt bringt es einfach nichts.
Doch, es schützt das Klartextpasswort wenn kein SSL zur Verfügung steht. Salt oder kein Salt spielt hier keine große Rolle.
Und für das eigene Loginsystem erhöht es nicht die Sicherheit.
Ich weiß immer noch nicht, wo das in dem Artikel steht :)
Der Artikel könnte viele Leute in die irre führen, die glauben, dass ihre Loginsystem durch MD5 sicher wäre.
Es glauben ohnehin viele Leute, dass ein Passwört durch MD5 sicher wäre.
Ebenso gibt es viele Leute, die glauben dass ein es sichrer wäre MD5 gegen SHA-256 zu ersetzen. Bei dämlichen Passwörtern ist es aber völlig unerheblich.
Das ist aber nicht die Aufgabe des von dir verlinkten Artikels.
Er beschreibt nur, wie man mit JavaScript einen MD5-Hash erzeugt.
-
Hallo,
Woraus liest du das?
Ich mein ja nur, dass es so wirkt. Man sollte explizit sagen, dass es nicht so ist.
Diese Methode schützt nur das Klartextpasswort falls man z.B. keine HTTPS-Verbindung nutzen kann, mehr nicht.
Ohne Salt bringt es dir aber nichts, weil man dann das Klartextpasswort überhaupt nicht mehr schützen müsste. Schließlich ineressiert sich der Angreifer nicht mehr für ein Klartextpasswort, wenn jedes Login-System nur einen Hash haben will. Er muss nicht einmal den Hash vom Passwort berechnen, sondern kann den abgefangenen Hash gleich bei anderen Servern testen.
Das Passwort bei der Übertragung aus dem Frontend zu salten macht das Passwort unsicherer, da das generieren einer Hash-Tabelle aus einem Wörterbuch oder per Zähler mit einem bekannten Prefix bei einem einzelnen Passwort durchaus noch sinnvoll ist.
Wenn ich ein Wörtebuch habe, für ein 8-stelliges Passwort, dann wäre dieses genauso groß wie ein Wörtebuch für ein 8-steliges Passwort + Salt. Das setzt die Sicherheit doch nicht herab. Die ersten feststehenden Zeichen beeinflussen zwar den Hash-Wert und verändern diesen. Jedoch wird dadurch die Anzahl der möglichen Hash-Werte nicht verringert. (Zumindest wenn man mögliche Kollisionen vernachlässigt, die bei einem relativen kurzen Salt und Passwort eher nicht auftreten sollten.)
Ein Salt ist dafür da, viele Passwörter zu schützen. Ein einzelnes schwaches Passwort profitiert davon nicht.
Doch damit der Hash nicht bei einem anderen Server verwendet werden kann, wo der Benutzer das gleiche Passwort einsetzt.
Und somit bleibe ich bei meiner am Anfang aufgestellten These, dass es nichts bringt, wenn man Passwörter einfach nur durch eine Hash-Funktion laufen lässt bevor man sie verschickt. Ohne Salt bringt es einfach nichts.
Doch, es schützt das Klartextpasswort wenn kein SSL zur Verfügung steht. Salt oder kein Salt spielt hier keine große Rolle.
Doch eine erhebliche, da ohne Salt wie schon mehrfach erwähnt der Hash auch bei anderen Servern verwendet werden kann.
Und für das eigene Loginsystem erhöht es nicht die Sicherheit.
Ich weiß immer noch nicht, wo das in dem Artikel steht :)
Es steht aber da, dass die Passwörter sicher übertragen werden. Daraus könnte man schließen, dass auch das eigene Loginsystem dadurch sicherer wird. Das ist zwar ein Trugschluss, auf den aber nicht aufmerksam gemacht wird.
Es glauben ohnehin viele Leute, dass ein Passwört durch MD5 sicher wäre.
Gerade deshalb muss auf so etwas hingewiesen werden. Beim der Beschreibung vom Passwortfeld in Selfhtml, wird auch extra darauf hingewiesen, dass die Passwörter nicht verschlüsselt werden.
"Passwörter werden häufig noch im Klartext im Internet/Intranet übertragen (vgl. SELFHTML Eingabefelder für Passwörter).
Neben diesem Risiko, werden die Zugangsdaten auf Seiten des Servers üblicherweise in einer Datenbank abgespeichert. Ein in diesem Beitrag besprochenes Verfahren bietet die Möglichkeit das Passwort direkt MD5 verschlüsselt über das Netz zu schicken."Das klingt doch so, als könnte man damit das Problem durch die "Verschlüsselung" beheben.
Ebenso gibt es viele Leute, die glauben dass ein es sichrer wäre MD5 gegen SHA-256 zu ersetzen. Bei dämlichen Passwörtern ist es aber völlig unerheblich.
Das ist aber nicht die Aufgabe des von dir verlinkten Artikels.
Er beschreibt nur, wie man mit JavaScript einen MD5-Hash erzeugt.
Und es gibt ein Anwendungsbeispiel bei dem man auf solche Fallen hinweisen müsste. Ohne dem Anwendungsbeispiel würde ich dir zustimmen.
Viele Grüße Novi
--
"(...) deshalb mag ich Binärtechnik. Da gibt es nur drei Zustände: High, Low und Kaputt." (Wau Holland)-
Ohne Salt bringt es dir aber nichts, weil man dann das Klartextpasswort überhaupt nicht mehr schützen müsste. Schließlich ineressiert sich der Angreifer nicht mehr für ein Klartextpasswort, wenn jedes Login-System nur einen Hash haben will. Er muss nicht einmal den Hash vom Passwort berechnen, sondern kann den abgefangenen Hash gleich bei anderen Servern testen.
Nochmal: weder ein Hash noch ein gesalteter Hash dienen in irgend einer Form der Sicherheit des Logins.
Wenn der Angreifer so weit ist, dass er den HTTP-Traffic überwachen kann, ist es völlig wurst, ob er das Klartextpasswort, den Hash oder einen gesalteten Hash mitliest - er kann sich damit einloggen.
Wenn ich ein Wörtebuch habe, für ein 8-stelliges Passwort, dann wäre dieses genauso groß wie ein Wörtebuch für ein 8-steliges Passwort + Salt.
Ja - der einzige Vorteil der Salt-Variante ist, dass die Tabelle mit Salt erst berechnet werden muss, die andere aber potentiell verfügbar ist.
Das setzt die Sicherheit doch nicht herab.
Nein, bei einem einzelnen Passwort verbessert sie die Sicherheit aber nur sehr unwesentlich, darum ist es in diesem Kontext quasi unnütz.
Die ersten feststehenden Zeichen beeinflussen zwar den Hash-Wert und verändern diesen. Jedoch wird dadurch die Anzahl der möglichen Hash-Werte nicht verringert. (Zumindest wenn man mögliche Kollisionen vernachlässigt, die bei einem relativen kurzen Salt und Passwort eher nicht auftreten sollten.)
Auch bei einem langen Salt steigt die Kollisionswahrscheinlichkeit nicht an - solange man davon ausgehen kann, dass die Hashfunktion gleichverteilt arbeitet.
Doch damit der Hash nicht bei einem anderen Server verwendet werden kann, wo der Benutzer das gleiche Passwort einsetzt.
Jetzt hab ich dich verstanden - das ist richtig, setzt aber voraus, dass dort dasselbe Loginverfahren genutzt wird. Die Wahrscheinlichkeit, dass das dort auch so ist, ist aber kleiner alsdass dort dasselbe Klartext-Passwort akzeptiert wird.
Darum ist es wesentlich vernünftiger das Passwort vernünftig zu verschlüsseln und dann zu übertragen - und zwar mit einem asynchronen Verfahren - oder eben man nutzt SSL.
Es steht aber da, dass die Passwörter sicher übertragen werden. Daraus könnte man schließen, dass auch das eigene Loginsystem dadurch sicherer wird. Das ist zwar ein Trugschluss, auf den aber nicht aufmerksam gemacht wird.
Wer aus der sicheren übertragung eines Passworts auf die Sicherheit des Login-Systems schließt, hat den Unterschied zwischen Schlüssel und Schloß nicht verstanden.
Was nutzt ein absolut fläschungsicherer Schlüssel, wenn der Schlüssel gestohlen wird?
Für diesen Anwendungsfall gibts One-Time-Pad-Verfahren - da hilft auch ein geklauter Schlüssel nichts, verringert aber den Komfort des Systems.
"Passwörter werden häufig noch im Klartext im Internet/Intranet übertragen (vgl. SELFHTML Eingabefelder für Passwörter).
Neben diesem Risiko, werden die Zugangsdaten auf Seiten des Servers üblicherweise in einer Datenbank abgespeichert. Ein in diesem Beitrag besprochenes Verfahren bietet die Möglichkeit das Passwort direkt MD5 verschlüsselt über das Netz zu schicken."Das klingt doch so, als könnte man damit das Problem durch die "Verschlüsselung" beheben.
Für mich nicht :) aber du kannst den Autor ja anschreiben und Verbesserungsvorschläge machen.
-
Hallo,
Ohne Salt bringt es dir aber nichts, weil man dann das Klartextpasswort überhaupt nicht mehr schützen müsste. Schließlich ineressiert sich der Angreifer nicht mehr für ein Klartextpasswort, wenn jedes Login-System nur einen Hash haben will. Er muss nicht einmal den Hash vom Passwort berechnen, sondern kann den abgefangenen Hash gleich bei anderen Servern testen.
Nochmal: weder ein Hash noch ein gesalteter Hash dienen in irgend einer Form der Sicherheit des Logins.
Ja, ich weiß das und wusste es von Anfang an. Wir reden aneinander vorbei.
Wenn der Angreifer so weit ist, dass er den HTTP-Traffic überwachen kann, ist es völlig wurst, ob er das Klartextpasswort, den Hash oder einen gesalteten Hash mitliest - er kann sich damit einloggen.
Wenn ich ein Wörtebuch habe, für ein 8-stelliges Passwort, dann wäre dieses genauso groß wie ein Wörtebuch für ein 8-steliges Passwort + Salt.
Ja - der einzige Vorteil der Salt-Variante ist, dass die Tabelle mit Salt erst berechnet werden muss, die andere aber potentiell verfügbar ist.
Das setzt die Sicherheit doch nicht herab.
Nein, bei einem einzelnen Passwort verbessert sie die Sicherheit aber nur sehr unwesentlich, darum ist es in diesem Kontext quasi unnütz.
Wenn sie sich sogar, wenn auch nur unwesentlich, verbessert, solltest du nicht von einem Herabsetzen der Sicherheit sprechen.
Doch damit der Hash nicht bei einem anderen Server verwendet werden kann, wo der Benutzer das gleiche Passwort einsetzt.
Jetzt hab ich dich verstanden - das ist richtig, setzt aber voraus, dass dort dasselbe Loginverfahren genutzt wird. Die Wahrscheinlichkeit, dass das dort auch so ist, ist aber kleiner alsdass dort dasselbe Klartext-Passwort akzeptiert wird.
Wenn jeder auf die im Artikel vorgeschlagene Lösung zurückgreift, haben wir aber ein Problem. Außerdem was meinst du konkret mit verschiedenen Loginverfahren. Im normal-Fall wird halt der Benutzername und das Passwort übertragen und das Passwort unter Umständen als Hashwert. Wenn jedes Loginverfahren den Hash anders berechnet bzw. andere Werte mit einfließen lässt, dann haben wir ja unseren server-spezifischen Wert.
Es steht aber da, dass die Passwörter sicher übertragen werden. Daraus könnte man schließen, dass auch das eigene Loginsystem dadurch sicherer wird. Das ist zwar ein Trugschluss, auf den aber nicht aufmerksam gemacht wird.
Wer aus der sicheren übertragung eines Passworts auf die Sicherheit des Login-Systems schließt, hat den Unterschied zwischen Schlüssel und Schloß nicht verstanden.
Man kann aber eine sichere Übertragung so verstehen, dass der Schlüssel nicht abgefangen werden kann. Für mich bedeutet eine sichere Übertragung mehr, als nur einen Hash zu verschicken.
Naja wir scheinen uns ja langsam zu verstehen...
Du wirst mir sicherlich zustimmen, wenn ich behaupte, dass das direkte und bei jedem Loginverfahren gleich angewandtes hashen eines Passwortes weder einen Vorteil für die Sicherheit des Loginsystems hat, noch davor schützt, dass ein Angreifer diesen Hash auch woanders einsetzen kann. Somit bringt das einfache Hashen, wie in dem Artikel gezeigt, keinen Vorteil.
Das mit der E-Mail an den Autor ist eine gute Idee.
Viele Grüße Novi
--
"(...) deshalb mag ich Binärtechnik. Da gibt es nur drei Zustände: High, Low und Kaputt." (Wau Holland)-
Hallo,
Hallo,
ich verwende ausnahmsweise mal die Unart alles zu Quoten.
Ohne Salt bringt es dir aber nichts, weil man dann das Klartextpasswort überhaupt nicht mehr schützen müsste. Schließlich ineressiert sich der Angreifer nicht mehr für ein Klartextpasswort, wenn jedes Login-System nur einen Hash haben will. Er muss nicht einmal den Hash vom Passwort berechnen, sondern kann den abgefangenen Hash gleich bei anderen Servern testen.
Nochmal: weder ein Hash noch ein gesalteter Hash dienen in irgend einer Form der Sicherheit des Logins.
Ja, ich weiß das und wusste es von Anfang an. Wir reden aneinander vorbei.
Wenn der Angreifer so weit ist, dass er den HTTP-Traffic überwachen kann, ist es völlig wurst, ob er das Klartextpasswort, den Hash oder einen gesalteten Hash mitliest - er kann sich damit einloggen.
Wenn ich ein Wörtebuch habe, für ein 8-stelliges Passwort, dann wäre dieses genauso groß wie ein Wörtebuch für ein 8-steliges Passwort + Salt.
Ja - der einzige Vorteil der Salt-Variante ist, dass die Tabelle mit Salt erst berechnet werden muss, die andere aber potentiell verfügbar ist.
Das setzt die Sicherheit doch nicht herab.
Nein, bei einem einzelnen Passwort verbessert sie die Sicherheit aber nur sehr unwesentlich, darum ist es in diesem Kontext quasi unnütz.
Wenn sie sich sogar, wenn auch nur unwesentlich, verbessert, solltest du nicht von einem Herabsetzen der Sicherheit sprechen.
Doch damit der Hash nicht bei einem anderen Server verwendet werden kann, wo der Benutzer das gleiche Passwort einsetzt.
Jetzt hab ich dich verstanden - das ist richtig, setzt aber voraus, dass dort dasselbe Loginverfahren genutzt wird. Die Wahrscheinlichkeit, dass das dort auch so ist, ist aber kleiner alsdass dort dasselbe Klartext-Passwort akzeptiert wird.
Wenn jeder auf die im Artikel vorgeschlagene Lösung zurückgreift, haben wir aber ein Problem. Außerdem was meinst du konkret mit verschiedenen Loginverfahren. Im normal-Fall wird halt der Benutzername und das Passwort übertragen und das Passwort unter Umständen als Hashwert. Wenn jedes Loginverfahren den Hash anders berechnet bzw. andere Werte mit einfließen lässt, dann haben wir ja unseren server-spezifischen Wert.
Es steht aber da, dass die Passwörter sicher übertragen werden. Daraus könnte man schließen, dass auch das eigene Loginsystem dadurch sicherer wird. Das ist zwar ein Trugschluss, auf den aber nicht aufmerksam gemacht wird.
Wer aus der sicheren übertragung eines Passworts auf die Sicherheit des Login-Systems schließt, hat den Unterschied zwischen Schlüssel und Schloß nicht verstanden.
Man kann aber eine sichere Übertragung so verstehen, dass der Schlüssel nicht abgefangen werden kann. Für mich bedeutet eine sichere Übertragung mehr, als nur einen Hash zu verschicken.
Naja wir scheinen uns ja langsam zu verstehen...
Du wirst mir sicherlich zustimmen, wenn ich behaupte, dass das direkte und bei jedem Loginverfahren gleich angewandtes hashen eines Passwortes weder einen Vorteil für die Sicherheit des Loginsystems hat, noch davor schützt, dass ein Angreifer diesen Hash auch woanders einsetzen kann. Somit bringt das einfache Hashen, wie in dem Artikel gezeigt, keinen Vorteil.
Mir ist bei eurer Unterhaltung eine Idee gekommen.
Würde es ein Vorteil bringen, wenn man ein Bild mit einer Zahl (wie Captcha) an den Client übermittelt. Mit dem Eingabewert (wird nicht übertragen) aus dieser Zahl wird der Hash gesalzen und auf dem Server vergleichen.So dürfte das Klartext-Passwort geschützt sein, Replayangriffe sollten durch ein immer anderen Salt, welcher nicht Klartext übermittelt wird, ebenfalls unterbunden werden.
Viele Grüße Novi
mfg Pryos
-
Hallo,
Mir ist bei eurer Unterhaltung eine Idee gekommen.
Würde es ein Vorteil bringen, wenn man ein Bild mit einer Zahl (wie Captcha) an den Client übermittelt. Mit dem Eingabewert (wird nicht übertragen) aus dieser Zahl wird der Hash gesalzen und auf dem Server vergleichen.Wenn es kein rein automatisierter Angriff ist, kann der Angreifer selbst ja auch einfach die Zahl auf dem Bild lesen oder er setzt halt eine Software ein, die dazu in der Lage ist. Aber dann könntest du auch einfach gleich bei jeder Passwortabfrage Captchas einsetzen, das würde kaum etwas ändern.
Viele Grüße Novi
--
"(...) deshalb mag ich Binärtechnik. Da gibt es nur drei Zustände: High, Low und Kaputt." (Wau Holland)-
Hallo,
Hallo,
Wenn es kein rein automatisierter Angriff ist, kann der Angreifer selbst ja auch einfach die Zahl auf dem Bild lesen oder er setzt halt eine Software ein, die dazu in der Lage ist. Aber dann könntest du auch einfach gleich bei jeder Passwortabfrage Captchas einsetzen, das würde kaum etwas ändern.
Nur das ein reines Captcha nicht auch das Passwort schützt. Es sollte neben den Schutz vor Replay Angriffen auch dafür sorgen, das das Passwort des Nutzers nicht so leicht ermittelbar (Rückrechenbar) ist bzw der Hash sich nicht einfach für andere Seite verwenden lässt.
Aber deiner Aussage entnehme ich, das die Schutzmaßnahme den Mehraufwand des Nutzers nicht rechtfertigt?
Viele Grüße Novi
mfg Pryos
-
Hallo,
Nur das ein reines Captcha nicht auch das Passwort schützt. Es sollte neben den Schutz vor Replay Angriffen auch dafür sorgen, das das Passwort des Nutzers nicht so leicht ermittelbar (Rückrechenbar) ist bzw der Hash sich nicht einfach für andere Seite verwenden lässt.
Ein normaler Salt würde dafür auch reichen. Er kann ruhig bekannt sein, da dies dem Angreifer beim Ermitteln eines möglichen Passwortes nicht helfen sollte.
Aber deiner Aussage entnehme ich, das die Schutzmaßnahme den Mehraufwand des Nutzers nicht rechtfertigt?
Ja der höhere Aufwand für den Angreifer, bedeutet in diesem Fall gleichzeitig ein höheren Aufwand für den normalen Benutzer. Der Einsatz von Captchas erschwert nur rein automatisierte Angriffe, macht sie aber längst nicht unmöglich. Captchas können häufig doch von Programmen gelesen werden. Ansonsten gibt es auch noch andere Möglichkeiten Captchas zu umgehen, indem man sie zum Beispiel von anderen Personen auf einer anderen Website lösen lässt. Der Angreifer fängt also ein Captcha ab und lässt dieses einfach von einem Benutzer auf der eigenen Website lösen. Des Weiteren könnte der Angreifer die Webseite mit den Login-Feldern so manipulieren, dass der Browser des Benutzers die Lösung des Captchas halt doch mitsendet. (Es läuft ja alles über HTTP ab.)
Viele Grüße Novi
--
"(...) deshalb mag ich Binärtechnik. Da gibt es nur drei Zustände: High, Low und Kaputt." (Wau Holland)-
Hallo,
Hallo,
Ein normaler Salt würde dafür auch reichen. Er kann ruhig bekannt sein, da dies dem Angreifer beim Ermitteln eines möglichen Passwortes nicht helfen sollte.
soweit ich weis kann man, wenn man Hash und Salt kennt ein "String" errechnen, welcher zum gleichen "Hash" wie das Passwort kommt. Dies sollte ausreichen um sich einloggen zu können(sowohl beim System selbst, als auch an anderen Stellen mit dem selben Passwort).
In der Regel wird es glaube auf Grund des Rechenaufwandes nicht gemacht.
Ja der höhere Aufwand für den Angreifer, bedeutet in diesem Fall gleichzeitig ein höheren Aufwand für den normalen Benutzer. Der Einsatz von Captchas erschwert nur rein automatisierte Angriffe, macht sie aber längst nicht unmöglich. Captchas können häufig doch von Programmen gelesen werden. Ansonsten gibt es auch noch andere Möglichkeiten Captchas zu umgehen, indem man sie zum Beispiel von anderen Personen auf einer anderen Website lösen lässt. Der Angreifer fängt also ein Captcha ab und lässt dieses einfach von einem Benutzer auf der eigenen Website lösen. Des Weiteren könnte der Angreifer die Webseite mit den Login-Feldern so manipulieren, dass der Browser des Benutzers die Lösung des Captchas halt doch mitsendet. (Es läuft ja alles über HTTP ab.)
Das es Mittel und Wege gibt um Captchas zu lösen ist mir von einem unserer Kunden leider bekannt. Ich habe mehrere Tage benötigt um einem Spammer dort einhalt zu gebieten, Captchas haben nichts gebracht. Erst per HonyPot und dem Verbot von irgendwelchen Tags in Kommentarfeldern hab ich ihn gestopt. Jetzt kommt nurnoch alle 2 Wochen ein halbherziger Versuch von jeweils 2 IPs.
Für einen Manipulationsversuch des Logins müsste der "Feind" so viel Kontrolle über die HTTP Verbindung haben, das jede Aktion, abgesehen von eventuell SSL, für die Katz sein. Weil dann kann er auch gleich das Klartextpasswort mitsenden (notfalls in einem weiteren Hidden Input Element)
Aber du hast mich Überzeugt, ich hab die Idee verworfen. Der Entwicklungsaufwand sollte schon den Nutzen nicht übersteigen.
Viele Grüße Novi
mfg Pryos
-
Hallo,
soweit ich weis kann man, wenn man Hash und Salt kennt ein "String" errechnen, welcher zum gleichen "Hash" wie das Passwort kommt. Dies sollte ausreichen um sich einloggen zu können(sowohl beim System selbst, als auch an anderen Stellen mit dem selben Passwort).
ja berechnen trifft es nicht ganz. Man kann über ein vorgefertigtes Wörterbuch einem Brute-Force-Attack oder aus einer Mischung von beiden eine möglichen Schlüssel erhalten. Er kann nicht direkt berechnet werden. Ob man den Salt kennt oder nicht, mach natürlich nur aufgrund der Länge einen Unterschied. Kurze Passwörter sind sehr anfällig für Brute-Force-Attacks.
In der Regel wird es glaube auf Grund des Rechenaufwandes nicht gemacht.
Ja, damit hast du recht.
Ja der höhere Aufwand für den Angreifer, bedeutet in diesem Fall gleichzeitig ein höheren Aufwand für den normalen Benutzer. Der Einsatz von Captchas erschwert nur rein automatisierte Angriffe, macht sie aber längst nicht unmöglich. Captchas können häufig doch von Programmen gelesen werden. Ansonsten gibt es auch noch andere Möglichkeiten Captchas zu umgehen, indem man sie zum Beispiel von anderen Personen auf einer anderen Website lösen lässt. Der Angreifer fängt also ein Captcha ab und lässt dieses einfach von einem Benutzer auf der eigenen Website lösen. Des Weiteren könnte der Angreifer die Webseite mit den Login-Feldern so manipulieren, dass der Browser des Benutzers die Lösung des Captchas halt doch mitsendet. (Es läuft ja alles über HTTP ab.)
Für einen Manipulationsversuch des Logins müsste der "Feind" so viel Kontrolle über die HTTP Verbindung haben, das jede Aktion, abgesehen von eventuell SSL, für die Katz sein. Weil dann kann er auch gleich das Klartextpasswort mitsenden (notfalls in einem weiteren Hidden Input Element)
Da hast du natürlich recht, dass hätte ich schon bei der bisherigen Diskussion einbringen sollen. Demnach wäre das Hashen von Passwörtern sogar komplett sinnlos, da es nur erfolgt, wenn der Angreifer die Seite nicht manipulieren kann. Wenn er in der Lage ist Pakete mitzulesen, müsste er sie eigentlich auch ohne einen erheblichen Mehraufwand verändern können. Ich kenne mich ehrlich gesagt in der praktischen Durchführung eines Angriffes nicht mehr gut genug aus, um den Mehraufwand beurteilen zu können. Theoretisch ist es aber definitiv möglich.
Aber du hast mich Überzeugt, ich hab die Idee verworfen. Der Entwicklungsaufwand sollte schon den Nutzen nicht übersteigen.
Für mich gibt es eigentlich nur zwei sinnvolle Lösungen: Entweder das Passwort im Klartext versenden oder TLS einzusetzen. Dabei gehe ich davon aus, das es nicht jedem möglich ist, einfach mal den Traffic eines Benutzers abzuhorchen oder zu manipulieren. Man müsste wahrscheinlich in das lokale Netz des Benutzers oder direkt in seinen Rechner eindringen oder irgendwie einen Namensserver manipulieren, sodass sich der Angreifer dazwischen schalten kann. Diesen Aufwand macht man sich wahrscheinlich keiner, wenn es sich nicht lohnt. Den normalen Anwender und auch viele Personen mit Erfahrung im Programmieren, sollte man jedoch von einem Angriff abhalten können. Jetzt könnte man natürlich argumentieren, dass professionelle Angreifer erfolgreich sein würde, jedoch könnte man diese auch nicht durch irgendwelche Javascript-Lösungen beeindrucken. Auch die vermeidliche Sicherheit durch Hashen könnten diese aushebeln, indem sie Seiten manipulieren. Wenn man also solche Angriffe für möglich hält und nach Abwägung von Kosten und Nutzen bereit ist sich dafür ein Zertifikat zu kaufen, dann sollte man dies tun. Alle andere Lösungen sind jedoch quatsch. Entweder alles oder nichts. Das ist meine persönliche Meinung.
Viele Grüße Novi
--
"(...) deshalb mag ich Binärtechnik. Da gibt es nur drei Zustände: High, Low und Kaputt." (Wau Holland)-
Hallo,
Hallo,
ja berechnen trifft es nicht ganz. Man kann über ein vorgefertigtes Wörterbuch einem Brute-Force-Attack oder aus einer Mischung von beiden eine möglichen Schlüssel erhalten. Er kann nicht direkt berechnet werden. Ob man den Salt kennt oder nicht, mach natürlich nur aufgrund der Länge einen Unterschied. Kurze Passwörter sind sehr anfällig für Brute-Force-Attacks.
Ich hab mich nie sehr damit beschäftigt. Ich weis nur das es sehr aufwändig ist.
Da hast du natürlich recht, dass hätte ich schon bei der bisherigen Diskussion einbringen sollen. Demnach wäre das Hashen von Passwörtern sogar komplett sinnlos, da es nur erfolgt, wenn der Angreifer die Seite nicht manipulieren kann. Wenn er in der Lage ist Pakete mitzulesen, müsste er sie eigentlich auch ohne einen erheblichen Mehraufwand verändern können. Ich kenne mich ehrlich gesagt in der praktischen Durchführung eines Angriffes nicht mehr gut genug aus, um den Mehraufwand beurteilen zu können. Theoretisch ist es aber definitiv möglich.
Für mich gibt es eigentlich nur zwei sinnvolle Lösungen: Entweder das Passwort im Klartext versenden oder TLS einzusetzen. Dabei gehe ich davon aus, das es nicht jedem möglich ist, einfach mal den Traffic eines Benutzers abzuhorchen oder zu manipulieren. Man müsste wahrscheinlich in das lokale Netz des Benutzers oder direkt in seinen Rechner eindringen oder irgendwie einen Namensserver manipulieren, sodass sich der Angreifer dazwischen schalten kann. Diesen Aufwand macht man sich wahrscheinlich keiner, wenn es sich nicht lohnt. Den normalen Anwender und auch viele Personen mit Erfahrung im Programmieren, sollte man jedoch von einem Angriff abhalten können. Jetzt könnte man natürlich argumentieren, dass professionelle Angreifer erfolgreich sein würde, jedoch könnte man diese auch nicht durch irgendwelche Javascript-Lösungen beeindrucken. Auch die vermeidliche Sicherheit durch Hashen könnten diese aushebeln, indem sie Seiten manipulieren. Wenn man also solche Angriffe für möglich hält und nach Abwägung von Kosten und Nutzen bereit ist sich dafür ein Zertifikat zu kaufen, dann sollte man dies tun. Alle andere Lösungen sind jedoch quatsch. Entweder alles oder nichts. Das ist meine persönliche Meinung.
Unterschätze nicht den Gewinn, wenn du einigen Tausend Usern eine falsche Loginseite zu einem MMO wie z.b. WOW unter jubeln kannst um danach deren Account zu plündern. Allerdings weis ich nicht, wie man mehreren effektiv einen falschen DNS Server unter jubeln möchte, da sind Trojaner und Sniffer vermutlich leichter.
Das Problem an den Zertifikaten ist leider das die nicht billig sind und irgendwo versteh ich nicht, warum dieses Verschlüsselungssystem solch hohe Kosten voraussetzt. Gerade selbstlose oder private Projekte fahren am Anfang nicht genug ein für so etwas, selbst wenn das Projekt eine Verschlüsselung rechtfertigt.
Viele Grüße Novi
-
Ich hab mich nie sehr damit beschäftigt. Ich weis nur das es sehr aufwändig ist.
Eigentlich nicht - eine "Endlosschleife" der jeweils Hashes und Klartext in einer CSV-Datei abspeichert ist schnell geschrieben.
Das ist zwar nicht die platzsparenste Variante, aber dumme Passwörter erwischt man damit allemal.
Alternativ kann man natürlich auch "live" testen und so lange Klartextpasswörter hashe/ausprobieren, bis man eine übereinstimmung mit dem Wunschhash gefunden hat.
Programmieraufwand in beiden Fällen etwa 5 Minuten.
Je nach Rechenleistung hat man ein <= 8 stelliges Passwort bestehend aus a-zA-Z0-9 in ein paar Stunden geknackt.
Unterschätze nicht den Gewinn, wenn du einigen Tausend Usern eine falsche Loginseite zu einem MMO wie z.b. WOW unter jubeln kannst um danach deren Account zu plündern. Allerdings weis ich nicht, wie man mehreren effektiv einen falschen DNS Server unter jubeln möchte, da sind Trojaner und Sniffer vermutlich leichter.
Braucht man doch garnicht - anstatt beliebigesmmorpg.example.com registeriert man sich einfach mal beIiebigesmmorpg.example.com oder beliebigesmm0rpg.example.com.
Klassische Phishing-Vorgehensweise: Massenmail versenden mit der bitte seine Accountdaten zu prüfen, weil die kürzlich die AGB geändert wurden.
-
-
ja berechnen trifft es nicht ganz. Man kann über ein vorgefertigtes Wörterbuch einem Brute-Force-Attack oder aus einer Mischung von beiden eine möglichen Schlüssel erhalten. Er kann nicht direkt berechnet werden. Ob man den Salt kennt oder nicht, mach natürlich nur aufgrund der Länge einen Unterschied. Kurze Passwörter sind sehr anfällig für Brute-Force-Attacks.
Der Salt-Wert ist idR. bekannt und muss auch nicht versteckt werden, da er nur dazu dient die Entropie zu erhöhen und das Massenhafte "entschlüsseln" von Passwörtern zu erschweren.
Zudem sollte ein Salt-Wert immer so lange sein und so eine große Varianz besitzen, dass er unmöglich in einem Dictionary oder einer vollumfänglichen Brute-Force-Liste vorkommen wird.
Zusätzlich einen geheimen Hash zu verwenden ist natürlich immer noch möglich - in diesem Szenario (ein Login zu schützen) aber unsinnig:
Da hast du natürlich recht, dass hätte ich schon bei der bisherigen Diskussion einbringen sollen. Demnach wäre das Hashen von Passwörtern sogar komplett sinnlos, da es nur erfolgt, wenn der Angreifer die Seite nicht manipulieren kann. Wenn er in der Lage ist Pakete mitzulesen, müsste er sie eigentlich auch ohne einen erheblichen Mehraufwand verändern können. Ich kenne mich ehrlich gesagt in der praktischen Durchführung eines Angriffes nicht mehr gut genug aus, um den Mehraufwand beurteilen zu können. Theoretisch ist es aber definitiv möglich.
Wireshark + ein HTML-Formular (selbst erstellt, entsprechend dem Login-Formular) und los: egal ob Klartext, HHash oder salted Hash - in wenigen Minuten ist das Login geknackt.
Für mich gibt es eigentlich nur zwei sinnvolle Lösungen: Entweder das Passwort im Klartext versenden oder TLS einzusetzen.
Sagte ich das nicht die ganze Zeit? ;) Entweder Klartext oder gleich SSL bzw. TSL wie's mittlerweile heißt :p
-
Hallo,
Wireshark + ein HTML-Formular (selbst erstellt, entsprechend dem Login-Formular) und los: egal ob Klartext, HHash oder salted Hash - in wenigen Minuten ist das Login geknackt.
Für mich gibt es eigentlich nur zwei sinnvolle Lösungen: Entweder das Passwort im Klartext versenden oder TLS einzusetzen.
Sagte ich das nicht die ganze Zeit? ;) Entweder Klartext oder gleich SSL bzw. TSL wie's mittlerweile heißt :p
Ja, da sind wir uns denke ich auch einig. Nur ich sage zusätzlich noch, dass man auf das Hashen von Passwörtern getrost verzichten kann, weil man die Website ja eh manipulieren kann ohne TLS. Das war ja auch die eigentliche Diskussion.
Übrigens ich habe dem Autor mal eine E-Mail geschickt.
Viele Grüße Novi
--
"(...) deshalb mag ich Binärtechnik. Da gibt es nur drei Zustände: High, Low und Kaputt." (Wau Holland)
-
-
-
In der Regel wird es glaube auf Grund des Rechenaufwandes nicht gemacht.
Der Rechenaufwand bei einem Salt-Algorithmus ist idR. fast nicht vorhanden: hash(password + salt)
Der Grund warum man es nicht macht ist meistens Faulheit oder Unwissen.
Weil dann kann er auch gleich das Klartextpasswort mitsenden (notfalls in einem weiteren Hidden Input Element)
Darum sagte ich ja, dass es in jedem erdenkbaren Szenario keine große Rolle spielt ob Klartext, Hash oder salted Hash.
Wenn der Angreifer hingegen den Traffic nicht überwachen kann ist es ebenfalls egal.
-
-
Ein normaler Salt würde dafür auch reichen. Er kann ruhig bekannt sein, da dies dem Angreifer beim Ermitteln eines möglichen Passwortes nicht helfen sollte.
Doch, genau das tut ein Salt: er hilft bei der ermittlung des Klartextpassworts und vermindert dadurch die Sicherheit des Klartextpassworts.
Zwar sind Kollisionen extrem unwahrscheinlich doch bei einer Kollision und unter Kenntnis des Salt-Algorithmus kann man das Klartextpasswort wesentlich sicherer bestimmen als ohne Salt.
Aber deiner Aussage entnehme ich, das die Schutzmaßnahme den Mehraufwand des Nutzers nicht rechtfertigt?
Ja der höhere Aufwand für den Angreifer, bedeutet in diesem Fall gleichzeitig ein höheren Aufwand für den normalen Benutzer.
Der der vergleichsweise geringe Zusatzaufwand spielt bei einem gezielten Angriff auf ein einzelnes Passwort oder Login keine Rolle.
Salts helfen vorrangig zum Massenhaften schützen von schlechten Passwörtern, aber nur unwesentlich zum Schutz eines einzelnen Passworts.
Der Einsatz von Captchas erschwert nur rein automatisierte Angriffe, macht sie aber längst nicht unmöglich.
Pryos.org hat das denke ich in einem anderen Kontext gemeint, sprich der sich einloggende Benutzer soll den Salt nur in der Art eines Captachs selbst eingeben.
-
-
-
-
Mir ist bei eurer Unterhaltung eine Idee gekommen.
Würde es ein Vorteil bringen, wenn man ein Bild mit einer Zahl (wie Captcha) an den Client übermittelt. Mit dem Eingabewert (wird nicht übertragen) aus dieser Zahl wird der Hash gesalzen und auf dem Server vergleichen.Nein, da der Salt ja auch irgendwie übertragen oder vewandt werden muss bzw. entsprechend abgefangen werden kann.
Wie bereits erwähnt spielt es keine Rolle ob das Passwort im Klartext, als Hash oder als gesalzener Hash übertragen wird, wenn der Angreifer bereits an einer Stelle sitzt, an der er eine unsichere Verbindung überwachen kann.
-
-
-
-
-
-
-
Üblicherweise wird ein gesalzener Hash verwendet.
Aber auch der dient nicht dazu, das Login sicherer zu gestalten, sondern das Klartextpasswort zu schützen.
-
Hallo suit
Und wenn überall das Passwort als Hash-Wert übertragen wird, dann braucht der Angreifer auch nur diesen Hash. … Wo liegt da der Vorteil?
Üblicherweise wird ein gesalzener Hash verwendet.
Aber auch der dient nicht dazu, das Login sicherer zu gestalten, …
Wo habe ich das behauptet?
Auf Wiederlesen
Detlef--
- Wissen ist gut
- Können ist besser
- aber das Beste und Interessanteste ist der Weg dahin!-
Aber auch der dient nicht dazu, das Login sicherer zu gestalten, …
Wo habe ich das behauptet?
Hast du nicht - aber Novi liest das auch aus einem verlinkten Artikel raus wo das so nicht steht ;)
-
Hallo,> > > Aber auch der dient nicht dazu, das Login sicherer zu gestalten, …
Wo habe ich das behauptet?
Hast du nicht - aber Novi liest das auch aus einem verlinkten Artikel raus wo das so nicht steht ;)
Ja da muss ich dir schon recht geben, dass es da nicht explizit geschrieben steht. Man könnte es aber so verstehen, weil ja auch nicht direkt darauf hingewiesen wird, dass es nicht so ist.
Aber bitte versteh mich nicht falsch und glaube, dass ich das auch so sehe. Mir ist es ja klar wie es ist, ansonsten hätte ich ja auch kein Grund den Artikel zu kritiesieren.
Viele Grüße Novi
--
"(...) deshalb mag ich Binärtechnik. Da gibt es nur drei Zustände: High, Low und Kaputt." (Wau Holland)
-
-
-
-
-
-
-
-
-
Hola!
Hier wird doch tatsächlich behauptet, dass es sinnvoll ist die Passwörter vor dem übertragen einfach durch eine Hash-Funktion laufen zu lassen.
Noch ein theoretischer Einwand in eine andere Richtung: Ich hab mich nicht vertieft mit Hash-Funktionen auseinandergesetzt, aber das Grundprinzip ist doch, dass eine sehr grosse Menge an möglichen Eingabewerten auf eine viel kleinere Menge von Ausgangswerten gemappt werden und die Funktion dadurch irreversibel wird. Wenn jetzt aber ein potentieller Hacker nicht mehr das Passwort, sondern den Hash erraten muss (da dieser im Endeffekt übertragen wird), dann wird doch das Ganze viel angreifbarer, da es weniger mögliche Kombinationen gibt?
gruss
stewe
-
-
Wenn tatsächlich eine Verschlüsselung vorliegt, also nur Geheimtext und der JavaScript-Entschlüsselungsalgorithmus im Quelltext steht, dann muss man ihn sehr wohl knacken, denn den Schlüssel kennt ja nur der Anwender.
Das erfordert aber, dass der auszuliefernde Klartext ebenfalls nur in verschlüsselter Form im JavaScript-Quellcode vorliegt. Jegliche Weiterleitung auf eine öffentliche Seite führt das Konzept ad absurdum.
-
-
-
Hai!
auf so ziemlich jeder Website, die sich mit Javascript oder HTML befasst steht, dass es keinen sicheren Javascript Passwortschutz gibt.
Das steht da, weil es so ist. Der Grund ist einfach: Javascript wird browserseitig ausgeführt, das heisst es handelt sich um für jeden frei einsehbaren Code. Auch dass du den Code noch verschlüsselst ändert nichts daran - nichts kann mich daran hindern, diesen wieder zu entschlüsseln. Verschlüsseln ist nicht gleich schützen.
Und wenn ich den Code sehe, dann hindert mich nichts daran, irgendeine Zahl genau so zu erstellen wie es dein Code tut, um damit dann auf die von dir angegebene Seite zu kommen.Aber das ist noch nichtmal die eigentliche Unsicherheit deines Scripts.
Denn ich muss mir gar nicht erst die Mühe machen, eine passende Zahl zu erstellen:
Ich kann einfach in meinem Browser Javascript deaktivieren und dann wunderschön auf deine "gesicherte" Seite surfen...Warum? Der Server schickt mir die Seite mit dem gesamten Code, auch jenem, den du eigentlich schützen wolltest. Javascript kann mich niemals daran hindern, diesen anzuschauen.
Fazit: Du hast noch sehr sehr sehr viel zu lernen..
-
Hi!
Allerdings glaube ich eine Möglichkeit gefunden zu haben einen sicheren Javascript Passwortschutz zu erstellen.
Nein, das ist ein Mißverständnis in der selben Größenordnung wie dieses hier, welches Du auch mit "allerdings.." zu erklären versuchtest.
Was kommt als nächstes? Ein paar Märchen sind ja vielleicht noch übrig...off:PP
--
"You know that place between sleep and awake, the place where you can still remember dreaming?" (Tinkerbell)
-
Hi!
nach nochmaligem Lesen von https://forum.selfhtml.org/?t=195946&m=1312208, in welchem Du nicht geantwortest hast, nach Deiner kühnen Behauptung in diesem Thread und diesem Beitrag heute, halte ich Dich für einen 100% Troll!off:PP
--
"You know that place between sleep and awake, the place where you can still remember dreaming?" (Tinkerbell)
-
Hallo,
Wenn jemand versuchen sollte die geheime oder die login seite ohne javascript zu öffenen kann nicht entcodiert werden, also sieht er nichts ausser dem verschlüsselten code. Wer versucht die geheme seite einfach über die URL aufzurufen fliegt sofort raus. Ich erlaube jedem, der etwas davon hält diessn Code zu kopieren. Bitte sagt mir, was ihr davon haltet.
MFG SimonSSSda du es ja nur testen willst, habe ich mir mal erlaubt dir zur Beweisen, dass man deinen Schutz ohne Probleme umgehen kann:
http://www.simodan.de/privat.html?95.207508264767024e+50Deine Ideen und deine Verschlüsselung machen die Sache natürlich schon etwas komplizierter. Mit einem geeigneten Browser, sieht man aber ohne Probleme den decodierten Quelltext.
Deine Passwortabfrage bietet vielleicht einen effektiven Schutz für sagen wir mal maximal 5 Minuten. Aber auch nur dann, wenn der "Angreifer" oder halt der Tester deines Scriptes nicht weiß, wie dein Script im groben funktioniert.
Viele Grüße Novi
--
"(...) deshalb mag ich Binärtechnik. Da gibt es nur drei Zustände: High, Low und Kaputt." (Wau Holland) -
Hallo,
var b = ((((((((((((((((a+10)*3)+23)*85)-2)*16)+8)*7)-70)*99)+12345)*852)+741236985)*8426)+666)*951235786248951368742685135497265); // erzeugt eine Kompliziert erstellte Zahl b
Das ist ein Trugschluss. Auch wenn der Term lang ist, ist er im Grunde genommen nur eine lineare Funktion:
var b = 19308237299274200000000000000000000000000000000*a+346976690783234000000000000000000000000000000000
Gut das Ergebnis könnte eine Rundung sein, aber das spielt bei deinem Script ja scheinbar eh keine Rolle.
Viele Grüße Novi
--
"(...) deshalb mag ich Binärtechnik. Da gibt es nur drei Zustände: High, Low und Kaputt." (Wau Holland)