Wichtige Daten in .exe's

Jansen

rowisoft schrieb:

Was ändert sich, wenn du nicht die verschlüsselte Datei, sondern die Exe-Datei verschickst? Wo ist der Unterschied?

Dass Exe-Dateien in der Regel deutlich grösser sind als eine Textdatei mit (ggf. verschlüsselten) Zugangsdaten?
Dass man das Programm bei jeder Änderung der Zugangsdaten neu kompilieren muss?
Dass man die Verwaltung der Zugangsdaten nicht ggf. auch dritten überlassen kann?
Dass es ungleich schwerer ist, benutzerspezifisch gestaffelte Zugänge zu ermöglichen?
Dass prinzipiell die Möglichkeit besteht, die Zugangsdaten doch allein anhand der Exe zu knacken, weil sie halt drinstehen?
Usw. usf.

rowisoft schrieb:

Am Besten ist es natürlich, das ganze zu vermeiden, indem man gar keine Passwörter zu irgendwelchen FTP-Servern in der Software speichert.

Ähh ja, genau das sagte Dasd doch!?

yo also ma folgendes:
ich hab keine ftp-daten in meinem projekt drinnen! ich hab lediglich die daten von meiner mysql-db drinnen da ich per mysql++ auf meine datenbank zugreifen muss (ergibt sinn, odda? :D) nyo aber die soll halt auch nich jeder depp rausfinden können. nayo und das pwd zu der ändert sich eigentlich nie und wenn dann würde ich sowieso eine neue version der software rausgeben müssen, die von meinem auto-updater erkannt würde und der sich anschließend die .exe datei ohnehin neu ziehen müsste ... also kommts da auch ziemlich aufs gleiche.
naja das problem bei solchen verschlüsselungen ist halt auch wieder, das diese geknackt werden können also so secure ist das nicht ... aber ich denke das ich das so machen werde ich werd auf jeden fall drüber nachdenken

sonst noch vorschläge (oder anregungen :D)
mfg bw

Jansen

BW schrieb:

ich hab keine ftp-daten in meinem projekt drinnen! ich hab lediglich die daten von meiner mysql-db drinnen

Was für Zugangsdaten das genau sind ist doch generell egal.

und das pwd zu der ändert sich eigentlich nie

Andere berühmte Aussagen: "Computer werden nie mehr als 640kB Speicher brauchen", "Zwei Stellen reichen aus, bis zum Jahr 2000 läuft das Programm ohnehin nicht".

wenn dann würde ich sowieso eine neue version der software rausgeben müssen

Bei extern übermittelten Zugangsdaten eben nicht.

Insgesamt sehe ich bei dem von dir beschriebenen Anwendungsszenario aber überhaupt keinen Sinn für die Geheimhaltung der Zugangsdaten. Wenn jeder User über das Programm Zugang zur DB erhalten soll und dabei alle denselben Account verwenden (was sie ja offenbar tun, oder wolltest du jeden Anwender eine eigene Exe mit seinen speziellen Zugangsdaten compilieren?), dann richte einfach einen entsprechenden Account in MySQL ein, mit den erforderlichen Berechtigungen bzw. Restriktionen. Wenn die DB korrekt gesichert ist spielt es doch keine Rolle, wer darauf zugreift.

Falls du wirklich der Meinung bist, etwas geheimhalten zu müssen, dann denk bitte dran, auch die Datenübertragung zwischen Client und Server/DB zu verschlüsseln. Die erfolgt sonst nämlich im Klartext, einschliesslich der von dir zuvor mühevoll in der Exe verschlüsselten Zugangsdaten.

C++ Forumbot

Dieser Thread wurde von Moderator/in Jansen aus dem Forum Borland C++ Builder (VCL/CLX) in das Forum Rund um die Programmierung verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

interpreter

Ravel schrieb:

Hi,

ich habe rowisofts Lösung noch nicht ausprobiert aber, hiermit findet man das Wort "HALLO" nicht in der *.exe.
AnsiString text;
text = String(char(72))+char(65)+char(76)+char(76)+char(79);
Edit1->Text=text;

Ergibt bestimmt sehr leserlichen Code bei längeren SQL-Statements! ;))

rowisoft

Hi!

Ergibt bestimmt sehr leserlichen Code bei längeren SQL-Statements!

Du brauchst deswegen ja nicht gleich alle SQL-Statements verschlüsseln...

tschüss
Robert

@jansen folgendes: natürlich hat jeder user hier zugriff auf die db aber dieser datenbank-zugriff dient hier lediglich der speicherung von userdaten auf dem server (username/passwort etc.) das heißt der user kann NICHT eigenmächtig in irgendeiner weise auf die db zugreifen - und so soll das auch bleiben
mfg

otze

wie ist es eigentlich bei templates?wie sichtbar is da der code?
müsste es da nich schön viele sprünge geben?

template<char a>
class safe_char{
     string getString{
          return string(a);
     }
};
template<class a,class b>
class safe_string{
    public:
        string getString(){
             return a.getString+b.getString;
        }
};
//in der main
string a=safe_string<char<H>,safe_string<safe_string<char<A>,char<L> >,safe_string<char<L>,char<O> > >;

rowisoft

Hallo!

Dass Exe-Dateien in der Regel deutlich grösser sind als eine Textdatei mit (ggf. verschlüsselten) Zugangsdaten?

Das mag wohl sein. In dem Fall, dass sich die Daten aber mit wirklich großer Wahrscheinlichkeit wirklich nicht ändern, finde ich die Lösung mit den Daten in der Exe-Datei wirklich nicht verkehrt.

Dass man das Programm bei jeder Änderung der Zugangsdaten neu kompilieren muss?

Dito.

Dass man die Verwaltung der Zugangsdaten nicht ggf. auch dritten überlassen kann?

Auch dito. Die Daten ändern sich im Idealfall ja nicht.

Dass es ungleich schwerer ist, benutzerspezifisch gestaffelte Zugänge zu ermöglichen?

Ist aber scheinbar nicht das Problem in diesem Posting

Dass prinzipiell die Möglichkeit besteht, die Zugangsdaten doch allein anhand der Exe zu knacken, weil sie halt drinstehen?

Verstehe ich nicht. Warum sollte ich die Zugangsdaten in einer Exe-Datei leichter knacken können, als in einer externen Datei? In einer extra Datei, weiß ich wo ich suchen muss: In der Datei, die von der Größe her beschränkt ist. In der Exe-Datei habe ich hingegen viel mehr "murks" ringsrum, dass es mir viel schwieriger ergeht, das ganze ausfindig zu machen und dann noch zu knacken.

Vom "Programmieren" her gesehen, mag es sein, dass der Quellcode schöner aussieht, wenn ichs über ne externe Datei mache. Ich bin mir aber sicher, dass die Verschlüsselungsmethoden in der eigenen Exe-Datei um ein vielfaches größer sind, als mittels externer Datei. (siehe SAVE-Links)

Zuletzt muss man wohl auch den wirtschaftlichen Teil sehen... Und in diesem speziellen Fall wird der wahrscheinlich eh so aussehen, dass man ohne großartigen Schutz auskommen wird...

tschüss
Robert

recht haste.
will im prinzip blos net das die db halt von außen geknackt werden kann besonders weil ich mir die nur von nem freund hab stellen lassen und der bringt mich um wenn die db geknackt wird wegen mir. es gibt mir hierbei weniger um irgendwelche anderne vorteile oder update-fragen sondern einfach um datenschutz ...

mfg

Jansen

Solange die Übertragung zwischen Client und Server unverschlüsselt abläuft hast du keinerlei Schutz. Jeder Anwender kann den Netzverkehr des Programmes bzw. seines Rechners mitsniffen und (beim Verbindungsaufbau) die Zugangsdaten im Klartext auslesen. Dasselbe trifft natürlich für die Nutzdaten zu.

will im prinzip blos net das die db halt von außen geknackt werden kann

Das ist zu 99,99% von der Konfiguration der DB bzw. des Servers abhängig, liegt also in der Verantwortung deines Freundes. Vielleicht solltest du dir lieber doch eine eigene DB zulegen, sowas gibt's doch für lau (z.B. www.funpic.de). Das wird zwar die Sicherheit nicht erhöhen aber zumindest verlierst du im schlimmsten Fall nicht deinen besten Freund.

ich hatte bis vor kurzem selber nen server und mein kollege betreibt den schon seit einigen jahren und kennt sich auch sehr gut aus ich denke das der server ziemlich secure ist ...
aber ma was anderes da ich mich damit so gar nich auskenne: wie kann ich verhindern das jeder depp die daten beim übertragen sniffen kann? wie verschlüssel ich sowas am besten? gibts da tuts o.ä. ... hab sowas vorher noch nie gemacht

mfg bw