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

[Sir Rufo]

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

[Reinhard Kern]

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