Geheime Daten einbinden

[negaH]

Sorry ich sehe gerade das da ein Fehler drinnen ist.

Zitat:

In der User-DB stehen alle registrierten Benutzer U, deren gehashtes Password Ph = H(P), und das mit diesem gehashten Ph verschlüsselte Passwort für Daten-DB -> Pd = C(D, Ph) !

Dies ist natürlich schwachsinnig, da ja Ph = H(p) und Pd = C(D, Ph) beide in der User-DB gespeichert sind wird es nun einfach für den Angreifer das D zu berechnen. Denn das Passwort Ph zur Entschlüsselung D = E(Pd, Ph) wird dem Angreifer der die User-DB lesen kann gleich frei Haus geliefert. Man muß dies absolut vermeiden und es sollte so aussehen:

In User-DB stehen U,Pv=H(P),s,Pd=C(D, H(s + P))
wobei
U = Username
Pv = H(P) = Passwordverifier zur Überprüfung des Passwortes
s = ein Zufallssalt, sprich z.b. 20 Bytes Zufallszahlen
Pd = C(D, H(s + P)), das verschlüsselte Data-DB Passwort D das mit H(Salt + Password) verschlüsselt wurde.

Diese sehr einfache Verfahren ermöglicht aber trotzdem bestimmte Angriffe. Um diese zu elimieren muß man dann schon echte mathematische "Public Key" Verfahren benutzen.

Gruß hagen

[czapie]

@Peter Lustig

Ist absolut richtig, gerade bei einer so "bekannten" Variante, wo ich weiß, dass dort irgendwo das password steckt, ist eine Veränderung tödlich
Mit Veränderung mache ich dan aben ein paar Hundert durchläufe und gucke was immer gleich geblieben, ist dann dauerts nicht mehr lange bis ich das PW habe.

Czapie.

[Jelly]

Hi,

aus all dem was ich bis jetzt gelesen hab, werd ich, um einen sichere Lösung zu finden, nicht um ein asymetrisches Verfahren kommen. Das ist aber sicherlich überdimensioniert für mein Problem.

Mir ist die Lösung von Hagen zwar ganz klar, und ist auch umsetzbar. Aber sie hat die gleich Sicherheitslücke, die eben nicht zu umgehen ist, nämlich irgendwo im Quelltext oder sonstwo muss ein unverschlüsseltes Passwort verankert sein. Bei Hagens Lösung ist dies das Passwort für die DB_User Datenbank.

Aber vielen Dank für die Anregung,

Gruss,
Tom

[negaH]

Zitat:

Mir ist die Lösung von Hagen zwar ganz klar, und ist auch umsetzbar. Aber sie hat die gleich Sicherheitslücke, die eben nicht zu umgehen ist, nämlich irgendwo im Quelltext oder sonstwo muss ein unverschlüsseltes Passwort verankert sein. Bei Hagens Lösung ist dies das Passwort für die DB_User Datenbank

Dies ist aber nur die leichter knackbare Hürde und bestimmt nicht die Sicherheit meines Vorschlages. Rein theoretisch könnte man die User_DB auch ungeschützt lassen, sie darf eben für normale User nur ReadOnly sein.

Wichtig an meinem Vorschlag ist es das der gültige Benutzer über seinen Benutzernamen und Passwort Zugriff auf die geschützte Daten_DB erlangt. Nur berechtigte Benutzer können diese DB öffenen.
Somit ist die Daten_DB sicher, und kann nur für berechtigte Benutzer mit korrektem Passwort geöffnet werden.

Gruß Hagen

[nailor]

um ein passwort zu verstecken: sehr sicher ist z.b. hardcoden mit nachträglicher bearbeitung. mach ne funktion, die als result das korrekt passwort liefert. dort speicherst du die ascii-codes des passwortes ab (eventuell noch ascii * 3, beim entschlüsseln dann durch 3), der dann in den string umgewandelt wird. strings werden "offensichtlich" in der exe hinterlegt, irgendwelche byte-variablen-arrays nicht... pass auf, dass die codeoptimierung die funktion nicht optimiert! so kommt man ohne abartigen disassembler-gebrauch nicht an das passwort.

Michael

PS: wenn jemand den traffic mitprotokolliert, könnte man das pw dort abfangen ?!?!

[Jelly]

Wegen des Traffic mach ich mir keine Sorgen. Die Mühe lohnt sich nicht denk ich.

Gruss,
Tom

[ExZtEd]

Entschuldigung das ich den Thread wieder ausgrabe, aber ich stehe genau vor demselben Problem der Datenverschlüsslung für den Zugriff auf eine DB.
In meinem Fall muss der Zugriff auf die DB sicher sein, da eine große Menge an User darauf zugreifen sollen.

Die Vorschläge hier sind auch von der Sicherheit auf "Datei-Ebene" passabel, aber wie schaut es zur Laufzeit aus?
Während die Anwenung läuft wird ständig das DB-Passowort benötigt und liegt demzufole in einer VAR.
Bei einem Speicherabbild würde dieses dann doch wider UNVERSCHLÜSSELT sein!?

Der Delphi-Komponente die für die Datenbankverbindung benötigt wird, muss ja das Passwort unverschlüsselt übermittelt werden zur Laufzeit.
Wie kann gewährleistet werden das jenes Passwort auch zur Laufzeit noch sicher ist?

Oder sehe ich vor lauter Paranoidität, die vogeschlagene Sicherheit nicht?

[nailor]

wie negah schon gesagt hat: entweder du baust eine weitere ebene (den login-server ein), oder du musst mit der tatsache leben, dass das passwort irgendwann mal lokal verfügbar sein muss. (wenn auch nur zur laufzeit im speicher).

[supermuckl]

ich will ja nix sagen.. aber vor lauter password verschlüsselung.. ist euch schonmal in den sinn gekommen das man das password im klartext über einen packetsniffer lesen kann ?

wenn dann müsste man halt das ganze ding in eine sichere kapselung packen die dann so sicher ist das auch z.b. public key verfahren eingesetzt werden

oder einfach nur IPsec/VPN ^^

wobei das dann nur für "hacker" abschreckend wirkt und die user die mit der db arbeiten immernoch sniffen können....

[nailor]

ja, wurde schon erwähnt, dass das geht