DB-Zugangsdaten verschlüsseln

[mkinzler]

Zitat:

Ob du die .txt nun verschlüsselst oder nicht, macht im Grunde keinen großen Unterschied.

Auch die meisten (Haus-)Türen sind nicht sicher, trotzdem sollte man diese Abschliessen.
Aus meiner Sicht macht es deshalb schon einen Unterschied ob die Zugangsdaten verschlüsselt oder im Klartext in der Textdatei/Ini/XML/Registry stehen.

[Schokohase]

Es ist ganz einfach:

Ohne eine weitere Schicht (z.B. REST-API) die auf einem anderen System läuft hast du nur Pseudo-Sicherheit. Egal wie die aussieht, egal was du machst.

Das war schon immer so und wird sich auch so schnell nicht ändern.

[KodeZwerg]

Zitat von Ykcim:

Was meint ihr?

Wie bereits erwähnt, alles ist besser als nichts. Von daher, mach es.
100 Prozent kann man mW eh nicht erreichen. Ob über REST, Datei/Registry oder über Timbuktu per Snailmail, Daten kann man überall irgendwie abgreifen.
XOR Gewährt Dir zumindest minimal Schutz vs unversierte Blicke.

[Schokohase]

100% Schutz gibt es nicht auch nicht bei REST-API.

Allerdings liegt ohne diese physische Zwischenschicht die Sicherheit bei 0%-20% und mit der physischen Zwischenschicht bei 90%-99% (z.B. physischer Einbruch in das Rechenzentrum oder Ausnutzen einer Zero-Day-Lücke und ähnliche Kaliber).

Man muss selbst entscheiden, was ausreichend ist.

[Jumpy]

Und man muss auch überlegen, vor wem man sich schützen will. Ist es z.B. vor der IT-Abteilung des Kunden nützt dir REST usw. auch nix, wenn die Server beim Kunden stehen. Geht es nur um das Fernhalten normaler Mitarbeiter eines Kunden reicht wohl das verschlüsselte Passwort irgendwo und sei es im Quelltext. Geht es darum komplett fremde Leute fern zu halten, muss man hoffen, das der Kunde eine gute Alarmanlage hat...

[KodeZwerg]

Im Kompilat kann das benutzte Passwort für die XOR Methode natürlich auch verschlüsselt ablegt werden, aber egal wie viel Layers man raufpackt, ist es ausführbar ist es angreifbar. Wobei es interessante Schutzproduke gibt die sich auf so was spezialisiert haben Themida zum Beispiel.
Schokohase hat mit REST schon Recht, ein Dongle geht übrigens auch.

[Zacherl]

Zitat von Schokohase:

Ohne eine weitere Schicht (z.B. REST-API) die auf einem anderen System läuft hast du nur Pseudo-Sicherheit. Egal wie die aussieht, egal was du machst.

Eben dieses.

Zitat von mkinzler:

Zitat:

Ob du die .txt nun verschlüsselst oder nicht, macht im Grunde keinen großen Unterschied.

Auch die meisten (Haus-)Türen sind nicht sicher, trotzdem sollte man diese Abschliessen.
Aus meiner Sicht macht es deshalb schon einen Unterschied ob die Zugangsdaten verschlüsselt oder im Klartext in der Textdatei/Ini/XML/Registry stehen.

Dein Vergleich hinkt. Passend währe vielleicht die Unterscheidung zwischen nicht-abschließen und abschließen, aber den Schlüssel unter der Fußmatte zu deponieren. Diese Denkweise "besser etwas (was trotzdem effektiv nicht hilft), als gar nichts" ist verdammt gefährlich in der IT. Das schlechte Gewissen ist beruhigt, aber irgendwann kracht es unweigerlich und man hat den Salat.

Zitat von KodeZwerg:

Wobei es interessante Schutzproduke gibt die sich auf so was spezialisiert haben Themida zum Beispiel.

Hierdurch erschwert man das Reverse Engineering - richtig angewendet - zwar tatsächlich signifikant, aber sicher ist es wie du schon sagst trotzdem nicht (siehe gecrackte Spiele). Never trust the client.

[rokli]

@Schokohase

Zitat von Schokohase:

@rokli

Es geht um die Zugangsdaten zur Datenbank, diese sollen dem Benutzer nicht bekannt sein.

Es geht nicht um die Zugangsdaten der Anwendung, die dem Benutzer sehr wohl bekannt sind, weil er diese selber festlegt (und diese sollten in der Datenbank nur als Hash gespeichert werden).

Um die Zugangsdaten der Anwendung aber überprüfen zu können muss es eine Verbindung zur Datenbank geben und dafür eben auch Zugangsdaten und diese sollen aber geheim sein (damit z.B. nicht jeder in der Datenbank herumpfuschen kann).

Dafür (und nur dafür) such der TE eine Lösung.

Ich traue dem TE zu, dass er das Verfahren da einsetzt, wo er es verwenden möchte; darum habe ich glaub ich immer INI/DB gleichzeitig genannt.

Zitat von mkinzler:

... in der Textdatei/Ini/XML/Registry stehen.

Danke @mkinzler

[generic]

Zitat von Schokohase:

@rokli

Es geht um die Zugangsdaten zur Datenbank, diese sollen dem Benutzer nicht bekannt sein.

Es geht nicht um die Zugangsdaten der Anwendung, die dem Benutzer sehr wohl bekannt sind, weil er diese selber festlegt (und diese sollten in der Datenbank nur als Hash gespeichert werden).

Um die Zugangsdaten der Anwendung aber überprüfen zu können muss es eine Verbindung zur Datenbank geben und dafür eben auch Zugangsdaten und diese sollen aber geheim sein (damit z.B. nicht jeder in der Datenbank herumpfuschen kann).

Ich glaube, ihr habt hier ein Konzept Problem.

Ihr baut euch eine eigene Benutzerverwaltung! Das ist nicht notwendig.

Der Datenbankserver hat bereits eine eingebaut, nutzt die. Damit habt ihr auch nicht das Problem, dass es eine weitere technische Verbindung/Benutzer gibt, die das gesamte Rechtssystem untergräbt.

Bevor jetzt die Diskussion los geht, mit "ich habe aber Köpfe zum Löschen und Bearbeiten in der Oberfläche die sollen aus sein, wenn der Benutzer keine Rechte hat" kann ich nur sagen:
Genau die Datensätze in Tabellen lassen sich auch Rechte abfragen. Wenn ein Benutzer kein "DELETE" auf der Tabelle hat, dann kann man auch den Knopf ausmachen.

Ja, manchmal sind die Datenbankrechte nicht fein genug, dann batch Funktionen welche die BI abbilden und die Tabellen verstecken. Schließlich braucht ein Benutzer nicht zwingend ein "SELECT" Recht auf einer Tabelle, wenn er die Daten auch durch einen View oder Funktion bekommen kann.

[Schokohase]

Zitat von generic:

Zitat von Schokohase:

...

Ich glaube, ihr habt hier ein Konzept Problem.

Das Konzept-Problem ist der direkte Zugriff vom Client auf die Datenbank und das in jeder Hinsicht. Zugriffs-Komponenten, Treiber, Zugangsdaten, etc.

Aber wieso wir? Ich habe das Problem nicht ...