Anleitung zum Umgang mit Datenbank Komponenten

[Medium]

Wenn es schlecht ist, dass sich ein User mit diesen Daten direkt am SQL Server anmelden kann, dann hat dieser User zu viele Rechte . Mach einen User, der nur genau die Rechte hat, die dein Programm braucht, und keinesfalls den root oder sowas. Wenn dieser dann auch im Klartext lesbar ist, macht das nix.

[DanielJ]

Hallo,

bei uns stehen die Verbindungsinformationen für die Verschiedenen Server in der Registry. Passwörter werden garnicht gespeichert, sondern beim Programmstart vom Nutzer angegeben.

Da kannst du auch machen was du willst - wenn du die Passwörter speicherst kann sie ein entsprechend versierte Nutzer auch auslesen.

Man kann sie zwar Verschlüsseln, aber der Key zum entschlüsseln befindet sich ja dann in der Exe und lässt sich per Debugger schnell finden.

LG,
Daniel

PS: Und dann kommt Firebird und macht alles zunichte in dem es die Passwörter im Klartext übers Netzwerk jagt ...

[Ykcim]

Die Passwörter für die Software werden natürlich nicht in einer File gespeichert, sondern in dem SQL-Server. Aber das Passwort für den Datenbank-Zugriff...

Gruß
Ykcim

[Sherlock]

Datenbankzugriffs-PW ist bei uns in der SW mehr oder weniger fest verdrahtet drin.

Sherlock

[himitsu]

Man sollte sie aber nicht unbedingt im OI (in der DFM) ablegen, sondern irgendwo per Code zuweisen.

Falls man nicht will, daß es per "Textsuche" im Code auffindbar ist (jenachdem wie das Pass"wort" aussieht), dann mit externem Programm verschlüsseln, verschlüsselt in den Quellcode kopieren und dort beim Zuweisen entschlüsseln lassen.

Mehr mühe braucht man sich nicht machen, denn jeder mit einem Compiler kann immernoch zum Aufruf der Passwortabfrage/-übergabe und sich dort den Inhalt der Variable (Speicherbereich im RAM) ansehn.
Und dann kann man eventuell auch noch ganz einfach die Connection zum DBServer belauschen (falls nicht verschlüsselt).

[Sir Rufo]

Es stellt sich die Frage, ob man überhaupt viel Energie in das Verstecken, Verschleiern oder Versonstwas mit den Zugangsdaten anstellen sollte.

Eine vernünftige Anwendung und vernünftig konfigurierter Server können dahingehend recht gut abgesichert werden, trotz bekannten Zugangsdaten sich keine Blöße zu geben.

Wer allerdings als Zugangsdaten den Root mitgibt, ja, der ist ja auch irgendwie selber Schuld gelle

[DanielJ]

Naja,

z.B. im Callcenter währe es schon schädlich genug wenn einer mal eben per "select * from Kundendaten" die Adressen klaut - dann kann der Laden eigendlich dicht machen. Dafür reicht ja schon Lesezugriff!

Ein Kombination aus Programmbenutzer-Passwort und "geheimen" im quelltext/verschlüsselter Textdatei etc. verstecktem Passwortanteil kann hier zumindest die Hürde erhöhen. Man muss natürlich dann bei jeder Änderung des Programmbenutzers den passenden Datenbanknutzer mit ändern, aber das lässt sich ja automatisieren.

LG,
Daniel

[Sir Rufo]

Wer behauptet dass ein DB User direkten Zugriff (selbst rein lesend) auf die Tabellen haben muss?
Solch kritischen Datenzugriffe (wie du geschildert) würde ich immer über eine Stored Procedure laufen lassen.
Und dort kann ich mir jede Schweinerei ausdenken um den Zugriff auf das Allernötigste zu beschränken.

Desweiteren hat man immer die Möglichkeit eine weitere Schicht zwischen Client und DB Server zu setzen.

[DanielJ]

Hallo,

da hast du natürlich recht - bloß das muss erstmal einer bezahlen.
Ich habe leider noch keine Individualsoftware und wendig Standartsoftware gefunden, die da nicht erhebliche Mängel aufweist. Und wenn man den Kunde/Arbeitgeber darauf hinweist und dann erstmal wochenlange Restrukturierungsarbeiten/ das Erstellen eine Middleware vorschlägt, nehmen die meisten Klein- und Mittelständler lieber die Unsicherheit in kauf.
Dann kann man teilweise froh sein, wenn´s nicht allzuviele Proteste dagegen gibt, zumindest den SysDBA aus dem Quelltext zu entfernen und mal das Defaultpasswort zu ändern ...

LG,
Daniel