Verbindungsdaten verstecken

[Privateer3000]

Hallöchen,
ich hab mal eine allgemeine Frage.
Um die Verbindungsdaten zu einer DB nicht
in einer Textdatei jedermann zugänglich zu machen
welche Möglichkeiten gibt es da?
Jedenfalls sollte es möglichst schwer sein
an die Daten heran zu kommen...

Grüße

[himitsu]

Es ist naturbedingt praktisch unmöglich etwas zu verstecken,
da jeder erstmal an die EXE direkt rankommt, diese debuggen und auf ihren Arbeitsspeicher zugreifen kann. (nötige Rechte vorausgesetzt ... z.B. ein billige Userprogramm kommt nicht so einfach an ein Programm mit hoheren Rechten ran)

Spätestens wenn das Programm eine Verbindung zur DB aufnehmen will, muß es diese Daten lesbar zur Verfügung stellen und schon kommt jeder da ran.



Du kannst gerne jede Menge in Richtung Verschlüsselung, Verschleierung (zwischen vielen Daten verstecken), Antidebugging, Antihacking uvm. unternehmen, aber am Ende kommt man immer daran.



Wenn's nur nicht direkt lesbar in der EXE stehen soll, dann verschlüssle diese Daten schon im Quelltext, aber sowas wie

Delphi-Quellcode:

#$48#97#$6C + chr(108) + 'o'

kannst'e gleich vergessen, denn da steht ebefalls wieder 'Hallo' in der EXE :lol:

z.B. vohrer per XOR verschlüsseln, in den Quellcode kopieren und bei Übergabe an die DB-Komponente entschlüsseln.

[Furtbichler]

Wenn Du ein bischen sicherer sein willst, als die offene Tür, dann verschlüssele die Text-Datei.

Wenn Du die Tür abschließen willst, dann z.b. über einen Server, der die Entschlüsselung erledigt. Na ja, dann kommen sie über die Fenster.

Ich bin ja Laie, aber ich glaube, Du musst die Sicherheit in den DB-Server verlagern, z.b. über Useraccounts oder AD.

[Privateer3000]

Danke für Eure Aussagen.
Das ist mir klar dass nichts wirklich sicher ist.
Ich sagte ja auch "möglichst schwer" machen.
Ich dachte da vllt. an eine (binäre?) unauffällige Datei
die im verzeichnis rumlungert.
Es muss halt editierbar sein, da man die Verbindungsdaten
auch mal ändert. Natürlich mit entsprechener Berechtigung (Anwender/Admin).

[Bummi]

ein verschlüsselter Alternative Data Stream (solange es NTFS noch gibt) ...

[Luckie]

Auch nicht sicherer als eine verschlüsselte Datei. Wenn da jemand wirklich dran will, dann findet er das auch. Hier stellt sich auch die Frage vor wem es sicher sein soll. Vor einem "professionellen" Angreifer oder einfach nur vor Oma Erna.

[MrSpock]

Ich schütze meine DB Zugriffe nur gegen Oma Erna und ihre Freundin. :mrgreen: Dazu schreibe ich den UserNamen und das Password verschlüsselt in eine Ini-Datei und entschlüssele die Daten im Programm, um die Verbindung herzustellen.

[Privateer3000]

Zitat:

Zitat von MrSpock (Beitrag 1192532)

Ich schütze meine DB Zugriffe nur gegen Oma Erna und ihre Freundin. :mrgreen: Dazu schreibe ich den UserNamen und das Password verschlüsselt in eine Ini-Datei und entschlüssele die Daten im Programm, um die Verbindung herzustellen.

Genau Spocki
das sollte im allg. reichen.
So werde ich es machen.

Dank an alle für Eure Meinungen!
Grüße

[p80286]

Zitat:

Zitat von Bummi (Beitrag 1192497)

ein verschlüsselter Alternative Data Stream (solange es NTFS noch gibt) ...

die Idee hat was, und dann gab es noch den Admin, der die Daten auf einem (FAT)USB-Stick sicherte und sich nach einer Rückkopie fragte, wo die Daten geblieben waren.

Gruß
K-H

[himitsu]

Egal. Das ist wie als wenn die Daten in der Registry oder irgendwo in einem anderem Verzeichnis lagen ... die wären auch weg, wenn man so unprofessionelle Datensicherungen macht.

[joachimd]

Zitat:

Zitat von Privateer3000 (Beitrag 1192482)

Um die Verbindungsdaten zu einer DB nicht
in einer Textdatei jedermann zugänglich zu machen
welche Möglichkeiten gibt es da?

Dazu gab es mal in im Usenet einen netten Beitrag (ich glaube von Marian Aldenhövel): pack die Daten unverschlüsselt in die readme - die liest sowieso keiner.

[Morphie]

Um welche DB geht es denn genau?
Firebird z.B. übermittelt Username und Password sogar im Klartext... Es kann also mit jedem x-beliebigen Sniffer mitgelesen werden.
Das kann Oma Erna natürlich nicht, aber jeder der ein Passwort umgehen muss, kriegt das so leicht hin...
Da kann im Programm noch so viel verschlüsselt werden, das Firebird-Protokoll ist hier die Schwachstelle.

Btw. wäre mal interessant zu wissen, ob das bei anderen RDBMS genau so ist.

[mjustin]

Zitat:

Zitat von Morphie (Beitrag 1192568)

Um welche DB geht es denn genau?
Firebird z.B. übermittelt Username und Password sogar im Klartext... Es kann also mit jedem x-beliebigen Sniffer mitgelesen werden.

Laut diesem Post gibt es schon seit Firebird 1.5 Password Hashes anstatt eines Klartext Passworts.

[Morphie]

Zitat:

Zitat von mjustin (Beitrag 1192571)

Laut diesem Post gibt es schon seit Firebird 1.5 Password Hashes anstatt eines Klartext Passworts.

Gerade noch mal nachgesehen (Firebird 2.5, aktuelle .NET Provider)

Code:

...
0070   04 55 54 46 38 39 04 0f 00 00 00 1c 06 53 59 53  .UTF89.......SYS
0080   44 42 41 1d 09 6d 61 73 74 65 72 6b 65 79 47 04  DBA..masterkeyG.
...

Man sieht, dass SYSDBA und masterkey schön lesbar im Protokoll stehen. (Ich habe das mit der Standardkonfig getestet)

[Bummi]

@joachimd :thumb:

[Privateer3000]

Danke für Eure Hinweise
Grundsätzlich reicht es aber
Anwender davon abzuhalten selbst in der DB
herumzupfuschen.
Wer es darauf anlegt, wird sicher den Weg finden.

Ich habe jetzt per dcpcrypt die Strings und File verschlüsselt
und klappt prima.
Damit bleibt Oma, nebst Freundin und gutem Bekannten draußen.

Grüße

[haentschman]

Zitat:

Dazu gab es mal in im Usenet einen netten Beitrag (ich glaube von Marian Aldenhövel): pack die Daten unverschlüsselt in die readme - die liest sowieso keiner.

...die Idee ist gut. :thumb: Aber bei Plattenplatzproblemen fliegen die zuerst weg. 8-)

[Privateer3000]

Zitat:

Zitat von haentschman (Beitrag 1192655)

...die Idee ist gut. :thumb: Aber bei Plattenplatzproblemen fliegen die zuerst weg. 8-)

Plattenplatzprobleme... die gibts noch? :o

[himitsu]

Du hat eine kleine SSD im Schlepptop und davon sind schon von Anfang an mindestens 50% zugemüllt (z.B. von den Delphi-Installern, welche eine nutzlose Kopie von sich anlegen) und dann noch 1-2 Filme in FullHD3D, noch ein/zwei Quellcodes und schon is die Platte voll. :cry:

[Privateer3000]

Zitat:

Zitat von Morphie (Beitrag 1192577)

Zitat:

Zitat von mjustin (Beitrag 1192571)

Laut diesem Post gibt es schon seit Firebird 1.5 Password Hashes anstatt eines Klartext Passworts.

Gerade noch mal nachgesehen (Firebird 2.5, aktuelle .NET Provider)

Code:

...
0070   04 55 54 46 38 39 04 0f 00 00 00 1c 06 53 59 53  .UTF89.......SYS
0080   44 42 41 1d 09 6d 61 73 74 65 72 6b 65 79 47 04  DBA..masterkeyG.
...

Mit was hast du das ausgelesen?
Mit dem Debugger?

[Morphie]

Mit Wireshark den Netzwerktraffic mitgeschnitten...

[mjustin]

Zitat:

Zitat von Morphie (Beitrag 1192577)

Gerade noch mal nachgesehen (Firebird 2.5, aktuelle .NET Provider)

Code:

...
0070   04 55 54 46 38 39 04 0f 00 00 00 1c 06 53 59 53  .UTF89.......SYS
0080   44 42 41 1d 09 6d 61 73 74 65 72 6b 65 79 47 04  DBA..masterkeyG.
...

Man sieht, dass SYSDBA und masterkey schön lesbar im Protokoll stehen. (Ich habe das mit der Standardkonfig getestet)

Oha!


Ich hatte mich auf diesen Artikel "verlassen":


Password hashes used in Firebird 1.5

Zitat:

"When I listen my network traffic (e.g. with wireshark) I see that after the
username a password hash follows. This password hash consists of 11 charakters."

Es scheint also einen Weg zu geben (oder in 1.5 gegeben zu haben?), Passwort-Hashes statt Klartext zu verwenden.

Auf dieser Seite - Details of the Security Changes in Firebird 2.0 - werden für Firebird 1.5 clientseitig erzeugte Passwort Hashes erwäht - aber auch eine Änderung in 2.0, nach der die Hashes serverseitig (!) erzeugt werden. Nun klingt "serverseitige Hash-Erzeugung" wirklich so, als ob der Client dem Server ein Klartext-Passwort schickt und der Server es hasht (und den Hash in der security2.fdb speichert).

Damit wäre Firebird für Einsatz über unsichere Verbindungen (ohne VPN) eigentlich unbrauchbar...

p.s. auch innerhalb VPN besteht natürlich das gleiche Problem, sicher ist das Passwort nur zwischen den Netzen, denn beim VPN-Partner dann ist es es wieder unverschlüsselt.

[Privateer3000]

Aprospos,
ich hatte überlegt über ein VPN (per OpenVPN)
zu verbinden.
Hat da jemand Erfahrungen? Wie siehts mit der Geschwindigkeit aus?

Unser Server (IPFire) wird von 3 Standorten angesprochen und hat
eine funktionierende VPN, die ich allerdings noch nicht eingesetzt habe.
Der Firebird steht in der grünen Zone und versorgt die Standorte mit Logdaten.
Das wäre ein Plus wenn dies auch noch über VPN geschehen würde.

Die Verbindungsdaten würde sonst ja auch unverschlüsselt übertragen
und alle anderen im grünen Netz könnten mitlauschen.
Kennt sich jemand damit aus?

[Sir Rufo]

Bei einem VPN brauchst du nichts wirklich "benutzen".

Das entfernte Netz ist unter einem bestimmten IP-Bereich ansprechbar und dort sollte auch dein Server zu finden sein. Aso einfach nur die IP Adresse angeben und schon läuft alles via VPN.

Bei geschickter (VPN-)Konfiguration sind alle Geräte durch ihre lokale IP Adresse von allen Standorten erreichbar.

EDIT

Oder verbinden sich die Standorte noch nicht über VPN?

[Privateer3000]

Der jeweilige Client nutzt dann die
OpenVPN Software zum verbinden.
Mit der Konfig des IPFire und dessen
VPN muss ich mich erst beschäftigen.
Das geht erst wieder morgen :)
Mit diesem übersetzen auf die interne IP das
habe ich schon irgendwo gesehen.

Was ich mich grad frage, was in den Firebird
verbindungsdaten eingegeben werden muss.
Dieses Thema ist für mich völlig neu.

Denn was nützt die programminter Verschlüsselung
der Firebirddaten wenn's dann unverschlüsselt über
das Netz geht...

[Sir Rufo]

In einem Firmenumfeld würde ich immer für die Anbindung von Standorten Router benutzen, die eine Verbindung per VPN zur Zentrale herstellen.

Das ist von der Wartung und Handhabung ungemein simpler und sicherer zudem (VPN Zugangsdaten liegen auf dem Router und nicht auf den Clients).

Die tatsächlichen Anwendungsserver würde ich auch immer vom VPN Handling trennen.
Denn für VPN brauche ich ja auch zunächst einen unverschlüsselten Zugang.

Somit besteht die Gefahr der Kompromittierung und das möchte ich auf dem Server mit den Daten möglichst gering halten.

[mjustin]

Zitat:

Zitat von Privateer3000 (Beitrag 1192815)

Die Verbindungsdaten würde sonst ja auch unverschlüsselt übertragen
und alle anderen im grünen Netz könnten mitlauschen.

p.s. auch innerhalb des gesamten VPN besteht natürlich das gleiche Problem, sicher ist das Passwort nur zwischen den Netzen, denn beim VPN-Partner ist es es wieder unverschlüsselt.

[Sir Rufo]

Zitat:

Zitat von mjustin (Beitrag 1192827)

Zitat:

Zitat von Privateer3000 (Beitrag 1192815)

Die Verbindungsdaten würde sonst ja auch unverschlüsselt übertragen
und alle anderen im grünen Netz könnten mitlauschen.

p.s. auch innerhalb des gesamten VPN besteht natürlich das gleiche Problem, sicher ist das Passwort nur zwischen den Netzen, denn beim VPN-Partner ist es es wieder unverschlüsselt.

Das ist aber weniger kritisch, denn man ist ja unter sich ;)

[Privateer3000]

Sicher, aber man hat die Wahl ob
ich Netz-zu-Netz, Client-zu-Netz oder
Client-zu-Client tunnele. Soweit meine Infos reichen.
Wie gesagt ich steh noch am Anfang mit diesem Thema.
Aber ich könnte den Firebird direkt ansprechen ohne dass dieser
im restlichen Netz mitgelauscht wird.
Obendrein ermöglicht der IPFire 4 Netze im LAN
so kann ein Server ein eigenes Netz haben (DMZ).

Aber zum Thema zurück.
Wenn ich nun die Verbindungsdaten, die ich in einer verschlüsselten
Datei stehen habe, von der Anwendung in ein Stream geladen werden
und dort entschlüsselt werden, können diese dann auch noch ausgelesen werden (Debugger)?
Im Schema ca. so

Code:

Anwendungstart -> a.LoadToStream(cryptetfile) -> decrypt(cryptetfile)
b.LoadfromStream(var)->b.password ---> Close (a.free)

so ungefähr vllt. sieht etwas wirr aus.