Das leidige Thema: Passwortschutz mit JS

[dbarthel]

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 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.

bei sowas immer wieder
SELFHTML Forumsarchiv / 2008 / April / Wettangebot: Verschlüsselung knacken

Mal davon abgesehen, das solche Rechnereien zu ungunsten der Ladezeit ausfallen und User, die keine Javascript verwenden, dumm aus der Wäsche gucken lassen.

 

[Yogilein]

Ich verstehe eure Antworten nicht ganz.

Der so erzeugte Code ist nicht zurückrechenbar, da er über den Zufallsgenerator läuft. Man braucht definitiv das Passwort, ansonsten kommt nur Müll heraus, auch wenn nur ein einziges Zeichen nicht stimmt.

Und hier noch eine Modifikation:

Verschlüsselt gibt es nur noch eine einzige Zeile.

Somit kann man nicht erkennen, wann eine neue Zeile anfängt und darauf hoffen, dass diese mit "<" beginnt.

Und so lange braucht JS auch nicht. Das geht im Bruchteil einer Sekunde.

Und klar, für eine JS-Lösung (.htacces + PHP war ja ausgeschlossen) benötigt der Anwender nun mal JS.

 

[dbarthel]

Ich verstehe eure Antworten nicht ganz.

Der so erzeugte Code ist nicht zurückrechenbar

Wie soll das denn gehn, dann könnte dein Script ja nie den Code richtig anzeigen, denn um ihn richtig anzuzeigen, muss es daa ganze ja entschlüsseln... zudem ich dachte:

PS: Es wird keine Seite mit einem kryptischen Namen aufgerufen, denn das wollte der liebe Kollege auch nicht.

 

[j-l-n]

Wie soll das denn gehn, dann könnte dein Script ja nie den Code richtig anzeigen, denn um ihn richtig anzuzeigen, muss es daa ganze ja entschlüsseln...

Warum sollte das nicht gehen??

//angenommen folgendem verschlüsselten String: U2FsdGVkX1/qgRQo5xga/U3OnpSipDxuZX/ToXApOg1LZWsEJKnT/DnqlmKzkY/h

loadFunctions("crypto-js.googlecode.com/svn/tags/3.1.2/build/rollups/aes.js", true);
var password = location.hash;
var decrypted = CryptoJS.AES.decrypt(encrypted, password);
var decrypted = ConvertChars(decrypted, "hex", "ascii");
document.getElementsByTagName('html')[0].innerHTML = decrypted;

Da steht doch auch nicht das Password im Quellcode, und dennoch wird es logischerweise bei richtigem Passwort korrekt entschlüsselt...


@Yogilein: document.write solltest du am besten gleich wieder vergessen

 

[dbarthel]

@Julian: Du verwendest ja auch einen Algorithmus und keine Zufallszahlen, so wie von Yogi benannt.

Zufallszahlen sind, wie der Name vermuten lässt, einen ausreichenden Zahlenbereich vorausgesetzt, zufällig.

Wenn ich nun zum Beispiel 6 mit einer 20 stelligen Zufallszahl mahl nehme und dann das Ergebnis wieder durch eine neue Zufallszahl dividiere, wird nur sehr selten wieder 6 rauskommen.

 

[j-l-n]

@Julian: Du verwendest ja auch einen Algorithmus und keine Zufallszahlen, so wie von Yogi benannt.

Dann haben wir uns missverstanden, es ging mir um's Prinzip.

Zufallszahlen sind, wie der Name vermuten lässt, einen ausreichenden Zahlenbereich vorausgesetzt, zufällig.

Ja, normalerweise schon. Aber vermutlich ist sein "Zufallszahlengenerator" der Gleiche wie in diesem Thread...

- - - Aktualisiert - - -

@Yogilein: das Ganze ist mir etwas unklar, könntest du es nochmal erklären?
Ich finde weiterhin die Lösung mit dem MD5-Hash als Dateinamen am sichersten. Wieso verwendest du sie nicht? Da wäre es übrigens sinnvoll, die geheime Seite in einem iframe zu laden, dann taucht sie nämlich auch nicht in dee Chronik auf.

 

[Yogilein]

@Yogilein: document.write solltest du am besten gleich wieder vergessen

Das bekomme ich jetzt schon das zweite Mal gesagt, aber es gibt doch keinen Ersatzbefehl??? Ziel ist, mit JS ausführbaren HTML-Code zu schreiben.

Der so erzeugte Code ist nicht zurückrechenbar
Wie soll das denn gehn, dann könnte dein Script ja nie den Code richtig anzeigen, denn um ihn richtig anzuzeigen, muss es daa ganze ja entschlüsseln...

Zurückrechnen heißt, dass man aus dem verschlüsselten Code niemals das Passwort errechnen kann. Dafür zuständig ist u.a. der Zufallszahlengenerator.

Ich will das mal so erklären: Es gibt ganz einfache mathematische Funktionen, die nur in eine Richtung funktionieren, z.B. ABS oder POW. Wäre mein Passwort (in Ziffern umgerechnet) 47 kann ich z.B. daraus ABS(4-7)=3 machen, aber von der 3 werde ich niemals mehr (eindeutig) auf die 47 kommen, auch wenn ich den Algorithmus kenne, denn es könnte auch 96, 69, 85, 58 usw. richtig sein.

Und was macht nun mein Zufallsgenerator mit Startwert? Er erzeugt Zufallszahlen ähnlich Math.Random. Aus dem Passwort mache ich z.B. 2556897 und gebe dies als Startwert ein. Als Ergebnis erhalte ich dann z.B. 25, 152, 7, 34, 212, ... mit diesen Werten xore ich den Quellcode und erhalte eine kryptische Zeile. Xore ich diese mit den gleichen Werten wieder, erhalte ich wieder den ursprünglichen Code. Der Zufallszahlengenerator braucht jetzt also wieder den Startwert 2556897 und gibt mir dann die gleichen Zufallszahlen aus.

Trotz, dass ich zweimal die gleichen Zufallszahlen erhalten habe, bleibt der Zufallszahlengenerator ein Zufallszahlengenerator. Jeder Zufallszahlengenerator muss initialisiert werden. I.d.R. nimmt man dazu einen Timerwert, z.B. getTime(). So hat man zu jedem Zeitpunkt unterschiedliche Zufallszahlen. Das macht auch JS so, allerdings automatisch.

Ich halte es daher für mathematisch unmöglich, aus dem gexorten Code das Passwort zurückzurechnen.

zudem ich dachte:
PS: Es wird keine Seite mit einem kryptischen Namen aufgerufen, denn das wollte der liebe Kollege auch nicht.

Die Seite muss ja dadurch keinen kryptischen Namen erhalten, sondern kann ganz normal heißen, lediglich der Code darin ist teilweise kryptisch.

 

[tsseh]

Zurückrechnen heißt, dass man aus dem verschlüsselten Code niemals das Passwort errechnen kann. Dafür zuständig ist u.a. der Zufallszahlengenerator.

ein xor das ist aber kein kryptographisch sicherer algorithmus und damit zurückrechenbar. und auch wenn du den schlüssel in jedem durchgang nach einem festen schema veränderst, wird es dadurch nicht sicherer.

Ich will das mal so erklären: Es gibt ganz einfache mathematische Funktionen, die nur in eine Richtung funktionieren, z.B. ABS oder POW. Wäre mein Passwort (in Ziffern umgerechnet) 47 kann ich z.B. daraus ABS(4-7)=3 machen, aber von der 3 werde ich niemals mehr (eindeutig) auf die 47 kommen, auch wenn ich den Algorithmus kenne, denn es könnte auch 96, 69, 85, 58 usw. richtig sein.

und der anfang ist gemacht

Und was macht nun mein Zufallsgenerator mit Startwert? Er erzeugt Zufallszahlen ähnlich Math.Random.

nein, nichtmal das

Jeder Zufallszahlengenerator muss initialisiert werden. I.d.R. nimmt man dazu einen Timerwert, z.B. getTime(). So hat man zu jedem Zeitpunkt unterschiedliche Zufallszahlen.

und kann aus jeder die folgende berechnen

Ich halte es daher für mathematisch unmöglich, aus dem gexorten Code das Passwort zurückzurechnen.

ja, das glauben alle, die mit xor etwas "verschlüsseln".
wobei, es geht nicht um zurückrechnen, sondern um analyse:
also es handelt sich um html => das erste zeichen ist vermutlich ein blank oder <
...

 

[kkapsner]

Interessant! Und wie?

Hab' ich hier über HttpFox gemacht.

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

Auch ein Passwort, das aus zwei Teilen besteht, ist ein Passwort... Aber ich finde die Verschlüsselungsidee eigentlich gar nicht schlecht.

Ob er nicht einfach die Konsole des Browsers meint? Da kann man im Reiter Netzwerk alles ablesen.

Nein kann man nicht, da diese Ansicht bei jedem Seitenladen geleert wird.

Da wäre es übrigens sinnvoll, die geheime Seite in einem iframe zu laden, dann taucht sie nämlich auch nicht in dee Chronik auf.

In der Chronik nicht, aber im Cache. Schon.

Ein XOR ist eigentlich die sicherste Verschlüsselung, wenn der Schlüssel, mit dem das XOR durchgeführt wird genauso lang ist, wie der zu verschlüsselnde Text... sonst gebe ich hesst Recht: über eine Analyse kann man das knacken. Aber warum verwendest du nicht einfach AES?

PS: 99% der Anwendungsbereiche für document.write() kann man mit .innerHTML lösen.
PPS: Du kannst uns ja mal eine Testseite geben und dann sehen wir, wie lange wir brauchen, um das zu knacken.

 

[tsseh]

Ein XOR ist eigentlich die sicherste Verschlüsselung, wenn der Schlüssel, mit dem das XOR durchgeführt wird genauso lang ist

du bist KRYPTOCHEF Detlef Granzow (persönlich)?

PS: 99% der Anwendungsbereiche für document.write() kann man mit .innerHTML lösen.

welchen vorteil bringt innerHTML hier?
ich sehe hier nur den nachteil, dass scripte nicht ausgeführt werden!

 

[kkapsner]

du bist KRYPTOCHEF Detlef Granzow (persönlich)?

Nein... warum?
Zusätzlich muss der Schlüssel natürlich komplett zufällig sein und darf nur ein einziges Mal verwendet werden. Deswegen ist es komplett unbrauchbar. Aber an sich ist es sicher.

welchen vorteil bringt innerHTML hier?

Es ist flexibler, kann zu jedem Zeitpunkt eingesetzt werden und ist nicht document.write(). Ich werde jetzt aber nicht wieder mit dir darüber diskutieren.

ich sehe hier nur den nachteil, dass scripte nicht ausgeführt werden!

Das kann man nachbessern und ist in den 1% enthalten.

 

[tsseh]

Nein... warum?

du kennst KRYPTOCHEF Detlef Granzow (persönlich) nicht? der hat vor jahren mal das ganze internet getrollt.
selbst zu bruce schneider ist das durchgedrungen https://www.schneier.com/blog/archives/2006/06/the_doghouse_kr.html
KRYPTO 4.0/2014 Professional Multi User war seine One-Time-Pad verschlüsselung. die einzig wahre. 256 vollbit!!einself

Es ist flexibler, kann zu jedem Zeitpunkt eingesetzt werden

das sehe ich hier nicht

Das kann man nachbessern

also selbst was basteln anstelle eine bereits vorhandene nativ funktion zu nutzen findest du besser?

und ist in den 1% enthalten.

also was nun? soll man write nun nicht benutzen, oder gibt es doch einsatzgebiete?

 

[Yogilein]

also es handelt sich um html => das erste zeichen ist vermutlich ein blank oder <

Ich habe unter DOS früher gerne solche Spielchen gemacht und sehe erstmals auch hier kein Problem.

Also die verschärfte Version:

1. Die verschlüsselten Zeichen sind nicht in der richtigen Reihenfolge (auch wieder per Zufallszahlengenerator machbar), so dass das erste Zeichen kein "<" ergeben muss.
2. Und nochmals verschärft: Als erstes schreibt der Entschlüsselungscode von sich aus das "<"-Zeichen, so dass es nicht errechnet werden muss. Danach kann kommen, was will, z.B: "Hier beginnt der Code></Hier>. Das erste Zeichen in diesem Beispiel ist jetzt also ein "H".
3. Ein weiteres Problem in HTML ist, dass bestimmte Zeichen gehäuft vorkommen, gerade das "<". Hier kann man versuchen, das Zeichen automatisch zu setzen, z.B. wenn "Leerzeichen, p, Leerzeichen" errechnet wird, mache "<p>" daraus. " Das kann man noch beliebig ausweiten und verfeinern.

Natürlich kann man auch das knacken, aber Ausgangspunkt war, eine Seite vor unbedarften Verwandten zu schützen. Früher (auch zu DOS-Zeiten) hatte ich sogar mal ein Programm, das passwortgeschützte ZIP-Dateien knacken konnte. Also, nichts ist sicher ...

 

[dbarthel]

Natürlich kann man auch das knacken, aber Ausgangspunkt war, eine Seite vor unbedarften Verwandten zu schützen.

Ja eben, warum dann deine zig-mal verschärfte Verschlüsselung?
Für unbedarfte Verwandte reicht sicher auch AES oder Hashing.

So langsam verstehe ich hier den Sinn deines Threads nicht mehr.

Zu Anfang leitetest du das ganze selbst mit der Bezeichnung "das leizige Thema" ein und lieferst dazu eine Testseite, die innerhalb von einer Minute zu knacken war, und jetzt plötzlich soll es der super-krypzische Code sein.

Willst du von uns Absolution?
Wenn du denkst du hast einen nicht knackbaren Weg gefunden, dann bitte.

Allerdings frag ich mich langsam, was so geheimnisvolles in die Seite rein soll, um so einen Aufwand zu rechtfertigen?

Ansonsten würde da jetzt wirklich eine Testseite mit dem neuen Code von Interesse sein.
(Bitte für mich diese auch nach dem WE on lassen, falls du sie erst morgen on stellst. )

 

[jspit]

Hi,
da ich vor einigen Jahren auf meiner Page noch kein PHP verfügbar hatte und einige Seiten nicht für jedermann zugänglich sein sollten,
hab ich was ähnliches gemacht wie julian #11 beschrieben hat. Jedoch mit einer kleinen Modifikation:
- die geschützten Seiten erhalten einen Namen, der das Passwort enthält.
- Bei Eingabe eines Passwortes wird der Seitenname zusammengesetzt
- Vom Eingabe-Passwort wird eine CRC-Prüfsumme berechnet und mit der gespeicherten CRC-Prüfsumme des richtigen Passwortes verglichen
Bei positiven Vergleich wird auf den Seitennamen weitergeleitet, bei negativen Vergleich wird eine Meldung ala Sorry ausgegeben.

Das Passwort selbst taucht nirgens auf, man muss also die Seite erraten. Je länger das Passwort bzw. der Seitenname ist, um so sicherer ist es.
Denkbar wäre noch die CRC-Summe aus dem Code zu ziehen, sich eine Passwortliste generieren zu lassen und diese dann zu probieren.
Der Aufwand ist aber schon erheblich.

LG jspit

 

[j-l-n]

Genau, jspit. Und da richte ich zum wiederholten Mal meine Frage an Yogilein: wieso setzt du nicht diese Lösung ein?

 

[Yogilein]

Genau, jspit. Und da richte ich zum wiederholten Mal meine Frage an Yogilein: wieso setzt du nicht diese Lösung ein?

Wie bereits gesagt, wollte der Kollege ursprünglich eine reine JS-Lösung, kein PHP, keine .htaccess und keinen kryptischen Seitennamen.

Der aktuelle Stand ist, dass er sich jetzt die Jimdo-Option "Passwortschutz" anschaut. Das ist vorerst die Lösung und ich werde euch jetzt nicht mehr länger mit irgendwelchen Verschlüsselungen nerven

 

[dbarthel]

Der aktuelle Stand ist, dass er sich jetzt die Jimdo-Option "Passwortschutz" anschaut. Das ist vorerst die Lösung und ich werde euch jetzt nicht mehr länger mit irgendwelchen Verschlüsselungen nerven

Na das ist jetzt fast schade, hätte das gerne mal getestet.

 

[miniA4kuser]

Na das ist jetzt fast schade, hätte das gerne mal getestet.

Ich auch!!!
Brauche Futter... Futter... Futter... Futter... Futter... Futter... Futter... Futter... Futter... Futter... Futter... Futter...

 

[kkapsner]

du kennst KRYPTOCHEF Detlef Granzow (persönlich) nicht?

Ach der. Doch den kenn' ich. Bin ich aber nicht...

also selbst was basteln anstelle eine bereits vorhandene nativ funktion zu nutzen findest du besser?

Da ich das sowieso basteln muss, weil ich ja auch nach dem onload noch HTML ins DOM schreiben will und dabei eventuell die <script>s auch brauche, kann ich auch immer das nehmen (wenn man das nicht selber basteln will, kann man ja z.B. .html() von jQuery verwenden), das ich immer einsetzen kann. So von wegen Faulheit und so... muss mir weniger merken und weniger nachdenken. Auch ist der Code dann in anderen Szenarien einsetzbar.

also was nun? soll man write nun nicht benutzen, oder gibt es doch einsatzgebiete?

Es gibt ein einziges Einsatzszenario für document.write() (wenn man <script> dynamisch erstellen muss und die Ausführreihenfolge fest befolgt werden muss). Den Rest der 1% kann man mit .innerHTML und Konsorten lösen, muss aber dabei etwas Mehraufwand betreiben.

Auch sehe ich hier nicht, dass <script>s in dem verschlüsselten HTML Sinn ergeben. Der Inhalt soll ja verschlüsselt werden und nicht die Funktionalität.

Aber hesst, das ist hier jetzt wirklich mein letzter Beitrag zu dem Thema.

@miniA4kuser: dito.