Quellcodezeilen Verschlüsseln

[Horst_33]

So, jetzt erst einmal Aufklärung...

Die Sache mit dem Net Use war nur ein Beispiel. Habe im mom. verschiedene Anwendungen, wo ich so etwas gerne einbauen möchte. Es ist jedoch egal, welchen Zweck es haben hat, da es universal funktioieren sollte.

Ich erklärs mal am besten mit einen kleinen Script von mir...

.\Projekte\Picturepush.com\wget.exe -q --no-clobber -r http://www.picturepush.com/webdav.php/ --http-user=[I]cencored[/I]@[I]cencored[/I] --http-password=[I]cencored[/I] --directory-prefix=".\Downloads\Picturepush"

If Errorlevel 1 goto fail

:success
echo # = Picsync was successful
goto end

:fail
color c
echo # = Picsync failed!

:end

Das Script macht folgendes: Es syncronisiert einen Bildbestand vom Bildhoster picturepush.com mit einen Lokalen Ordner, sodass ein Offlineabbild entsteht.

Überall, wo jetzt cencored steht, ist im Script natürlich in PlainText benutzername [E-Mailadresse] und das benötigte Passwort drinnen. Also z. B. user@gmx.de und Passwort123.

Sinn des Scriptes ist auch, dass es komplett automatisch ohne einen Menschen abläuft! Möchte man es anders machen, könnte man ja mit set /P USERNAME= und set /P PASSWORT= das ganze umbiegen, sodass der Benutzer seinen Benutzernamen und Passwort eingeben muss.

Anschließend machste dann...

.\Projekte\Picturepush.com\wget.exe -q --no-clobber -r http://www.picturepush.com/webdav.php/ --http-user=%Benutzer% --http-password=%Passwort% --directory-prefix=".\Downloads\Picturepush"

und es dürfte funktioieren.

So stell ich mir das dann auch für die finalen universellen Scripte vor. Hier wird dann natürlich nichts eingegeben, sondern der PasswortCode wie z. B.

encrypttool.exe fe6fa98138ffab6339e4adeee157538c | set /P BENUTZERNAME=
encrypttool.exe fdaklöjkfö4759p3uf90j4392pßj9ß93qja | set /P PASSWORT=

Wenn das nicht funktioniert bräuchte man halt etwas, was die entschlüsselten Werte direkt in ne Variable zwängt. Alles weitere dürfte ja klar sein.

Info: Dass ich anfänglich MD5 Beispiele verwendet habe ist Egal. Das MD5 hierfür funktioniert, ist mir natürlich klar.

 

[snow1]

Eins vorneweg: das wirst du niemals sicher hinkriegen, solange du auf Skripte setzt, die beim Benutzer ablaufen.

Man braucht nur ein kleines Skript das %Benutzer% und %Passwort% ausgibt schreiben und es statt dem eigentlichen Skript aufzurufen. Schon hat man es wieder.

 

[Horst_33]

set /P Benutzer001=
set /P Passwort001=

NET USE \\Rechner\Pfad %Benutzer001% %Passwort001%

set Benutzer* bzw.

set Benutzer001 = Blubwert

---------------

Wäre her die alternative, denke ich zumindest. Werden zudem solche Variablen nur so lange gespeichert, wie das CLI offen ist? Ansonsten... niemand macht echo %Benutzer%

Möcht doch nur nicht, dass da Plaintext drinen steht, alles andere is mir schnubbe >.>

 

[snow1]

Dann schreib dir doch einfach ein kleines Programm, das als Parameter das Skript erwartet das zu starten ist.

Deine "geheimen" Daten sind dann im Programm hinterlegt. Das Programm setzt dann nur die Parameter und führt das Skript aus.

Damit sind die Passwörter zumindest nicht unmittelbar sichtbar. Zwar kann man sich die Daten aus der Exe trotzdem raus ziehen, aber es ist 100x wahrscheinlicher, dass eher jemand ein Skript baut, was nur die Daten mittels echo ausgibt, bevor er sich den Binärcode ansieht.

Bleibt festzustellen: sicher ist anders - aber es steht zumindest nirgends das Passwort im Plaintext...

 

[Trainmaster]

Passwörter => PHP => MD5!

MD5 ist nur per Rainbow-Tables rückentschlüsselbar.

Also beim Login einfach das eingegebene ein, oder je nach Sicherheit auch zweimal, also per md5 verschlüsseln.

Selten solch einen Unfug gelesen.

MD5 = Hash-Funktion (keine Verschlüsselung!).

"rückentschlüsselbar" - was ist das bitte für ein Wort? Ganz zu schweigen von der fehlerhaften Logik.

Mehrfaches Hashen erhöht nicht die Sicherheit!

 

[Horst_33]

Dann schreib dir doch einfach ein kleines Programm, das als Parameter das Skript erwartet das zu starten ist.

An sich keine schlechte Idee... leider kann ich nichts anderes als Batch. Und kommt mir jetzt nicht mit "Das Lernt man doch schnell.." oder "Da gibts doch 1.000.000 Tutorials...", habs schon sehr oft versucht und bin genau so oft wieder gescheitert. Batch ist alles, was ich kann.

 

[snow1]

Das Grundgerüst, z.B. in C ist recht einfach. Das würde etwa so aussehen (wenn ich mich nirgends vertippt habe )

#include <stdlib.h>
#include <stdio.h>

char user[] = "Benutzer";
char pass[] = "Passwort";

int main(int argc, char **argv) {
  char cmd[256];

  snprintf(cmd, sizeof(cmd), "%s %s %s", argv[1], user, pass);
  system(cmd);

  return EXIT_SUCCESS;
}

Das lässt sich natürlich beliebig erweitern.

Das Programm kannst du dann z.B. mit

startcmd meinscript.bat

aufrufen. Und das Programm (startcmd.exe in dem Fall) macht nix anderes wie

meinscript.bat Benutzer Passwort

aufzurufen. Das kannst du im Batch ja wiederum mit %1 und %2 abgreifen

 

[ice-breaker]

Mehrfaches Hashen erhöht nicht die Sicherheit!

neija ein Fünkchen Wahrheit ist da trotzdem erhalten, die Chance dass ein z.B. 7 stelliges Passwort in einer Rainbow-Tabelle vorhanden ist, ist höher als das ein 32 Zeichen alphanumerischer String dort enthalten ist.

 

[Trainmaster]

neija ein Fünkchen Wahrheit ist da trotzdem erhalten, die Chance dass ein z.B. 7 stelliges Passwort in einer Rainbow-Tabelle vorhanden ist, ist höher als das ein 32 Zeichen alphanumerischer String dort enthalten ist.

??? Was hat dies mit mehrfachen Hashen zu tun?

 

[Metzlor]

http://www.winhelpline.info/forum/p...pte/81805-batch-cmd-datei-verschluesseln.html

verlinke mal dorthin, dort wurde das gleiche Thema behandelt.
Soll wohl schon ein Tool dafür geben.

 

[ice-breaker]

??? Was hat dies mit mehrfachen Hashen zu tun?

ein 7 stelliges Passwort (Originalpasswort)
ein 32 stelliges Passwort = md5-Hash

fällt nun auf worauf ich hinauswollte?

 

[Yuuri]

fällt nun auf worauf ich hinauswollte?

Nein und anscheinend weißt du nicht, was ein Hash oder eine Rainbow-Table ist. Das Passwort kann 1, 2, 7 oder 5 Mio stellig sein, es kommt trotzdem ein 128 bit großer Hash heraus. Außerdem bringt Security by Obscurity überhaupt gar nichts. Sobald einer mit Brute Force an die Sache geht, ist mehrfaches hashen überhaupt nicht sicherer, "nur weil es in der Rainbow Table steht". Wer außerdem Hashes aus einer Rainbow Table nutzt, dem kann ich sowieso nicht mehr helfen.

verlinke mal dorthin, dort wurde das gleiche Thema behandelt.
Soll wohl schon ein Tool dafür geben.

Ein 16 bit Programm unter einem 64 bit OS bringt nur überhaupt nichts. Desweiteren bezweifle ich, dass das Programm zusätzlich verschlüsselt, denn sonst sind die Passwörter trotz allem plain in der exe vorhanden.

 

[ice-breaker]

Nein und anscheinend weißt du nicht, was ein Hash oder eine Rainbow-Table ist.

hach ja, das Vorurteil des Internets, weil die anderen nicht wissen, mit wem sie es zu tun haben

Das Passwort kann 1, 2, 7 oder 5 Mio stellig sein, es kommt trotzdem ein 128 bit großer Hash heraus.

kompett richtig, hat dein Passwort aber nur 7 Stellen steigt die Wahrscheinlichkeit dieses in einer Rainbow-Tabelle wiederzufinden, hast dein Pw nun jedoch 32 Zeichen (Rehash eines Md5) sind die Chancen astronomisch gering, da keine Rainbowtable in der Lage ist soviele Passwörter zu speichern, immerhin würden wir hier von 28^32 Möglichkeiten sprechen.
Da ein Passwort in der Regel weniger als 32 Zeichen hat ist der Klartextraum des Hashes deutlich geringer, als wenn ich davon ausgehen muss, dass ein 32 Zeichen String (128 Bit md5 als String) der Klartextraum ist.

Außerdem bringt Security by Obscurity überhaupt gar nichts. Sobald einer mit Brute Force an die Sache geht, ist mehrfaches hashen überhaupt nicht sicherer, "nur weil es in der Rainbow Table steht".

Da brauchen wir uns nicht drüber streiten, das stimmt vollkommen.
Nur einzig und allein die Aussage, dass ein Rehash die Sicherheit nicht erhöht war indem Zusammenhang falsch.

 

[Trainmaster]

Bei MD5 bestehe ohnehin Kollisionsgefahr, weshalb ich davon abraten würde, v.a. mehrfaches Hashen. Zudem hat es sich bereits als Standard durchgesetzt, sog. Salts zu verwenden. Diese erhöhen die Sicherheit weitaus mehr als deine Methode und machen Rainbow-Tabellen erst recht unwirtschaftlich und ineffizient.

 

[ice-breaker]

Bei MD5 bestehe ohnehin Kollisionsgefahr, weshalb ich davon abraten würde, v.a. mehrfaches Hashen.

die Kollisionsgefahr ist immernoch sehr gering, bzw. man schafft nur spezielle Hashes zu konstruieren, die den gleichen Wert ergeben, durch Zufall wurden noch keine Kollisionen gefunden.

Zudem hat es sich bereits als Standard durchgesetzt, sog. Salts zu verwenden.

auf jedenfall, aber darum ging es mir nicht. Es mag keine sinnvolle Praktik sein Hashes wieder zu hashen ich wollte nur ausdrücken, dass die Aussage, dass dies keine zusätzliche Sicherheit bietet, eben nicht stimmt, ich habe nicht gesagt, dass man es tun sollte
Würde ich auch nie tun, Salts sind wunderbar und das Problem des Threaderstellers ist sowieso nur ein falscher Ansatz.

 

[kuddlmuddl]

Ist es überhaupt möglich (in einer beliebigen Sprache) das Ziel vom Threadersteller zu erreichen?
Ich dachte immer ein Programm kann keine geheimen Passwörter sicher abgelegt verwenden, da ja der Schlüssel um die "sichere Ablage" zu lesen im Programm vermerkt sein muss - und somit gestohlen werden kann.