Hallo Zusammen,

ich stelle mir gerade folgende Frage, wir bauen eine Datenbank auf in welche wir Passwörter speichern. Da es verschiedene Arten von Passwörtern gibt und diese somit andere Felder benötigen, Frage ich mich gerade ob ich eine große Tabelle mache mit allen Passwörtern drin, worin jedoch je nachdem viele Spalten dann NULL sein werden oder

ob ich für jede Passwortart eine eigene Tabelle anlege.

Als Beispiel:

Sehr einfach sind z.B. die Daten für das Passwort bei Fachinformatiker.de

Hier brauche ich nur Bezeichnung, URL, Benutzername und Passwort.

Bei einem WLAN Router gibt es einige Felder mehr. Einige überschneiden sich aber andere sind "neu".

Bezeichnung, URL, Benutzername und Passwort sind identisch, aber z.B. SSID und das Passwort von der SSID wären neu.

Sollte ich somit eine Tabelle anlegen mit Bezeichnung, URL, Benutzername, Passwort, SSID, SSID Passwort worin jedoch viele Datensätz die Spalten SSID und SSID Passwort leer sind oder lieber eine Tabelle "Webportale" und eien Tabelle "WLAN Router" und in diese jeweils die benötigten Spalten?

Gruß

IT-Biene

Hi,

ich würde vermutlich einen (zwingend eindeutigen) Namen vergeben (z.B. Fachinformatiker.de, oder Verwaltungs-WLAN etc.) und ein Feld Bemerkung, in dem zusätzliche Infos eingetragen werden können (aber nicht müssen) wie eben SSID oder URL oder sowas. Danach (zwingend) Benutzernamen und Passwort.

Bei einem WLAN könnte man natürlich auch die SSID mit in den Namen packen, wie z.B. Intern_wlan_SSID0815 oder sowas.

Ich denke es macht wenig Sinn eine Tabelle anzulegen mit etlichen Attributen, die dann meistens sowieso leer sind.

Das hört sich ganz nach internem Gebrauch an.

Probiert mal KeePass, das macht alles was ihr braucht.

Wie du die Datenbank aufbaust, hängt davon ab, was ihr da später reinkippt. Wenn ihr nur einen (vllt. zwei) Routerzugänge habt, dann lohnt es sich wahrscheinlich nicht, die extra zu modellieren. Wenn ihr hingegen dutzende (oder hunderte) Router habt, die ihr verwaltet und die für sich genommen eine Anwendung darstellen, dann würde ich die DB auf jeden Fall entsprechend modellieren.

Wenn ihr aber eine kleine DB (ein paar Dutzend Einträge) mit heterogenen Zugängen habt, würde ich mir auch nicht die Mühe machen, das großartig zu unterteilen - damit macht man sich nur unnötigen Aufwand. Überleg dir eine Tabellenstruktur, in der du alle benötigten Daten ordentlich abbilden kannst und leb' damit, dass bei einigen Datensätzen die Hälfte Attribute null ist.

Danke, für eure Rückinfo. Ja das ganze ist für den internen Gebrauch gedacht. Es werden denke ich schon mehrere 100 oder gar 1000 Passwörter werden. Dann werde ich wohl eher den Weg gehen für jede Art eine Tabelle anlegen. Danke

Hi,

wobei sich dann tatsächlich die Frage stellt, wieso ihr nicht KeePass nehmt und stattdessen was Eigenes entwickelt?

4 Tabellen

Tabelle A

Modellname

Modellbeschreibung

ModellID

Tabelle B

ModellID

Feldname

FeldID

Tabelle C

Gerätename

Gerätebeschreibung

GeräteID

ModellID

Tabelle D

GeräteID

FeldID

Beschreibung

Inhalt

Mit diesem Aufbau kannst du a über Tabelle A Modell definieren diese bekommen eine ID

In Tabelle B speicherst du zu jeder ModellID aus A 1-x Felder (FeldID) die du für jedes Modell eigen definieren kannst.

Also z.B. Router, Webzugänge etc.

in Tabelle C speicherst du den eigentlichen Zugang z.B. Fachinformatiker.de und verknüpfst das mit der ModellID aus B

und in D werden dann die in B definierten felder zum Gerät zusammengehängt.

Danke Enno ich glaub so werde ich das machen.

Wir haben aktuell Passwordsafe im Einsatz, wollen aber eine Integration in unsere Software erreichen, deswegen die eigene Struktur und Aufbau.

Habt ihr einen Sicherheitsbeauftragten? Der Haut euch das nicht um die Ohren?

Hi,

Habt ihr einen Sicherheitsbeauftragten? Der Haut euch das nicht um die Ohren?

wird er nicht, weil das nicht in den Aufgabenbereich eines Sicherheitsbeauftragten fällt. Wenn überhaupt dürfte das den Datenschutzbeauftragten interessieren.

Dann denk aber auch dran, dass man Passwörter nicht unverschlüsselt in einer Datenbank speichert.

Hashing der Passwörter fällt raus, wenn man das Passwort im Klartext angezeigt bekommen haben möchte und nciht nur der Hash verglichen wird, ob das Passwort übereinstimmt.

Alle anderen Verfahren, die zwingend umkehrbar sein müssen, sind unsicher, sobald jemand Zugriff auf die Datenbank erlangt.

Wenn sollte es also zumindest entsprechende Firewallregeln und Berechtigungen auf der Datenbank geben, dass auch wirklich nur der entsprechende Server auf die Datenbank zugreifen darf, auf dem die Anwendung dann läuft.

Verschlüssle die Passworte lieber mit einem salt, mit dem man sich Einloggen muss. Dann ist es wenigstens halbwegs sicher.

Bearbeitet 14. Juni 201510 j von boredom

Hi,

Verschlüssle die Passworte lieber mit einem salt, mit dem man sich Einloggen muss. Dann ist es wenigstens halbwegs sicher.

den Satz verstehe ich so nicht. Ein Salt ist ein Zufallswert, der mit dem Passwort abgespeichert wird um Wörterbuchattacken zu erschweren, inwiefern hat das irgendwas mit "Einloggen" zu tun?