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 von 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, 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 von Jumpy:

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