DB-Passwort vor Decompilierung schützen?
-
Hi,
security by obscurity funktioniert nicht.
das mag schon sein, aber was ist die Alternative? Die DB gleich offenlegen? Problem ist halt, dass darin sensible Daten liegen.
Tschüss,
Christian
-
Man sollte wohl erst einmal definieren, was hier unter Sicherheit zu verstehen ist. Je nachdem wie sicher es sein muss reicht security by obscurity , ansonsten den Benutzer das Passwort eingeben lassen.
-
winni schrieb:
das mag schon sein, aber was ist die Alternative? Die DB gleich offenlegen? Problem ist halt, dass darin sensible Daten liegen.
ich kann dir keine alternative nennen, dazu weiß ich zu wenig über die konkrete problemstellung. fakt ist aber: wenn du das passwort in irgendeiner form mit dem programm auslieferst, kannst du die datenbank auch gleich offenlegen. deine "sensiblen daten" sind dann nicht mehr sicher.
-
Hi,
Knuddlbaer schrieb:
Man sollte wohl erst einmal definieren, was hier unter Sicherheit zu verstehen ist. Je nachdem wie sicher es sein muss reicht security by obscurity , ansonsten den Benutzer das Passwort eingeben lassen.
vollkommene Sicherheit wird man kaum erreichen. Aber: Erreichen möchte ich, dass nicht jeder Laie mit einem Tool wie reflector sehr schnell das Datenbankkennwort rausbekommt und damit die DB direkt öffnen kann.
warnende entität schrieb:
ich kann dir keine alternative nennen, dazu weiß ich zu wenig über die konkrete problemstellung. fakt ist aber: wenn du das passwort in irgendeiner form mit dem programm auslieferst, kannst du die datenbank auch gleich offenlegen. deine "sensiblen daten" sind dann nicht mehr sicher.
Die Problemstellung ist, dass unser Programm auf eine Access-DB zugreift, die aus Sicherheitsgründen passwort-geschützt ist. Bitte jetzt keine Diskussionen wie weit die Access-DB selbst damit gesichert ist, mehr geht halt nicht bei derartigen Datenbanken. Somit muss ich also das Passwort in irgendeiner Form 'ausliefern'.
Gäbe es wie anfangs erwähnt irgendeine Form der sicheren Authentifizierung zwischen Exe und Dll würde mir das als Sicherheit bereits ausreichen. Mir ist schon klar, dass auch eine normale C-Dll disassembliert werden kann. Aber wer sich die Mühe macht, soll dann ruhig auch belohnt werden
Danke,
Christian
-
dongle....
-
BorisDieKlinge schrieb:
dongle....
ja, damit wäre Sicherheit zu erreichen. Allerdings paßt das nicht zu unserer Anwendung, die quasi als Freeware per Internet verteilt wird.
Irgendwie schon seltsam, mit diesem Problem müßten doch eigentlich eine Menge Leute zu tun haben. Schon fast jedes Programm nutzt ja irgendwo eine kleine DB. Und wenn es nun in .net geschrieben ist...
Christian
-
winni schrieb:
Irgendwie schon seltsam, mit diesem Problem müßten doch eigentlich eine Menge Leute zu tun haben. Schon fast jedes Programm nutzt ja irgendwo eine kleine DB. Und wenn es nun in .net geschrieben ist...
Den Vorschlag hab ich Dir zwar schon gemacht, aber der Vollständigkeit halber:
Vermutlich werden diese Infos oft auf Dateiebene abgelegt (app.config). Und eine Datei kann man ja derart schützen, dass nur noch die Anwendung und der Administrator darauf Zugriff hat.
-
winni schrieb:
Problem ist halt, dass darin sensible Daten liegen.
was sind bei dir eigentlich "sensible" daten? wer erleidet denn einen schaden, wenn auf die enthaltenen daten frei zugegriffen werden kann? und wie groß wäre der entstehende schaden? wer hätte überhaupt interesse daran, an die daten zu gelangen?
winni schrieb:
Mir ist schon klar, dass auch eine normale C-Dll disassembliert werden kann. Aber wer sich die Mühe macht, soll dann ruhig auch belohnt werden
die mühe muss sich nur ein einziger machen. danach kann er das passwort einfach veröffentlichen, womit das sicherheitskonzept bereits ausgehebelt wäre.
ich würde mir an deiner stelle wirklich keinen kopf darüber machen, wie du das passwort in deiner anwendung hinterlegst. es macht keinen echten unterschied ob du es verschlüsselt in einer extra dll aufbewahrst oder einfach im klartext im programm stehen hast. wenn es jemand rausfinden will, dann kriegt er es auch raus. und wenn es einer weiß, dann wissen es alle.
die einzigen die du mit deinem ansatz aufhalten kannst, sind total unbedarfte anwender, die nicht auf die idee kommen bei google nach dem passwort zu suchen, und außerdem nichts über decompiler wissen, oder dass man einfach mal in den binärcode reinschauen könnte.
meiner meinung nach wäre der zeitaufwand für die verschleierung des passworts deshalb vergeudete zeit. ich empfehle deshalb maximal eine einfache substitionschiffre, die sich in 5 minuten implementieren lässt.
wenn du doch mehr sicherheit brauchst, musst du wohl das gesamte konzept mit der datenbank nochmal überdenken.
-
nachfragende entität schrieb:
was sind bei dir eigentlich "sensible" daten?
es handelt sich dabei um (Lohn-)Buchhaltungsdaten. Für den einen oder anderen kann es z.B. durchaus interessant sein, was der Chef oder der Kollege so verdient
Das Geschrei wär dann natürlich groß, wenn da jemand ohne großen Aufwand rankommt.nachfragende entität schrieb:
ich würde mir an deiner stelle wirklich keinen kopf darüber machen, wie du das passwort in deiner anwendung hinterlegst.
naja, Kopf in Sand stecken ist auch ne Strategie
nachfragende entität schrieb:
wenn du doch mehr sicherheit brauchst, musst du wohl das gesamte konzept mit der datenbank nochmal überdenken.
Mein Problem ist wohl eher der anvisierte Anwender. Der will sich nicht um die Sicherheit kümmern bzw. hat das Know-How dazu gar nicht, sondern erwartet, dass das Programm das für ihn macht. Aber ohne saubere Benutzerverwaltung, die auf Dateiebene für Sicherheit sorgt, wie von lordjaxom vorgeschlagen, wird das nichts.
Scheinbar muss man sich wirklich damit abfinden und von .net lieber die Finger lassen, wenn es um Anwendungen geht, die sensible Daten verwalten, jedoch beim Anwender ohne großen Aufwand und mit einer DB arbeiten sollen.
Wir machen es nun doch mit "security by obscurity", hilft somit halt nicht.Danke,
Christian
-
ist es denn möglich, dass wenigstens für jede installation des programms ein eigenes passwort generiert wird (oder vom benutzer festgelegt wird)? so wäre zumindest nicht jede installation kompromittiert, wenn das masterpasswort publik wird.