Passswort sicher in die EXE speichern

[Chrissi91]

Hallo,

wie kann ich ein Passwort und einen Benutzernamen sicher in der EXE speichern?

Die Daten werden schon vor dem Kompilieren angegeben. Ich möchte dann mit den Daten auf meinen FTP - Server zugreifen.

Wie kann ich diese Daten nun relativ sicher in die EXE tun? Gibt es dafür Komponenten?

Ich habe letztens bei den Indy's eine Komponente gesehen, womit man Passwort und Usermname eingeben konnte .... ich dachte, das wäre sowas, aber im editor war das passwort trotzdem ganz deutlich zu sehen.

IdUserPassProvider unter IndySASL

Kennt jemand eine simple Lösung für mein Problem?

[fkerber]

HI!

Ich glaube, ein "sicher" wird es da nicht geben. Du kannst sie evtl. irgendwie verschlüsseln, aber auch dann wird irgendjemand, wenn er ein Interesse an der Sache hat, in der Lage sein, sie wieder zu entschlüsseln. Spätestens nachher bei der Übertragung ins Netz könnte sich einer das Paket abfischen.


Ciao Frederic

[faux]

Das Problem ist, dass die Daten auch irgend wie von dir wieder entschlüsselt werden müssen, und alles was man entschlüsseln kann, kann man somit auch herausfinden.

[ichbins]

Du musst den Hash des Passwortes speichern. Dieser Hash kann nicht entschlüsselt werden. Du kannst dann das eingegebene Passwort mit derselben Mehtode verschlüsseln und schauen ob der dabei herauskommende Hashwert gleich ist wie der gespeicherte. Such einfach mal nach md5 oder rc4.

Alternativ eine eigene (unsichere) Hash-Lösung:

Delphi-Quellcode:

function xorhash(password:string):string;
var
  i:integer;
begin
  result:='';
  for i:=1 to length(password) do 
    result:=result+char(byte(password[length(password)+1-i]) xor byte(password[i]));
end;

[faux]

Bitte baue mal eine Verbindung zu nem FTP-Server auf, dessen Passwort du nur in Hash-Form verfügbar hast.... :roll:

[ichbins]

Ich meinte der User solle es ja eingeben. Sonst wäre es ja unmöglich. Was die EXE aus sich selbst auslesen kann, kann man auch so auslesen.

[AndreasP]

mahlzeit,

eine möglichkeit wäre das du das passwort erst wenn du es brauchst zusammen setzt. eine sehr einfache variante wäre

Delphi-Quellcode:

Pass := Teil1 + Teil2 + Teil3;

oder du machst das ganze zeichenweise:

Delphi-Quellcode:

Pass := #65#85#75#43

natürlich kannst du auch normale stringmanipulation(copy, replace...)oder kombinationen verwenden um das passwort zu erstellen. und wenn du das ganze auch noch über mehre prozeuren/funktionen verteilst, tendiert die warscheinlichkeit das jemand dass passwort aus der exe ausließt gegen null. du mußt aber entscheiden ob sich der aufwand lohnt, denn solange du kein ssl oder ssh verwendest um mit dem ftp-server zu reden sei auf programme wie etheral hingewiesen.

[Chrissi91]

danke ... wie sieht das denn mit ssl aus ... bei den indys ist doch auch irgendne ssl kompo dabei ,oder?

[MrKnogge]

@IchBins
Was Chrissi91 möchte, ist, dass sein Programm auf den FTP zugreift und dann beispielsweise eine Datei auswertet um den User anzuzeigen ob updates zur Verfügung liegen, oder beispielsweise die analyse unseres Surf-Verhaltens hochladen :mrgreen:

Der Endbenutzer kann und darf die Benutzerdaten natürlich nicht wissen.

@Chrissi91
SSL ist eine geschützte Verbindung , die dein Server ebenfalls unterstützen müsste, dies hat aber nichts mit FTP zu tun, oder wolltest du deine Verbindungsdaten über die SLL-Verbindung abrufen ?
- Dann rate mal was du für eine SSL-Verbindung brauchst :stupid:

Die Variante von AndreasP ist recht gut, du kannst ja noch ein bisschen daran feilen, beispielsweise

Delphi-Quellcode:

a := ord('a');
a := a*2;
pass := #65#85#75+Chr(a);

gruss

[ichbins]

aber er kann sie hacken. das ist absolut unbestreitbar. das prog könnte vielleicht den hash speichern und dann mit brute-force selbst das passwort bestimmen :mrgreen:

der User könnte z.B. auch eine eigene Firewall schreiben, die alle gesendeten Daten abfängt. Es ist also unmöglich.

Eine weitere Möglichkeit: Das Prog schickt Daten [eMails :?:] an einen bestimmten Rechner, der diese dann verarbeitet (z.B. die Daten auf dem Server ändert) und als einziger das Kennwort kennt.

[fkerber]

Hi!

@AndreasP:
Aber mit etwas Geduld und Erfahrung ist auch das ganz schnell geknackt.

Ciao Frederic

[Chrissi91]

ich werde dann mal das mit verscidenen teilen des passwortes machen oder eben mit dem:

Pass := #65#85#75#43

ich nehme an das sind irgendwelche zeichen (ich rate mal: ascii) ... wenn nein, bräuchte ich den namen, damit ich mal solch eine seite im internet suchen kann ... dafür gibt es sicherlich tabellen

[fkerber]

Hi!

Jepp, das sind Ascii-Codes und heißt
AUK+

Ciao Frederic

[Chrissi91]

Also muss ich mich nach einer Tabelle, wie dieser hier richten: http://www.manderby.com/mandalex/a/ascii.php

Muss ich die Dec - Werte benutzen, ja, oder?

[fkerber]

Hi!

Ja nach so einer Tabelle mit den Dec-Werten.


Ciao Frederic

[Chewie]

Öööhm, Leute, ob er jetzt so schreibt:

Delphi-Quellcode:

str = #116#101#115#116;

oder so:

Delphi-Quellcode:

str = 'test';

macht im Kompilat exakt nichts aus. So kannst du höchstens den Quellcode verschlüsseln :roll:

[himitsu]

Ich würde auch noch einen anderen Weg vorschlagen, wenn dein Server z.B. über PHP verfügt.

Lege doch einfach ein Script auf dem Server ab, welches den Zugriff auf den Server vornimmt, dann bräuchtest du die FTP-Zugangsdaten garnicht in einem Programm einbinden und hättest sogar die möglichkeit mal diese Daten zu ändern, ohne daß danach deine Programme nicht mehr funktionieren :angel:

Notfalls kann dein Programm aber auch die aktuellen Zugangsdaten über ein Script abfragen, aber dann wäre es ja auch wieder möglich die FTP-Daten zu erfahren, da man ja nur selber mal dieses Script befragen muß ... also ist die erste Variante die wohl sichere Methode ^^

[add]
Also 2 Programme:
eine um die Daten zu verschlüsseln und das Verschlüssele dann in den Quellcode des entsprechenden eintragen, dann dieses compilieren.
Und im zweiten (dem eigentlichen Programm) dann das wieder entschlüsseln

Programm 1:

Delphi-Quellcode:

Edit1: TEdit; // Passwort
Edit2: TEdit; // verschlüsseltes Passwort

Edit2.Text := Verschlüsseln(Edit1.Text);

Programm 2 (das eigentliche Programm):

Delphi-Quellcode:

Passwort := Entschlüsseln('verschlüsseltes Passwort');

[add2]
Chewie hat schon recht, die bisherigen Vorschläge sind wohl nicht so sinnvoll gewesen, denn wenn du die Zugangsdaten schon direkt in deiner EXE haben möchtest, dann mußt du diese schon in verschlüsselter Form in den Quellcode eintragen und dieses dann bei der Ausführung entschlüsseln.

[Chrissi91]

mal schaun, wie lange ihr braucht, es rauszufinden ...

[Chrissi91]

gut ... kann es denn ohost oder funpic? außerdem weiß ich über php nichts ...

[himitsu]

funpic kann dat aufjedenfall (hab da ja selber noch 'nen Account)

Und notfalls kann dir beim PHP ja auch bestimmt jemand helfen.

Wobei bei funpic sogar die erste Methode möglich wäre ... die Dateien haben ja eine Größenbegrenzung, vobei man da also ganz einfach per PHP-Upload die Dateien hochladen kann. (pracktisch die selbe Methode wie hier im Forum die Dateien hochgeladen werden ... du brauchst ja auch keine Zugangsdaten um die Dateien anzuhängen)

[Chrissi91]

ich freu mich über die vorschläge, aber ich verstehe nicht, was du genau meinst ... ;)

[Neotracer64]

Zum Crackme:

"tRoTTeL)" ohne "

EDIT: 2 min

[Chrissi91]

mist ... :wall:

[himitsu]

Wie gesagt, du mußt die Daten schon zumindestens in verschlüsselter Form in die EXE einbinden und selbst dieses Verschlüsselte könntem an unter Umständen noch leicht wieder entschlüsseln ^^nur für den QuellCode verschlüsselt reicht halt nicht aus, wie Chewie schon bemerkte, da ja z.B. #116#101#115#116 und 'test' nach dem Kompilieren auf das Selbe hinauskommt.

Wie gesagt, am sichersten ist es halt, wenn nirgendwo mit den FTP-Zugangsdaten gearbeitet wird, dann kann da natürlich auch keiner rankommen ;)

[tommie-lie]

Ihr wisst aber, daß FTP das Passwörter eh unverschlüsselt übertragen werden und jemand, der die Echse analysiert um nachzuschauen, ob er das Passwort unverschlüsselt darin findet, vorher das Passwort schon lange in seinem Netzwerksniffer abgegriffen hat?

Zitat:

Zitat von himitsu

Notfalls kann dein Programm aber auch die aktuellen Zugangsdaten über ein Script abfragen

Ja, übertragen wir das Passwort gleich zweimal ungeschützt über's Netzwerk!

[Neotracer64]

Er meint ein PHP-Script, dass sich auf einem Server befindet. Und es einem nur erlaubt Bilder hochzuladen.

[himitsu]

Zitat:

Zitat von tommie-lie

Ja, übertragen wir das Passwort gleich zweimal ungeschützt über's Netzwerk!

Na ja, wenigstens isses dann ja nich in der EXE drin für die Überpragung vom Script zum Programm könnte man es ja auch verschlüsseln :zwinker: (aber wenigstens isses da dann nicht in der EXE mit drin und er könnte halt norfalls die Zugangsdaten abundzu mal ändern)

Aber darum hab ich ja auch dafür plädiert diese Daten nirgendwo zu verwenden ;)


@Neotracer6: Tommie meinte meinen zweiten Vorschlag, also die Zugangsdaten von einem Script zu erfragen

[Neotracer64]

Ups, achso. Na dann finde ich den ersten doch besser. :)

[Chrissi91]

Also ehrlich: Ich verstehe nichts mehr! Was soll ich denn nun machen? Und vor allem wie? Ich will ja nur txt oder ini files mit ein paar kb hochladen ... Ist das denn so schwer? :wall:

[negaH]

Es ist defacto unmöglich.

Um eine Datenübertragung von A nach B wirklich sicher hinzubekommen müssen A wie auch B einbruchsicher sein. Angenommen B ist ein Server dann ist dies relativ einfach zu bewerkstelligen, wenn wir mal nur die Datenübertragung über ein unsicheres Netzwerk betrachten (also keine Einbrecher oder böswillige Mitarbeiter).

Bei A wird es nun schwieriger. Ist es ein Mensch der sein Passwort im Kopf speichert und ein sehr gutes Passwort gewählöt hat so können wir davon ausgehen das dies einbruchsicher ist.

Ist A aber nur deine eigene Software dann wirst du es niemals sicher hinbekommen wenn die Plattform auf dem deine Software A nicht sicher ist. D.h. wir benötigen ein einbruchsicheres Betriebssystem samt einbruchsicherem Hardware Kernel. Microsoft nennt dies in seinem Palladium den Nexus.

Eine Alternative wäre ein intelligentes Hardware Dongle. Dies funktioniert aber nur dann wenn der Server B direkt mit dem Dongle A deiner Sofwtare die Daten austauschen kann.

Jede andere Lösung wird immer darauf hinauslaufen das du mit Programmiertechnsichen Tricks versuchst es dem "Angreifer" schwerer zu machen. Dies führt zu zwei wesentlichen Konsequenzen:
1.) du musst schlauer sein als eine rießige Gruppe von Angreifern die sich heutzutage sogar sehr gut organisiert haben
2.) du musst mehr Aufwand treiben in deinen Programmeirtechnischen Tricks als der Aufwand der auf Angreiferseite nötig wäre. Sprich die Angreiferseite kannst du als hochtechnisiert betrachten mit entsprechenden Tools.

Ich rate dir also folgendes:
Statt das Passwort in der EXE zu speichern müssen sich die Benutzer deiner Software bei dir registrieren. Du hast damit schonmal die Grundlage geschaffen das jeder Benutzer individuelle Zugangspasswörter bekommt, statt für alle Benutzer das gleiche Passwort zu benutzen. Desweiteren hast du damit einen Service-Vorteil errungen, du musst es nur als solchen verkaufen können. Technologisch ist es nun ein einfaches "illegales" Verhalten deiner Benutzer zu beobachten und entsprechend mit einer Zugangssperre auf den Server darauf zu reagieren.

Du verlagerst also immer mehr Software Funktionen weg von der Client-Software hin auf Server Seite den du ja unter Kontrolle hast. Du schaffst damit die technischen Voraussetzungen deine Benutzer überwachen zu können. Dies kann sogar unter Umständen zusätzliche Geld einbringen.

Man dürfte aus den letzten Sätzen sehr gut schon im WEB bestehende Konzepte wiedererkennen. Zb. Microsofts-Update Philosophie entspricht exakt diesem Konzept.

Gruß Hagen

[Chrissi91]

Und wie funktioniert das dann mit Seriennummern bei z.B. Microsoftanwendungen? Dort ist doch auch die Seriennummer in der EXE gespeichert ..., oder? Ich möchte ja kein unknackbares System haben ... E muss noch nicht mal so sicher wie Seriennummern bei Programmen ... Nur eben, dass nicht jeder es rausbekommt ...

[Tubos]

Wie schon gesagt, sobald die FTP-Verbindung hergestellt wird kann jeder ganz einfach dein Passwort herausfinden. Sogar ich ;)
Lösung ist ein PHP Script das den Upload übernimmt.

Ich empfehle dir die Grundlagen von PHP zu lernen - es ist eine relativ einfache Sprache. Man muss nur aufpassen durch unvorsichtige Programmierung keine Sicherheitslecks zu öffnen.

[himitsu]

Im Grunde genommen muß halt nur die Dateiendung geprüft werden, so daß man nur Dateien mit bestimmte Dateiendungen hochladen kann.

[MrKnogge]

Zitat:

Zitat von Chrissi91

Und wie funktioniert das dann mit Seriennummern bei z.B. Microsoftanwendungen? Dort ist doch auch die Seriennummer in der EXE gespeichert ..., oder?

Nein, sonst wären ja alle Seriennummern gleich, die eingegebene Seriennummer wird durch diverse Algorithmen auf Richtigkeit überprüft.

gruss

[Chrissi91]

ja ... naja: ein beispiel:

wenn ich meine wohnungstür auf lasse, kommt jeder einbrecher, auch wenn er gar keiner ist, rein.

wenn ich sie abschleiße, ist es für einen profi genauso schwer, wie wenn ich die wohnungstür abschließe und den schlüssel stecken lasse.

ein profi kommt immer ran ...

dasselbe mit dem passwort für ftp ... es soll nicht im klartext drinstehen ...aber ein wenig verschlüsselt sein ...

[negaH]

Du verstehst nicht. Beim FTP braucht ein Angreifer nicht deine Anwendung zu analysieren, er muß noch nichtmal deine Software besitzen geschweige denn Zugriff auf den Rechner haben auf dem deine Software ein FTP durchführt. Er muß nur die ersten Datenpackete zwischen deiner FTP Anwendung zum FTP Server abfangen, denn darin steht unverschlüsselt als direkt lesbarer Text der FTP Benutzername und dessen Passwort.

Es gibt aber sogannante FTPS Server, ein abgewandeltetes FTP mit SSL Schlüsselaustausch.

In deinem Falle benötigt ein Anwender im Bestcase seinen PC, deine Software und einen TCP/IP Packet Sniffer (die es wie Sand am Meer als Freeware gibt). Er startet seinen Sniffer der ausgehende Verbindungen zum Port 21 überwacht. Er startet deine Anwendung, baut damit ein FTP auf und schon hat er dein Passwort+Benutzernamen im Sniffer im ersten FTP Packet lesbar vorsich. Alles in allem benötigt er länger mit der Installation deiner Software als deine Anwendung zu knacken, er benötigt mehr Zeit um sein WindowsXP hochzufahren, er muß länger auf eine Tasse Kaffee warten, er wird mehr Zeit benötigen seine Freunde mit deinem Passwort zu versorgen als es zu knacken. Er wird wahrscheinlich mehr Zeit damit verbrauchen deinen FTP Server zu cleanen und temporär illegale Dateien über deinen FTP Server mit seinen Freunden auszutauschen.

Und bei all dem kannst du Monate damit verplempern dein Passwort in der EXE mit allen möglichen Tricks zu verstecken, zu verschlüsseln und weis Gott noch was.

>> ein profi kommt immer ran ...

Nein eben nicht. Bei wirklich sicher konstruierten Systemen haben die Experten diese so konstruiert das sie basierend auf der heutigen Technologie per mathematischer Interpolation exakt beweisen können das der Angreifer mehrere Milliarden Jahre benötigte um das System zu knacken. Das einzigste was diese Experten nicht vorausberechnen können ist die Frage nach den zukünftigen mathematischen Entdeckungen in zb. 100 Jahren. Sie können aber mit an Sicherheit grenzender Wahrscheinlichkeit Systeme konstruieren die niemand heute in den nächsten 20-50 Jahren knacken wird. Es ist also so das man sehr wohl praktisch unknackbare Systeme konstruieren kann und defacto auch schon längst benutzt.

Man kann also Profi sein wie man will, man müsste schon ein super genialer Profi sein. Tja, der würde aber ziemlich schnell auf der anderen Seite für viel Geld arbeiten ;)

Es ist also ein sehr weites Feld was wir als Normalos als "sicher" empfinden. Wenn du wie du sagst das du ein Passwort in deiner EXE verstecken möchtest dann ist dies eben beiweitem nicht sicher, sondern absolut unsicher !

Gruß Hagen

[faux]

Zitat:

Zitat von Neotracer64

Zum Crackme:

"tRoTTeL)" ohne "

EDIT: 2 min

Und User ist "suppi ..."
oder umgekehrt.

[Chrissi91]

Das sollte eigentlich nur eine Meldung sein ;)

Zitat:

Zitat von negaH

Nein eben nicht. Bei wirklich sicher konstruierten Systemen haben die Experten diese so konstruiert das sie basierend auf der heutigen Technologie per mathematischer Interpolation exakt beweisen können das der Angreifer mehrere Milliarden Jahre benötigte um das System zu knacken. Das einzigste was diese Experten nicht vorausberechnen können ist die Frage nach den zukünftigen mathematischen Entdeckungen in zb. 100 Jahren. Sie können aber mit an Sicherheit grenzender Wahrscheinlichkeit Systeme konstruieren die niemand heute in den nächsten 20-50 Jahren knacken wird. Es ist also so das man sehr wohl praktisch unknackbare Systeme konstruieren kann und defacto auch schon längst benutzt.

Die Chance besteht doch aber immer, durch Zufall, den Code einzutippen, auch wenn die Wahrscheinlichkeit gleich null sein wird ...

Aber nun gut ... Ich habe es verstanden ...

[negaH]

Zitat:

Die Chance besteht doch aber immer, durch Zufall, den Code einzutippen, auch wenn die Wahrscheinlichkeit gleich null sein wird ...

Sicher doch. Man muß aber immer präzise sein. Die Wahrscheinlichkeit durch Zufall einen sicheren Schlüssel zu finden beträgt 1/2^Schlüssellänge in Bits. Mit heutiger propagierter Schlüssellänge von größer 128 Bit beträgt die Wahrscheinlichkeit also nicht 0 oder annähernd 0 sondern exakt 1/2^128, was unendlich größer als NULL-Wahrscheinlichkeit ist.

Da es eber immer noch diese sehr geringe Wahrscheinlichkeit gibt versucht man zwei Strategien anzuwenden
1.) die Schlüssel werden in ihrer Lebenszeit begrenzt, zb. auf maximal 1 Jahr
2.) man verteilt viele unterschiedliche Schlüssel statt immer die gleichen zu benutzen

Beides schafft selbst mit relativ "unsicheren" Systemen eine erhöhte Sicherheit, quasi einen zeitlichen Vorsprung.

Gruß Hagen

[Chrissi91]

Mit anderen Worten ist es für einen wie mich fast unmöglich zu programmieren ;)