• Das Erstellen neuer Accounts wurde ausgesetzt. Bei berechtigtem Interesse bitte Kontaktaufnahme über die üblichen Wege. Beste Grüße der Admin

Das leidige Thema: Passwortschutz mit JS

Y

Yogilein

Member
Ein Geschäftskollege wollte von mir einen einfachen Passwortschutz über JS (auf .htaccess + PHP hat er keinen Zugriff). Obwohl ich ihm krampfhaft versuchte zu erklären, dass dies eigentlich unmöglich sei, beharrte er darauf und meinte, dass der Schutz nicht besonders gut sein muss, da er nur gewisse Familienmitglieder ausschließen möchte, die sich sowieso nicht sehr gut auskennen.

OK, ich habe mal etwas versucht und möchte von euch wissen, wie lange ihr braucht, um das Passwort herauszufinden, vielleicht noch mit der Unterscheidung, ob ihr euch eher als Profi oder als Normalanwender seht. Ich kann ihm ja schlecht ein Skript geben, das jeder in 10 Sekunden mühelos knacken kann.

Das Skript ist eigentlich ganz einfach aufgebaut: Wenn das hinterlegte Passwort fehlt oder falsch ist, wird eine Fehlerseite mit einem entsprechendem Hinweis aufgerufen.

Ich habe meine Umsetzung temporär hier hochgeladen: http://www.yogifotos.de/Test/Passworteingabe.htm

Also, wie schnell seid ihr?

PS: Es wird keine Seite mit einem kryptischen Namen aufgerufen, denn das wollte der liebe Kollege auch nicht.
 
Warum gibt dein Kollege denn seinen Verwandten, die er aussperren will überhaupt die URL?
Und warum muss es via JS sein? Accessprotect ist wenigstens etwas sicherer.
 
Zuletzt bearbeitet:
dbarthel schrieb:
Warum gibt dein Kollege denn seinen Verwandten, die er aussperren will überhaupt die URL?
Und warum muss es via JS sein? Accessprotect ist wenigstens etwas sicherer.
Zum Vergrößern anklicken....

Gute Frage. Ich werde ihn morgen darauf ansprechen, dass er ja einfach eine neue Unterseite mit einem neuen Namen erstellen soll, die dann natürlich vom Menü her nicht verlinkt ist.

Auf die .htaccess-Datei hat er auskunftsgemäß keinen Zugriff.

Mich würde aber trotzdem interessieren, wie schnell ihr das Passwort knacken könnt.
 
Werde ich morgen testen, wenn ich am Pc bin, vom Handy aus ist mir das gefummel auf dem Touch zu groß.
 
Julian schrieb:
Nicht mal eine einzige Minute - JavaScript und automatische Weiterleitung deaktiviert und einen kurzen Blick in den Quelltext geworfen...
Zum Vergrößern anklicken....

Hätte ich auch so gemacht, ist nur wie gesagt auf dem Handy etwas unpraktisch.

Vielleicht doch mal access-protect versuchen, für den Ausschluß von lästigen Familienmitgliedern reicht es allemal.
 
Julian schrieb:
und der massive Einsatz von document.write --> javascript - Why is document.write considered a "bad practice"? - Stack Overflow).
Zum Vergrößern anklicken....
document.write (henceforth DW) does not work in XHTML
Zum Vergrößern anklicken....
xhtml ist tot
DW executed after the page has finished loading will overwrite the page, or write a new page, or not work
Zum Vergrößern anklicken....
onklick feuert auch nicht, wenn man text in ein eingabefeld eingibt
DW executes where encountered: it cannot inject at a given node point
Zum Vergrößern anklicken....
das ist falsch, der 2. teil jedenfalls
DW is effectively writing serialised text ...
Zum Vergrößern anklicken....
ja und? das ist ja gerade der einsatzzweck
...which is not the way the DOM works conceptually...
Zum Vergrößern anklicken....
das ist käse
..., and is an easy way to create bugs
Zum Vergrößern anklicken....
warum das denn?
 
Julian schrieb:
Nicht mal eine einzige Minute - JavaScript und automatische Weiterleitung deaktiviert und einen kurzen Blick in den Quelltext geworfen...
Zum Vergrößern anklicken....

OK, ich dachte bzw. hoffte, dass nicht jeder gleich darauf kommt, neben JS auch das automatische Weiterleiten zu unterbinden. Hätte das auch ein Anfänger so sofort hinbekommen? Zumindest meine Familie (auch relativ unbedarft) schaffte es nicht. Aber danke für das Ergebnis, was für mich bedeutet, dass ich meinem Kollegen diese Löung nicht anbieten werde. Und wie gesagt .htaccess soll nicht gehen, da es eine kostenlose Jimdo-Seite ist. Ich werde wohl mal selbst schauen müssen. Ansonsten gefällt mir die Löung mit einer neuen Unterseite, die nicht verlinkt ist, noch am besten.

Julian schrieb:
PS: du solltest deine Scripts dringend überarbeiten (etliche globale Variablen und der massive Einsatz von document.write --> javascript - Why is document.write considered a "bad practice"? - Stack Overflow).
Zum Vergrößern anklicken....

Das document.write stammte aus meinem Menü, das mit JS die Untermenüs aufbaut und eigentlich nur mit diesem Befehl HTML-Code schreiben kann, zumindest ist das mein Wissensstand. Lt. meinem JS-Buch ist document.write eigentlich veraltet, aber durchaus noch einsetzbar. Da mich die JS-Lösung sowieso ein bisschen gestört hat, habe ich das Menü jetzt komplett in PHP geschrieben (war ja nicht so viel). Auch hier danke für den Anstupser.

Ja, ich habe womöglich auch zu viele globale Variablen, aber sie sind alle abgestimmt und kommen sich nicht in die Quere. Das werde ich bei meinen nächsten Vorhaben auch anders machen.
 
miniA4kuser schrieb:
Ja was denn nun? PHP ja oder nein?
Zum Vergrößern anklicken....

Das Menü ist jetzt eine PHP-Datei die per include eingelesen wird und in Abhängigkeit der Seite die Untermenüs einblendet. Die vorhergehende Lösung hatte zwar das gleiche gemacht, allerdings mit JS und somit mit dem document.write-Befehl. Gestört hatte mich, dass die Untermenüs nicht aufgingen, wenn JS deaktiviert war. Eigentlich war das gar nicht mal so schlimm, denn Bilder anschauen konnte man nämlich nicht, denn der Bildviewer braucht JS. Aber irgendwie fand ich es nicht gut, dass man dadurch auch nicht die einzelnen Galerien sehen konnte, zumindest vom Namen her.

Ich hatte mal eine Seite, die aus über 80 Einzelseiten bestand und da war das Menü jeweils Bestandteil der einzelnen Seiten. Und da es auch nicht immer gleich war (aktive Seite ausgeblendet, Untermenüs etc.) war der Pflegeaufwand enorm hoch, wenn einmal ein Menüpunkt sich geändert hat oder hinzugekommen ist. Und bei YogiFotos muss ich jetzt nur noch eine einzige PHP-Datei ändern und das war's. Und auch der Validator meckert nicht mehr. Ich vermute, dass dieser Probs mit den maskierten Anführungszeichen hatte, die aber jeder Browser geschluckt hat und lt. Fehlerkonsole auch nicht angemeckert wurden.

PS: Um genau auf deine Frage einzugehen: Heute Morgen noch JS und ab heute Abend PHP.
 
Yogilein schrieb:
Hätte das auch ein Anfänger so sofort hinbekommen? Zumindest meine Familie (auch relativ unbedarft) schaffte es nicht.
Zum Vergrößern anklicken....
Ich täte sagen: für einen technisch etwas versierten Nutzer absolut kein Problem, für "Otto-Normal-User" aber meiner Meinung nach eigentlich ausreichend.
Am sinnvollsten fände ich die Lösung, dass man ein Passwort eingibt und dann zu einem Dokument weitergeleitet wird, dessen Name dem MD5-Hash davon entspricht.
Bsp: das Passwort ist "password". Die geheime Seite muss also "5f4dcc3b5aa765d61d8327deb882cf99.html" lauten. Gibt ein Nutzer nun ein anderes Passwort ein, landet er woanders und bekommt einen 404 Error.

Yogilein schrieb:
Aber danke für das Ergebnis, was für mich bedeutet, dass ich meinem Kollegen diese Löung nicht anbieten werde.
[...]
Auch hier danke für den Anstupser.
Zum Vergrößern anklicken....
Bitteschön - gern geschehen!

PS: ich habe bei Jimdo keine Homepage, aber laut Hilfe kann man da auch passwortgeschützte Seiten erstellen. Läuft dann bestimmt serverseitig und bietet somit einen echten Schutz. Passwortgeschützte Bereiche - Jimdo SupportCenter - (DE)
 
Julian schrieb:
[...]
Am sinnvollsten fände ich die Lösung, dass man ein Passwort eingibt und dann zu einem Dokument weitergeleitet wird, dessen Name dem MD5-Hash davon entspricht.
Bsp: das Passwort ist "password". Die geheime Seite muss also "5f4dcc3b5aa765d61d8327deb882cf99.html" lauten.
Zum Vergrößern anklicken....

Apropos MD5-Hash, was haltet ihr von crypto.js? ( https://code.google.com/p/crypto-js ) - damit liese sich sogar eine geheine Passphrase integrieren (welche man der Seite als Variable zb. über die Adresszeile übergeben könnte), die für zusätzliche Sicherheit sorgt.
 
Zuletzt bearbeitet:
miniA4kuser schrieb:
Und warum machst du dann nicht einfach nen simplen Login mit Session über PHP? Wenn eingeloggt Seite anzeigen und wenn nicht, dann Loginformular (so ähnlich wie bis jetzt).
Zum Vergrößern anklicken....
Wir reden von zwei verschiedenen Seiten. Auf meiner (Bezahl-) Seite geht natürlich PHP, auf der kostenlosen Jimdo-Seite des Kollegen angeblich nicht.

Ich werde heute aber auf jeden Fall an ihn weitergeben, dass Jimdo die Option Passwortschutz anbietet, wobei ich nicht weiß, was damit möglich ist.
 
dbarthel schrieb:
damit liese sich sogar eine geheine Passphrase integrieren (welche man der Seite als Variable zb. über die Adresszeile übergeben könnte), die für zusätzliche Sicherheit sorgt.
Zum Vergrößern anklicken....

Eine geheime Passphrase ist doch das gleiche wie ein Passwort...

Ein Hash vom Passwort als Dateiname ist, meiner Meinung nach, das Sicherste, was man da mit JS machen kann... und das ist nicht besonders sicher. Dann muss man aber massiv mit seiner Browserverlauf aufpassen.

PS: hab' etwa eine halbe Minute gebraucht. Einfach den Netzwerkverkehr mitgeschnitten und dann angesehen.
 
kkapsner schrieb:
Eine geheime Passphrase ist doch das gleiche wie ein Passwort
Zum Vergrößern anklicken....

Nicht ganz, denn dann würde das ganze zweifach verschleiert.

Selbst wenn durch Zufall das richtige PW eingegen würde, jedoch nicht der richtige Key (Passphrase) an die Seite übergeben würde, käme keine Weiterleitung zum geschützten Bereich zustande.

Ansonsten bleibt es natürlich, wie bereits gesagt.
Clientseitig und mit JS ist Verschlüsselung nur sehr unzureichend möglich.
 
Ich habe mit meinem Kollegen gesprochen und er will jetzt schauen, was Jimdo für einen Passwortschutz anbietet.

Aber noch eine Idee:

Ich verschlüssele die ganze Seite in der Art:

Code: 
zeile[1]="sfsf2sf58s8fsfY3s3f1s658f8Psree3f"
zeile[2]="asasdöldöadgöadgöadgöEkads1235ü8gaöasög"
.
.
.

Die Entschlüsselung erfolgt dann über das Passwort, indem jeder Buchstabe der verschlüsselten Zeilen damit gexort wird. Anschließend wird die so ermittelte Zeile mit document.write herausgeschrieben. Evtl. kann das Passwort auch meinen Zufallsgenerator ansteuern :grin: und dessen Rückgabewerte dienen zum xoren. Somit erzeugt ein Passwort mit wenigen Stellen trotzdem viele unterschiedliche Zeichen zum xoren.

Die Funktion zum Entschlüsseln steht natürlich im Klartext in der Datei, aber diese nutzt ohne Passwort eigentlich nicht sehr viel.
 
Yogilein schrieb:
Die Entschlüsselung erfolgt dann über das Passwort, indem jeder Buchstabe der verschlüsselten Zeilen damit gexort wird. Anschließend wird die so ermittelte Zeile mit document.write herausgeschrieben. Evtl. kann das Passwort auch meinen Zufallsgenerator ansteuern :grin: und dessen Rückgabewerte dienen zum xoren. Somit erzeugt ein Passwort mit wenigen Stellen trotzdem viele unterschiedliche Zeichen zum xoren.

Die Funktion zum Entschlüsseln steht natürlich im Klartext in der Datei, aber diese nutzt ohne Passwort eigentlich nicht sehr viel.
Zum Vergrößern anklicken....
bei sowas immer wieder
SELFHTML Forumsarchiv / 2008 / April / Wettangebot: Verschlüsselung knacken
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben