Datenbank-Passwörter speichern

[Jumpy]

Hallo,

der gefühlt 100ste Thread zum Thema Passwort speichern, aber irgendwie hab ich mich in den 5 meist längeren Threads, die ich gerade gelesen habe, (da ging es meistens um FTP-Passwörter) nicht wieder gefunden.

Ich habe ein altes Programm, das nur innerhalb der Firma eingesetzt wird und im Prinzip eine Art Toolsammlung für alle möglichen Aufgaben ist. Das Programm kann dazu auch auf vielen verschiedenen Datenbanken viele verschiedene kleine Dinge tun. Für letzteres hat das Programm für jede der vielen Datenbanken mind. einen Nutzernamen samt Passwort, den es für den Kontakt mit dieser Datenbank nutzen soll, manchmal auch mehrere mit unterschiedlichen Rechten.
Ich habe jetzt gemerkt, da sich ein Datenbank-Passwort geändert hat und eine Funktionalität nicht mehr ging, und ich dem nachgehen sollte, dass sowohl User als auch Passwort im Klartext im Quelltext stehen. Ich habe also das Passwort an der richtigen Stelle geändert, neu kompiliert, fertig.

Aber jetzt wo ich von dieser Geschichte weiß, stört mich das mächtig. Erstens, dass ich jedesmal den Quelltext anpassen und neu kompilieren muss, wenn sich ein Passwort ändert. Viel mehr aber noch, das jeder Kollege (wie jetzt auch ich) einfach nur in den Quelltext gucken muss, um diverse "interessante" andere Dinge auf den Datenbanken machen zu können.

Wie kann ich a) ohne Neukompilieren usw. Passwortänderungen dem Programm zugänglich machen und b) die Passwörter zumindest nicht mehr im Klartext irgendwo stehen zu haben.

Meine Idee ist jetzt, die Passwörter verschlüsselt z.B. in einer Ini-Datei oder Datenbanktabelle stehen zu haben wobei auch Benutzername und Datenbank, die ja sowas wie Sektion und Key der Ini-Datei wären auch zu verschlüsseln.
Das Ganze soll keinem Hacker standhalten sondern verhindern, dass der "normale Sachbearbeiter", also kein anderer Entwickler oder Admin, so einfach an diese Passwörter kommen kann.

Wäre das ein ausreichender Weg und welche Verschlüsselung kann man da einfach nehmen?

[Luckie]

Rot13. Ich meine, wenn man nicht den eignen Mitarbeitern vertrauen kann, wem dann? Oder eine beliebige Cäsar-Chiffre mit der Länge des Benutzernamens als Verschiebung. Oder einfache Verschlüsselung mit Benutzername als Key. Es soll ja nur Deppen (Sorry) und Mitarbeiter, denen man vertrauen sollte, abhalten

[p80286]

Ich habe ein ähnliches Problem, da habe ich mir mit einer INI-Datei und einer Base64-Codierung für das Passwort geholfen. Und natürlich haben nur 3 UIDs die Möglichkeit, diese Datei auch zu schreiben.

@Luckie
Das mit den Deppen ist nicht so weit hergeholt, letzt hat eine Kollegin eine gutes Drittel eines Datenbestandes geschrottet, nur weil sie eigentlich unnötige Rechte hatte.

Gruß
K-H

[Klaus01]

.. warum gibt man den Usern nicht die entsprechenden Passwörter - und läßt sie diese eingeben wenn sie
das Programm nutzen wollen. Dann müssten die Passwörter auch nirgendes gespeichert werden, das gesalzene Passwort Hash würde dann genügen.

Grüße
Klaus

[Jumpy]

Zitat:

Zitat von Klaus01 (Beitrag 1310978)

.. warum gibt man den Usern nicht die entsprechenden Passwörter - und läßt sie diese eingeben wenn sie
das Programm nutzen wollen. Dann müssten die Passwörter auch nirgendes gespeichert werden, des Passwort Hash würde dann genügen.

Grüße
Klaus

Das würde dem Sinn des Programms als Eierlegendewollmilchsau wiedersprechen. Abhängig vom (Domäne-)Benutzer kann man mit dem Programm untersch. Dinge tun. Ich kann damit z.B. bei 4-5 ganz anderen Programmen die Passwörter dortiger Benutzer zurücksetzen oder diese nach einer Sperre freischalten usw.
Ich muss mich nicht in dem anderen Programm als Admin anmelden, um das da zu machen und ich muss mir auch nicht für die jeweiligen Datenbanken die hinter den jeweiligen Programmen stehen merken wo das was in welcher Tabelle gespeichert ist, das die Passwortverwaltung beeinflußt und ich muss mir erst recht für diese anderen Datenbanken keine Anmeldedaten merken, oder überhaupt irgendwelche anderen Rechte auf diesen DBs haben.

Es geht hier auch nicht unbedingt um böswilligkeit der Kollegen. Es kam schon vor, dass sich Kollegen für gewisse Programme "hintenrum" über die Datenbank mal kurz zum Admin gemacht haben, um dann im Programm schnell was einfacher ändern zu können und dabei unabsichtlich Konfigurationen zerschießen o.ä.

[Mavarik]

Zitat:

Zitat von Jumpy (Beitrag 1310954)

Das Ganze soll keinem Hacker standhalten sondern verhindern, dass der "normale Sachbearbeiter", also kein anderer Entwickler oder Admin, so einfach an diese Passwörter kommen kann.

Wäre das ein ausreichender Weg und welche Verschlüsselung kann man da einfach nehmen?

na fast egal...

Umsetz Tabelle (Caesar) / Incrementer / Incrementer mit Lauflänge / XOR Tabelle / XOR Tabelle mit PosIncer

Wenn Du noch für die XOR Tabelle den Rechnernamen nimmst, kannst Du die PW Datei sogar für jeden sichtbar machen, da kein Arbeitsplatz mit dem Passwort des anderen funktioniert...

[BUG]

Aus Datenbanklersicht sieht es afaik so aus: Du erstellst für jeden Benutzer (oder zumindest für jede Rolle) einen neuen Datenbankbenutzer. Der hat dann nur die Rechte, die deine Anwendung für diesen Benutzer braucht.
Wenn man es kann, kann man die Anmeldung an der Datenbank oder die Verteilung der Zugangsdaten bestimmt irgendwie in die Domänenverwaltung reinfummeln.

[Union]

Ich hatte gerade vor einger Zeit ein ähnliches Problem und habe es so gelöst:

Delphi-Quellcode:

unit Config.Encoder;

interface

uses
  IdCoderMIME;

type
  TEncoder = class
  private
  class var
    FEncoder : TIdEncoderMIME;
    FDecoder : TIdDecoderMIME;
  public
    class constructor Create;
    class destructor Destroy;
    class function Encode(const AValue : string) : string;
    class function Decode(const AValue : string) : string;
  end;

implementation

{ TEncoder }

class constructor TEncoder.Create;
begin
  FEncoder := TIdEncoderMIME.Create;
  FDecoder := TIdDecoderMIME.Create;
end;

class function TEncoder.Decode(const AValue: string): string;
begin
  Result := FDecoder.DecodeString(AValue);
end;

class destructor TEncoder.Destroy;
begin
  FEncoder.Free;
  FDecoder.Free;
end;

class function TEncoder.Encode(const AValue: string): string;
begin
  Result := FEncoder.EncodeString(AValue)
end;

end.

[BUG]

Das Problem bei diesen Lösungen ist einfach, dass es im Programm eine Verbindung zur Datenbank mit Admin-Rechten gibt.
Im gegebenen Fall (gegen übereifrige Mitarbeiter) mag das noch gehen, im Zweifelsfall übertölpelt ein böswilliger Nutzer das Tool dann doch (SQL-Injektion, Ausführen beliebiger SQL-Kommandos mithilfe eines Debuggers).


Aber klar, ein verschleiertes Admin-Passwort zur Produktivdatenbank ist immer noch besser als es im Klartext liegen zu haben.

[p80286]

vergiß es, "Rolle" ist gut und sollte selbstverständlich sein.

Gruß
K-H

[Jumpy]

Zitat:

Zitat von BUG (Beitrag 1310988)

Das Problem bei diesen Lösungen ist einfach, dass es im Programm eine Verbindung zur Datenbank mit Admin-Rechten gibt.

Da ist natürlich was Wahres dran. Die Benutzen User haben viel mehr Rechte, als für den jeweiligen Zweck nötig wäre. Hier wurde einfach der User genommen, mit dem das eigentliche Programm für das Datenbank XYZ gedacht ist, arbeitet vermute ich mal. Ist auf jeden Fall eine Anregung die man beim Neuaufsetzen des Ganzen mit berücksichtigen kann, da muss aber der DB-Admin mit ins Boot.
Und man muss sich mal schlau machen, wieweit genau man so Rechte definieren kann, denn Verändern einer Tabelle könnte u.U. schon zuviel Rechte bedeuten, da evtl. nicht alle Felder der Tabelle für diesen neu angelegten User veränderbar sein sollen.

[Sir Rufo]

Wenn du es so richtig schön sicher haben möchtest, dann wirst du um einen Service (Dienst auf einem Server) nicht herumkommen.

Dieser bietet die zur Verfügung stehenden Funktionen an und führt diese aus. Nur dem Service sind die Passwörter bekannt und die Benutzer identifizieren sich einmal an dem Service.

Allerdings ist das etwas/erheblich mehr Aufwand, als mal eben die Kennwörter zu verschlüsseln. Andererseits kann man auch darüber nachdenken aus der gesamten Anwendung einen (Intranet-)Web-Dienst zu machen. Client-Installationen gibt es dann nicht mehr und sicher ist es, weil die Kennwörter nur auf dem Server liegen.

[Perlsau]

Am sichersten wäre es wohl, wenn jene, die die Paßwörter für die EierlegendeWollmillsausoftware (ELWMS) vergeben, diese irgendwo sicher aufbewahrten, zum Beispiel in einer gut geschützten Paßwort-Datenbank, zu der nur dieser kleine erlauchte Kreis selbst Zugang hat, oder in einer schriftlichen Liste im Safe. Irgendwo notieren muß man sich diese Passwörter, wenn es sich nicht um leicht zu merkende Zeichenketten handeln soll.

Im eigentlichen ELWMS bzw. der dazugehörigen Datenbank werden letztlich nur Hash-Strings abgespeichert, die aus Passwort und Benutzername erzeugt werden. Gibt der Anwender dann Benutzername und Paßwort richtig ein, wird daraus wieder derselbe Hash berechnet und in der Tabelle gesucht, ob er dort existiert. Neue Benutzer können dann natürlich nur von diesen wenigen Berechtigten angelegt werden. Hash-Strings können nicht zurückgerechnet werden, so daß aus dem Hash-Wert niemand die einzugebenden Zeichenketten ermitteln kann. Der Hash-Wert selbst nützt dem potentiellen Datendieb auch nichts, denn er muß ja Benutzername und Passwort eingeben, um die Funktionalität des Programms nutzen zu können.

Selbstverständlich solllte der direkte Zugriff auf die Datenbank, z.B. via Datenbank-Manager (IbExpert, SQL Server Manager usw.) ebenfalls gut gesichert sein. Wie das bei den einzelnen DBMS gelöst ist, muß du allerdings selber ermitteln. Firebird z.B. erlaubt keinen echten Schutz der Datenbank-Datei vor fremden Zugriffen, denn jeder, der sich dieser Datei bemächtigen kann, ist in der Lage, diese auf einem eigenen Firebirdserver zu öffnen. Werden ihm Rechte bei der Änderung von Datensätzen und/oder DB-Strukturen verwehrt, kann er das einfach umgehen, indem er ein Backup (fbk) dieser DB-Datei erzeugt und mit selbigem via Restore und eigener Benutzer- und Passwort-Kombination wieder ein FDB-Datei erzeugt, die danach aller Beschränkungen beraubt ist.

[p80286]

u.U. ist eine weitere Möglichkeit, die notwendige Funktionalität über views zu erreichen. Die entsprechenden Zugriffsrechte werden genau hierfür vergeben.

Gruß
K-H

[Jumpy]

Zitat:

Zitat von Sir Rufo (Beitrag 1310998)

Wenn du es so richtig schön sicher haben möchtest, dann wirst du um einen Service (Dienst auf einem Server) nicht herumkommen.

Dieser bietet die zur Verfügung stehenden Funktionen an und führt diese aus. Nur dem Service sind die Passwörter bekannt und die Benutzer identifizieren sich einmal an dem Service.

Allerdings ist das etwas/erheblich mehr Aufwand, als mal eben die Kennwörter zu verschlüsseln. Andererseits kann man auch darüber nachdenken aus der gesamten Anwendung einen (Intranet-)Web-Dienst zu machen. Client-Installationen gibt es dann nicht mehr und sicher ist es, weil die Kennwörter nur auf dem Server liegen.

Damit verschiebt man das Problem natürlich auf den Service, sprich wo bekommt der seine Passworte her. Da er aber, wie du sagst, auf dem Server läuft (wo keiner der Normalo-Benutzer dran kommt) könnte man es im Klartext z.B. in einer Ini-Datei speichern, die "Sicherheit" käme daher, das erst gar keiner an die Dateien dran kommt.
Wobei ich vermute, das du meinst man soll trotzdem verschlüsseln usw. und das mit dem Service ist eine weitere zusätzliche Stufe der Sicherheit?

Ist auf jeden Fall ein guter Gedanke, den ich wenn mal Zeit ist, umsetzen werde. Wäre auch eine schöne Übung, da ich einen Webdienst bisher nch nicht erstellt habe. Da das ein rein internes Programm ist, eilt es ja auch nicht.

Zitat:

Zitat von p80286 (Beitrag 1311037)

u.U. ist eine weitere Möglichkeit, die notwendige Funktionalität über views zu erreichen. Die entsprechenden Zugriffsrechte werden genau hierfür vergeben.

Kann man den mit Views auch Daten verändern? Die bisherige Anwendung "schießt" im Prinzip nur Datenverändernde SQL-Statements ab.

[Jumpy]

Zitat:

Zitat von Perlsau (Beitrag 1311018)

Am sichersten wäre es wohl, wenn jene, die die Paßwörter für die EierlegendeWollmillsausoftware (ELWMS) vergeben, diese irgendwo sicher aufbewahrten, zum Beispiel in einer gut geschützten Paßwort-Datenbank, zu der nur dieser kleine erlauchte Kreis selbst Zugang hat, oder in einer schriftlichen Liste im Safe. Irgendwo notieren muß man sich diese Passwörter, wenn es sich nicht um leicht zu merkende Zeichenketten handeln soll.

Im eigentlichen ELWMS bzw. der dazugehörigen Datenbank werden letztlich nur Hash-Strings abgespeichert, die aus Passwort und Benutzername erzeugt werden. Gibt der Anwender dann Benutzername und Paßwort richtig ein, wird daraus wieder derselbe Hash berechnet und in der Tabelle gesucht, ob er dort existiert. Neue Benutzer können dann natürlich nur von diesen wenigen Berechtigten angelegt werden. Hash-Strings können nicht zurückgerechnet werden, so daß aus dem Hash-Wert niemand die einzugebenden Zeichenketten ermitteln kann. Der Hash-Wert selbst nützt dem potentiellen Datendieb auch nichts, denn er muß ja Benutzername und Passwort eingeben, um die Funktionalität des Programms nutzen zu können.

Es geht nicht so um die Passwörter der Benutzer, die das Programm nutzen wollen. Da wird die Authentifizierung über den Domäne-Benutzer gesteuert, d.h. er muss sich am Programm genauso anmelden, wie an der Domäne.
Es geht eher darum, dass das Programm intern "wissen" muss, wie es an die verschiedenen Datenbanken dran kommt, und wie/wo man diese Info sicher speichert. Da wäre aber die Idee deiner Passwort-Datenbank (im Gegensatz z.B. zu einer Ini-Datei) eine Alternative.

Zitat:

Zitat von Perlsau (Beitrag 1311018)

Selbstverständlich solllte der direkte Zugriff auf die Datenbank, z.B. via Datenbank-Manager (IbExpert, SQL Server Manager usw.) ebenfalls gut gesichert sein. Wie das bei den einzelnen DBMS gelöst ist, muß du allerdings selber ermitteln. Firebird z.B. erlaubt keinen echten Schutz der Datenbank-Datei vor fremden Zugriffen, denn jeder, der sich dieser Datei bemächtigen kann, ist in der Lage, diese auf einem eigenen Firebirdserver zu öffnen. Werden ihm Rechte bei der Änderung von Datensätzen und/oder DB-Strukturen verwehrt, kann er das einfach umgehen, indem er ein Backup (fbk) dieser DB-Datei erzeugt und mit selbigem via Restore und eigener Benutzer- und Passwort-Kombination wieder ein FDB-Datei erzeugt, die danach aller Beschränkungen beraubt ist.

Die betroffenen Datenbanken (meist Oracle) liegen auf diversen Servern, die afaik abgesichert sind, d.h. da kommt ausser den Admins keiner dran (an das "System" der Datenbank mein ich damit).

[taveuni]

Zitat:

Zitat von Jumpy (Beitrag 1311064)

Es geht nicht so um die Passwörter der Benutzer, die das Programm nutzen wollen. Da wird die Authentifizierung über den Domäne-Benutzer gesteuert, d.h. er muss sich am Programm genauso anmelden, wie an der Domäne.

Eben deshalb gibt es nur eine saubere Lösung. Multitier. Wenn Deine Client Anwendung gestartet wird gibt diese dem Server ausschliesslich den angemeldeten Windowsbenutzer für das Login mit. Der Server (Dienst) überprüft dann via Domänenkontroller ob dieser Windowsbenutzer existiert und ob er in einer oder mehreren (AD-) Gruppen ist welche in Deiner Applikation konfiguriert sind. Diese Gruppen- (Rollen) Rechte können dann kumuliert werden. Auf das Login gibt der Server so die Berechtigungen zurück und der Client handelt entsprechend. Auf diesem Weg muss überhaupt kein Passwort gespeichert werden. Weder auf dem Server noch auf dem Client. Weiterer Vorteil: Die Rechte können so in der Firma via AD konfiguriert werden. Kommt ein neuer Mitarbeiter erhält er einfach vom Administrator die benötigten Rechte. Die Client Applikation kann auf jedem Rechner, VM oder was auch immer via Rollout installiert werden. Der Client muss einzig wissen wohin er sich verbinden soll. usw. usw.

[jobo]

Zitat:

Zitat von Jumpy (Beitrag 1311060)

Zitat:

Zitat von p80286 (Beitrag 1311037)

u.U. ist eine weitere Möglichkeit, die notwendige Funktionalität über views zu erreichen. Die entsprechenden Zugriffsrechte werden genau hierfür vergeben.

Kann man den mit Views auch Daten verändern? Die bisherige Anwendung "schießt" im Prinzip nur Datenverändernde SQL-Statements ab.

Ja, das ist (mindestens bei Oracle) kein Problem. Die Logik allein (und wahrscheinlich auch die Fähigkeiten der DB) gebietet allerdings gewisse Grenzen. Aggregate oder Datenmengen ohne PK, berechnete Felder im Detail usw. lassen sich innerhalb eines Views natürlich nicht updaten.

Es gibt bei Oracle noch eine Reihe weiterer Möglichkeiten.

• Rollen (non default) mit Passwort, kombiniert mit einem Login Mechanismus, der die Rollen aktiviert (set role..).
• aktive Schema Änderung (set schema..)
• Database Links
• diverse Kombinationen davon
• DML per Stored Procs, was auch sehr komplexe Updates erlauben würde. (einhergehend mit Revoke DML auf den Tables direkt)

Dennoch kommst du um eine passable Nutzer/Rollenverwaltung nicht herum. Angenommen, ein AD ist verfügbar (Windows Domäne) bietet sich im Falle von mssql auch trusted login an, was glaube ich auch mit Oracle geht (hab ich aber noch nie gemacht)

[Perlsau]

Zitat:

Zitat von Jumpy (Beitrag 1311064)

Es geht nicht so um die Passwörter der Benutzer, die das Programm nutzen wollen. Da wird die Authentifizierung über den Domäne-Benutzer gesteuert, d.h. er muss sich am Programm genauso anmelden, wie an der Domäne. Es geht eher darum, dass das Programm intern "wissen" muss, wie es an die verschiedenen Datenbanken dran kommt, und wie/wo man diese Info sicher speichert. Da wäre aber die Idee deiner Passwort-Datenbank (im Gegensatz z.B. zu einer Ini-Datei) eine Alternative.

Die Datenbank, die eurem wollmilcheierlegenden Tool zugrunde liegt, sollte ebenfalls dort liegen, wo nur Admins rankommen. Die Zugriffsdaten für die verschiedenen Datenbanken sind dann verschlüsselt in dieser Tool-Datenbank gespeichert. Der Key zum entschlüsseln dieser Daten liegt ebenfalls auf dem Server, oder auch der Key zum Entschlüsseln des Keys usw. Ein Sicherheitsschloß, das Fingerabdruck, Retina und Sprachmuster prüft, erlaubt nur den Administratoren, den Serverraum zu betreten. :lol:

Scherz beiseite, wo ist hier eigentlich das Problem? Das Tool verwaltet Rechte, Passwörter und sonstige Zugangsdaten. Das Tool kann nur von Berechtigten mit der richtigen User-Passwort-Kombination gestartet werden. Werden falsche Zugangsdaten eingegeben, startet das Tool nicht bzw. beendet sich sofort und legt einen Log-Eintrag an. Ich halte das für einfacher als die Domänenverwaltung von Windows zu bemühen. So wäre z.B. auch sichergestellt, daß nicht ein Unbefugter das Tool startet, während der Domänen-Besitzer gerade auf der Toilette ist – der sollte natürlich vor dem Klogang stets das Tool sperren oder beenden.

[jobo]

Zitat:

Zitat von Perlsau (Beitrag 1311090)

der sollte natürlich vor dem Klogang stets das Tool sperren oder beenden.

Das übliche Verfahren ist wohl, den gesamten Rechner zu sperren, wenn man den Arbeitsplatz verlässt. Das geht auch konform mit der Trusted Login Nutzung. Müsste man jedes Tool einzeln sperren, ist ja die Pause rum, bis man mit Sperren fertig ist.

[BUG]

Zitat:

Zitat von jobo (Beitrag 1311079)

Die Logik allein (und wahrscheinlich auch die Fähigkeiten der DB) gebietet allerdings gewisse Grenzen. Aggregate oder Datenmengen ohne PK, berechnete Felder im Detail usw. lassen sich innerhalb eines Views natürlich nicht updaten.

Mit entsprechenden Triggern lässt sich aber viel machen.

Im Prinzip kann man mehrere getrennt entwickelte Anwendungen mit einer gemeinsamen Datenbasis betreiben, wobei alle ein anderes Tabellenlayout sehen. In der Praxis ist das Performance-technisch vermutlich nicht die Lösung ... andererseits kann ein größerer Datenbankserver auch weniger Kosten als eine Neuentwicklung der beteiligten Anwendungssoftware.

Zitat:

Zitat von Perlsau (Beitrag 1311090)

erlaubt nur den Administratoren, den Serverraum zu betreten. :lol:

Der Dolch der DB-Admins ist auch nicht nur für zeremonielle Zwecke :stupid:

Auch Scherz beiseite: Der Inhalt einer Datenbank kann gut und gerne über den Bestand einer Organisation entscheiden. Nur Admins in den Serverraum zu lassen ist genauso berechtigt wie den Zugriff auf die Finanzmittel einzuschränken.