In den Resourcen steht die dfm also auch Passwörter?

[Yakumo500]

Hallo,

In Delphi werden die dfm Dateien ja als Resource in eine Exe eingebunden. Aber wie steht es mit der Sicherheit? Man könnte doch einfach mit ResourceHacker die Datei untersuchen und dann z.B. Passwörter, die in Komponenten eingegeben wurden, auslesen? Gibt es dagegen keinen Schutz?

[lbccaleb]

Verschlüsselung?

[Yakumo500]

Gibts irgendeine Einstellung in Delphi mit der man das erreichen kann?

[Matze]

Hallo,

sämtliche Passwörter, die du in die Exe integrierst, sei es mit Delphi, C++ oder anderen Programmen, kann man auslesen, wenn man weiß wie. Manchmal reicht es dafür, die Exe mit einem Hex-Editor zu öffnen, manchmal ist die Überwachung des RAMs oder ein Disassemblieren erforderlich.
Hundertprozentige Sicherheit gibt es da nicht, da deine Exe das Passwort im Klartext kennt. Und wenn es verschlüsselt wäre und die Exe das Passwort selbst entschlüsseln kann, dann bringt das genauso wenig (das Passwort steht nach dem Entschlüsseln bsp. im Klartext im RAM).

Worum geht es dir denn genau?

Vielleicht lässt sich das Problem anders lösen. Statt bsp. FTP-Zugangsdaten in die Exe zu integrieren, könnte sich das Einrichten eines separaten FTP-Users mit entsprechenden Rechten (ohne Passwort) anbieten. Oder der Weg über PHP. Dann wären die Zugangsdaten in PHP-Dateien hinterlegt, die keiner auslesen kann und PHP sorgt für die Übertragung der Daten.

Grüße, Matze

[Yakumo500]

Naja es hat mich einfach nur mal interessiert. Wahrscheinlich werde ich in Zukunft den Komponenten die Passwörter im Quellcode zuweisen. Ich meine es ist immernoch einfacher mit ResourceHacker die dfm zu durchsuchen als z.B. mit Cheat Engine den Speicher zu scannen.

Vielen Dank für eure Antworten.

[Christian Seehase]

Moin,

Zitat:

Zitat von Yakumo500

Wahrscheinlich werde ich in Zukunft den Komponenten die Passwörter im Quellcode zuweisen.

Alle Texte, die im Klartext im Sourcecode stehen, stehen, i.d.R., auch in der Exe im Klartext.
Da reicht Notepad.

[fkerber]

Hi!

Zitat:

Zitat von Yakumo500

Ich meine es ist immernoch einfacher mit ResourceHacker die dfm zu durchsuchen als [...]

Du gibst doch die dfm gar nicht raus - das wird ja alles in die Exe integriert.
Vllt. wären one-way-Verschlüsselungen (z.B. MD5) was für dich?


Grüße, Frederic

[hoika]

Hallo,

Zitat:

Du gibst doch die dfm gar nicht raus - das wird ja alles in die Exe integriert.

Die DFM's sind als Resource eingebunden,
deswegen der Spruch mit dem ResourceHacker.

Wie schon richtig gesagt,
hilft da nur Verschlüsselung.


Heiko

[Matze]

Zitat:

Zitat von hoika

Wie schon richtig gesagt,
hilft da nur Verschlüsselung.

Aber auch nur, wenn das zum Entschlüsseln erforderliche Passwort vom Benutzer eingegeben wird, oder? Und selbst dann wäre es Unsinn, da der Anwender das Passwort ja kennt.
Sonst kann man das Entschlüsselte doch ebenfalls problemlos auslesen, wie ich bereits geschrieben habe, oder nicht?

Ich bin der Meinung, dass man in dem Fall natürlich versuchen kann, das Passwort zu verstecken, aber wirklich verhindern lässt sich das Auslesen nicht, wenn das Passwort in die Exe integriert ist.

Grüße, Matze

Edit: Das von Frederic angesprochene Hash-Verfahren ist natürlich was anderes. Da hat man jedoch das Passwort nie zur Verfügung, lediglich einen Hash, mit dem man einen anderen Hash bsp. vergleichen kann.

[hoika]

Hallo,

Zitat:

Sonst kann man das Entschlüsselte doch ebenfalls problemlos auslesen

Wenn das so waäre, sind also Verschlüsselungsverfahren völlig überflüssig,
weil das Passwort ausgelesen werden kann ?


Heiko

[Sir Rufo]

Zitat:

Zitat von Yakumo500

Naja es hat mich einfach nur mal interessiert. Wahrscheinlich werde ich in Zukunft den Komponenten die Passwörter im Quellcode zuweisen. Ich meine es ist immernoch einfacher mit ResourceHacker die dfm zu durchsuchen als z.B. mit Cheat Engine den Speicher zu scannen.

Vielen Dank für eure Antworten.

Nur um den Schein zu wahren, speicher ich die Passwörter (und sonstige Zugangsdaten) immer getrennt von der exe-Datei (z.B. in einer ini-Datei).

Vorteile:
- kann nicht einfach so ausgelesen werden
- Änderungen bei den Zugangsdaten erfordern keine neue Compilierung

Für die Speicherung der Werte habe ich mich ein wenig von der Firma LANCOM inspirieren lassen.
In den Config-Dateien (sind ini-Dateien) werden die Passwörter auch verschlüsselt gespeichert.
Es ist aber auch möglich, das Passwort in der Config-Datei im Klartext zu schreiben.
Beim ersten Zugriff auf die Config-Datei wird der Wert dann aber automatisch verschlüsselt.
Die Erkennung, ob der jeweilige Eintrag verschlüsselt ist, erfolgt über ein doppeltes = Zeichen

Unverschlüsselt

Code:

[Section]
Ident1=Geheim

Verschlüsselt

Code:

[Section]
Ident1==ft6tz7

Das ist keine Hochsicherheitslösung, weil ja alle Teile zum Ver- und Entschlüsseln vorliegen, reicht aber
um solche Kennwörter vor neugierigen Benutzern zu verstecken :mrgreen:

[Reinhard Kern]

Zitat:

Zitat von Yakumo500

Hallo,

In Delphi werden die dfm Dateien ja als Resource in eine Exe eingebunden. Aber wie steht es mit der Sicherheit? Man könnte doch einfach mit ResourceHacker die Datei untersuchen und dann z.B. Passwörter, die in Komponenten eingegeben wurden, auslesen? Gibt es dagegen keinen Schutz?

Hallo,

ehrlich gesagt, ich verstehe das ganze Problem nicht - Passwörter haben doch in der Exe nichts verloren, und auch nicht im Quelltext, schliesslich müssen sie ja nicht nur geheim, sondern auch leicht änderbar sein. Was machst du denn, wenn du 10 Kunden hast, deren Datenbank-Admin monatlichen Passwortwechsel vorschreibt: 120 mal im Jahr eine neue Exe versenden? Und in 99 % der Fälle kannst/darfst du das Passwort doch überhaupt nicht wissen?

Irgendwie muss das ein Anwendungsfall sein, der mir noch nie begegnet ist, bitte um Aufklärung.

Gruss Reinhard

[Matze]

Zitat:

Zitat von hoika

Wenn das so waäre, sind also Verschlüsselungsverfahren völlig überflüssig,
weil das Passwort ausgelesen werden kann ?

Nein, so kannst du das nicht sagen. Wenn alles zum Entschlüsseln erforderliche in die Exe integriert ist, kommt man normalerweise an die Daten ran. Erfolgt die Verschlüsselung so, dass der Anwender ein (geheimes) Passwort zum Entschlüsseln eingeben muss (Zip-Archive, ...), dann ist das Ganze nicht der Fall.
Oder das angesprochene Hashing:
Da ist der Hash bekannt und beim Einloggen eines Benutzers wird aus dessen Kennwort der Hash generiert und mit dem vorliegenden Hash verglichen. Wobei das nur eine Einweg-Verschlüsselung ist.

Wenn die Exe aber selbst in der Lage ist, die verschlüsselten Dateien zu entschlüsseln, dann bin ich der Meinung, dass das unsicher ist. Wo sollte denn da die Sicherheit liegen? Die Exe kennt das Kennwort und spätestens wenn sie was entschlüsselt, wird das Entschlüsselte irgendwo abgelegt, wo man es auslesen kann.
Wenn du mir das vernünftig begründen kannst, glaube ich es evtl. sonst nicht.

Aber wie Reinhard angesprochen hat und ich auch weiter oben, wäre es interessant zu wissen, worum es hier genau geht. Oft gibt es andere, bessere Lösungen, wenn man etwas wirklich sicher machen möchte. Geht es nur ums Erschweren zum Auslesen von Dingen, dann ist das so in Ordnung.

[himitsu]

@Sir Rufo: Das ist sogar noch etwas unsicherer.

Wenn der geheime Text (hier dein Passwort) in der EXE steht, dann muß man es dort ertstmal suchen und dann noch entschlüsseln.
Wenn es aber in einer kleineren externen Datei steckt, dann hat man den Text schonmal und muß nur noch rausfinden, wie er verschlüsselt ist.


Wie schon gesagt wurde:
gegen unerfahrenere Hacker und vollkommen unwissende hilft es schon, wenn die Daten irgendwo (in EXE, INI oder sonstwo) irgendwie verschlüsselt rumliegen,
selbst wenn die EXE weiß, wie man es entschlüsselt.

Sobald es sicherer sein soll, dann muß irgendetwas davon ... z.B. das Paswort der Entschlüsselung, das Entschlüsselungsverfahren ... weit weg von dem Benutzer, in einer "sicheren" Umgebung (z.B. auf dem eigenem Server) liegen und auch noch der Übertragungsweg muß sicher sein.

Wenn der böse Bube aber an alles rankommt (verschlüsselte Daten, Passwort und Entschlüsselungsverfahren), dann kann er sich die Daten selber entschlüsseln ... ebenso muß dan sichergestellt werden, daß er auch nicht wichtige Daten irgendwo/irgendwann im Klartext auslesen kann.

[Sir Rufo]

Zitat:

Zitat von Sir Rufo

Nur um den Schein zu wahren, speicher ich die Passwörter (und sonstige Zugangsdaten) immer getrennt von der exe-Datei (z.B. in einer ini-Datei).

Das dieses Verfahren nicht wirklich sicher ist, ist mir durchaus bewusst und habe ich auch so vermerkt.

Es gibt aber Situationen, wo ein solches Verfahren unumgänglich ist, ohne den Benutzer unnötig zu gängeln.

Natürlich sollte man sich immer überlegen, welches Loch man sich im Fall der Fälle damit reißt.
Bei einer geschlossenen und überschaubaren Menge an Benutzern (firmenintern),
wo Daten auf einem internen ftp-Server hochgeladen werden sollen,
der ftp-User nur Berechtigungen (aber halt schreibend) für ein Austausch-Verzeichnis hat,
ist dieses Verfahren aber m.E. durchaus zulässig.

[sx2008]

Folgende kleine Verschleierungstaktik sollte ausreichen um Spielkinder fernzuhalten:

Delphi-Quellcode:

function TForm1.GetPasswort:string;
const
  c5:char = 'i';
  muell1:char = '@';
  c2:char = 'e';
  muell2:char = #2;
  muell3:char = #210;
  c1:char = 'g';
  muell4:char = #13;
  c3:char = 'h';
  muell5:char = '0';
  c4:char = 'e';
  c6:char = 'm';
begin
  result := c1+c2+c3+c4+c5+c6;
end;

[himitsu]

Den "Müll" kannst'e weglassen, da er nirgends verwendet und demnach eh nicht einkompiliert wird.

[fkerber]

Hi!

Funktioniert eine solche Verschleierungstaktik wirklich?
Ich hätte gedacht, dass der Compiler solche Scherze gleich wegoptimiert?


Grüße, Frederic

[himitsu]

theoretisch optimiert er es weg

bei echten Konstanten kürzt der Compiler es zusammen

Delphi-Quellcode:

function TForm1.GetPasswort:string;
const
  c5 = 'i';
  c2 = 'e';
  c1 = 'g';
  c3 = 'h';
  c4 = 'e';
  c6 = 'm';
begin
  result := c1+c2+c3+c4+c5+c6;
end;

und macht das draus.

Delphi-Quellcode:

function TForm1.GetPasswort:string;
begin
  result := 'geheim';
end;

Aber typisierte Konstanten sind eher mit Variablen zu vergleichen und bei Variablen kann nicht gekürzt werden

Delphi-Quellcode:

function TForm1.GetPasswort:string;
const
  c5:char = 'i';
  c2:char = 'e';
  c1:char = 'g';
  c3:char = 'h';
  c4:char = 'e';
  c6:char = 'm';
begin
  result := c1+c2+c3+c4+c5+c6;
end;