# Datenbankverbindung ohne Passwort im Quelltext bei einer offline Anwendung



## eskimo328 (19. Mrz 2012)

Hallo,

wie eine Datenbankverbindung zu einer lokalen H2-Datenbank aufbauen, ohne dass Passwort im Quelltext zu speichern? Das Thema gab es schon öfters, eine gute Lösung ist wohl der Weg über einen Webservice.

Problem ist jedoch, dass sich die Datenbank auf dem Client-Rechner befindet und die Anwendung offline funktionieren muss. D.h. einmalig (oder manuell durch den User) werden die Benutzer- und Anwendungsdaten (Stammdaten, Statistikdaten, etc.) vom Server geladen und in der lokalen DB gespeichert.

Folgendes Szenario:
Der User installiert die Anwendung, damit wird automatisch die DB und deren Struktur erstellt.
Beim Start der Anwendung baut diese eine Verbdindung zur lokalen DB (DB-Benutzer + DB-Passwort stehen plain im Code) auf. Ist der User online, werden die Benutzerdaten automatisch vom Server geladen und in der DB gespeichert. Dann kann sich der User anmelden und alle notwendigen Daten vom Server laden, die Daten werden dann in der DB gespeichert. In Zukunft muss der User dann auch offline arbeiten können.

Wie kann im offline Modus sicherer eine DB Verbindung aufgebaut werden, ohne dass das PW im Klartext im Code steht?
Ich nehme an eine sichere Variante gibt es nicht, aber eine bessere?


----------



## tfa (19. Mrz 2012)

Der Anwender muss das DB-Passwort selbst eintippen. Das wäre die "sicherste" Lösung.
Handelt es sich um eine embedded H2 oder läuft der Server lokal?


----------



## eskimo328 (19. Mrz 2012)

Ja, embedded H2.



tfa hat gesagt.:


> Der Anwender muss das DB-Passwort selbst eintippen. Das wäre die "sicherste" Lösung.


Wohl wahr, aber man kann dem User nicht zumuten ein DB Benutzer/Passwort einzugeben und danach sich nochmals mit seinen Benutzerdaten anzumelden.


----------



## tfa (19. Mrz 2012)

> Ja, embedded H2.


Dann lass das Passwort komplett weg. Was soll das bezwecken?


----------



## eskimo328 (19. Mrz 2012)

Wenn eine unbefugte Person Zugriff zu dem Notebook hat (aus welchem Grund auch immer) darf diese nicht die Daten auslesen, also nicht an Kunden- /Auftrags-/ Statistikdaten etc. herankommen.


----------



## Marcinek (19. Mrz 2012)

Dann benutzte doch die Authentifizierung der Datenbank. Dann kannste das Rechtesystem der Datenbank nutzen.


----------



## tfa (19. Mrz 2012)

> Wenn eine unbefugte Person Zugriff zu dem Notebook hat (aus welchem Grund auch immer) darf diese nicht die Daten auslesen, also nicht an Kunden- /Auftrags-/ Statistikdaten etc. herankommen.


In dem Fall muss die DB natürlich auch verschlüsselt sein. PW alleine reicht nicht.
Am besten verschlüsselt man die gesamte Festplatte und lässt das Notebook beim Booten ein Passwort abfragen. Für Firmenlaptops sollte das eigentlich Standard sein.


----------



## eskimo328 (19. Mrz 2012)

OK, Datenbank-Verschlüsselung sollte man auch nachdenken, das stimmt. Aber auch hier benötige ich ein PW für die Verschlüsselung, das ebenfalls wieder irgendwo gespeichert werden muss. Selbes problem!?

Festplatte/Notebook verschlüsseln wäre zwar eine Variante, jedoch handelt es sich teilweise um Firmennotebooks aber auch um private Notebooks. Wir müssen von unserer Seite einfach mehr oder weniger alles mögliche machen um das System "sicher" zu machen, als auch ohne Verschlüsselung/Boot-Passwort. 

Wir haben jetzt auch keine HOCHgeheimen Daten die die Welt verändern und brauchen es daher nicht zu übertreiben. Aber dennoch, wenn es was zu verbessern gibt bzgl. Sicherheitm, sollte man das auch machen. Ich denke eben, das PW im Code zu speicher ist so ziemlich die einfachste und unsicherste Variante.


----------



## tfa (19. Mrz 2012)

> Aber auch hier benötige ich ein PW für die Verschlüsselung, das ebenfalls wieder irgendwo gespeichert werden muss.


Ja. Am besten im Gehirn des Anwenders.


----------



## eskimo328 (19. Mrz 2012)

Das is geht ja eben nicht. Der Benutzer soll nur seine eigenen Zugangsdaten eingeben müssen um sich an der Anwendung einloggen zu können. Diese stehen blöderweise in der Datenbank, die ebenfalls ein Passwort benötigt.

D.h. es gibt keine bessere Lösung, also das PW muss im Code stehen, zumindest bei der offline Variante?

Wie wäre folgende Variante, oder habe ich hier einen Denkfehler:

Anwendung wird zum ersten Mal gestartet
Benutzer gibt Name + Passwort ein
Anfrage mit Name und Pw wird an den Server gesendet, dieser prüft die Daten mit der Benutzertabelle und gibt ein OK zurück. (Bei einem FAIL ist der Login nicht möglich)
Wenn OK, dann erstellt die Client-Anwendung die Datenbank mit einem Standard User und Passwort, dass ich ebenfalls per Server als Antwort zurück bekomme. Diesen kann ich als Admin nutzen um auf die Datenabk zuzugreifen. Zudem liefert mir der Server alle Benutzer und Passwörter, die ebenfalls als Datenbankbenutzer angelegt werden.
In Zukunft kann ich dann mit meinem eigenen Benutzernamen und Passwort eine Datenbankverbindung aufbauen und bin zugleich auch eingeloggt.

@Marcinek: Hast du das vielleicht so gemeint?


----------



## moonermo (19. Mrz 2012)

Wie wäre es, wenn die Nutzerdaten zum Einloggen in die Anwendung gleich der Nutzernamen für die DB sind? (Passwörter natürlich auch). Dann fällt die Tabelle für Benutzernamen weg...


----------



## Guybrush Threepwood (20. Mrz 2012)

Die Offline-Datenbank wird sicher irgendwo im Benutzerverzeichnis abgelegt, oder? In diesem Fall wäre das Datenbank-File bereits durch die Zugriffskontrolle des Betriebssystems geschützt. Das ist ja nicht viel anders als mit dem Dokumenten der Firma, die ja auch irgendwie geschützt abgelegt werden müssen, ohne dass das ganze Internet darauf zugreifen kann. Die Datenbank-Datei ist dann lediglich eine Datei mehr unter diesen anderen Dokumenten.


----------



## eskimo328 (20. Mrz 2012)

Es handelt sich hier um ein Außendienstsystem für Vertreter


----------



## areafo (21. Mrz 2012)

@eskimo

Du kennst doch bereits Grundlegend alle aktuellen Möglichkeiten und hast diese auch logisch durchdacht.

Nochmal. Entweder man hat etwas geschützt mit einer Authentifizierungsmethode seiner Wahl, dann muss diese auch durchgeführt werden oder man vertraut auf die schon bestehenden Authentifizierungsmethoden drumrum und braucht dann keine eigene zu implementieren.

Woher die Credentials für die Authentifizierung kommen ist erstmal zweitrangig und bringt dich anscheinend zu einem Punkt wo du nach etwas suchen möchtest was es nicht gibt.

Ergänzend:
1. Du weisst bereits das dein Quelltext einsehbar ist >>> Das ist schonmal sehr gut
2. Du weisst bereits das dein Quelltext und alle Abläufe darin manipulierbar sind >>> wunderbar
3. obfuscator für den Quelltext und viele Spitzfindigkeiten im und um den Quelltext herum verschaffen Zeit und bringen für den Entwickler Hürden mit sich mehr nicht.

Clientseitig wirst du natürlich niemals auf ein Serversicherheitsniveau heran kommen


----------



## Guybrush Threepwood (21. Mrz 2012)

eskimo328 hat gesagt.:


> Es handelt sich hier um ein Außendienstsystem für Vertreter



Ja, aber wenn jemand unberechtigt an das Datenbank-File herankommt, dann hat er möglicherweise auch Zugriff auf die Anwendung selbst, die - wie Du schreibst - die Daten automatisch von einen Server holt. In diesem Fall müsstest Du die gesamte Anwendung schützen. Es ist dann nicht alleine ein Problem davon, ein Passwort für die lokale Datenbank im Quelltext zu haben. Das Problem ist dann viel umfangreicher.


----------

