Passwort "hard codieren": Beste Lösung?

[timog]

Und vielleicht noch einen Blick auf den Wrapper werfen, der hier schon mal diskutiert wurde.

[rhuber]

@Andreas13: Danke, das sieht sehr interessant aus! Ist es von der Sicherheit her aber nicht dasselbe, wenn ich zwei Zeichenfolgen hart codiere und aus diesen dann einen einzelnen Hash erzeuge, der dann als PW genutzt wird? Oder liegt der Clou darin, dass der Angreifer nicht rausfinden kann, wie verschlüsselt wurde?

@generic: Nein, der Client wird auf irgend einem Rechner in einem unbekannten Netzwerk mit Internetzugang ausgeführt, der Server steht bei uns. Mit dem Client schreibt/liest der Benutzer Daten in/aus einer MySQL-Datenbank auf dem Server. Lokal beim Benutzer darf/kann nichts gespeichert werden.

[mjustin]

Direkt im Code der Anwendung ist ungünstig wenn das Password später mal geändert werden muss.

Stattdessen kann es z.B. in einer stark verschlüsselten Konfigurationsdatei gespeichert werden.

"For outbound authentication: store passwords outside of the code in a strongly-protected, encrypted configuration file or database that is protected from access by all outsiders, including other local users on the same system. Properly protect the key (...). If you cannot use encryption to protect the file, then make sure that the permissions are as restrictive as possible."

Quelle: http://cwe.mitre.org/data/definitions/259.html

p.s.:
Das ist wegen der Einschränkung

Zitat von rhuber:

Lokal beim Benutzer darf/kann nichts gespeichert werden.

auch keine Lösung.

[dummzeuch]

Zitat von DieDolly:

Ich würde es jedenfalls erst gar nicht in die EXE schreiben.
Oder vielleicht gehasht. Dann aber kein MD5 sondern SHA256 oder besser.

Gehasht funktioniert nicht, denn er muss das Password ja an den Server weitergeben.

[Neutral General]

@Andreas13: Bringt unterm Strich auch nicht viel. Ich kann mich ohne Probleme mit nem Debugger dranhängen und nach dem Entschlüsseln einfach in den Speicher schauen was da steht.
Letztendlich ist die einzig wahre Lösung, dass der Benutzer die Daten eingeben muss - was aber natürlich je nach Fall nicht wirklich sinnvoll ist. In so einem Fall kann man unterm Strich nicht verhindern dass sich jemand die Daten aus der Exe schnappt.

[dummzeuch]

Zitat von Neutral General:

@Andreas13: Bringt unterm Strich auch nicht viel. Ich kann mich ohne Probleme mit nem Debugger dranhängen und nach dem Entschlüsseln einfach in den Speicher schauen was da steht.
Letztendlich ist die einzig wahre Lösung, dass der Benutzer die Daten eingeben muss - was aber natürlich je nach Fall nicht wirklich sinnvoll ist. In so einem Fall kann man unterm Strich nicht verhindern dass sich jemand die Daten aus der Exe schnappt.

Theoretisch kann der Benutzer natürlich auch nicht das eigentliche Password eingeben sondern eines, das zum Entschlüsseln dieses Passwords verwendet wird. Dann muss man zumindest das Password des Benutzers kennen, um mit dem Debugger an das eigentlich Password zu kommen.

Aber ob das wirklich so viel besser ist? Kommt halt auf das Szenario an.

[DieDolly]

Wer an das Passwort will, kommt dran und bekommt es auch im Klartext. Über sowas würde ich mir gar nicht erst den Kopf zerbrechen. Den ultimativen Schutz gibt es nicht und wenn doch, wird er Millionen von Euros kosten.

[Rollo62]

Zitat:

Muss in einem Tool (fat-client, der mit einem Server über die REST/http-Schnittstelle kommuniziert) Benutzername und Passwort "hart" codieren.

Könnte man die REST-Schnittstele erweitern, bzw. ergänzen ?
So das z.B. mit festem Passwort kommt man nur auf eine Authorisierungs-Seite,
und von da kannst du z.B. Zertifikate, Token, etc. austauschen ?

Erst im 2. Schritt kommt man dann auf die richtige REST-Schittstelle.

Das könntest du deine Sicherheits-Stufe nach Belieben selber bestimmen (2FA, OAuth, etc.).

[generic]

Zitat von rhuber:

Hallo zusammen
Muss in einem Tool (fat-client, der mit einem Server über die REST/http-Schnittstelle kommuniziert) Benutzername und Passwort "hart" codieren. Also direkt im Code, damit ich eine einfache http-Basic Authentication realisieren kann.

Ich finde ein Passwort zu hinterlegen immer nicht gut.
Da der Server öffentlich erreichbar ist, hast du natürlich Interesse dran, dass nicht jeder die Schnittstellen nutzt - der soll der Client sich authentifizieren.
Die Frage ist was sich genau authentisieren soll?
Der Benutzer des Clients, die Client-Software oder vielleicht sogar den Client PC.

Je nachdem ergibt sich dann, dass z.B. jeder der die Client-Software hat, den Server nutzen kann.
Oder jemand der Zugriff zu dem PC hat...
Oder die eine Person

Eine weitere Überlegung von mir ist, wird ein Change-Tracking der Daten auf dem Server durch geführt. Also wer hat was geändert.

Damit dürfe sich das auf den Benutzer beschränken.

Daher glaube ich, dass ihr ein OAuth-Server nutzen solltet.
Der Benutzer/der Berechtigte kann sich, dann einmal anmelden und ein Token wird im Client gespeichert.

Dieses wird dann zur Authentifizierung gegen den REST-Endpunkt genutzt.

Vorteil das Token kann entzogen werden und ggf. durch erneute Anmeldung einfach erneuter werden.
Das Passwort würdest du aus dem Client nur mit einen Release ändern können.
Du solltest davon ausgehen, dass es kompromittiert werden kann bzw. du es nach BSI Empfehlung sowieso alle 90 Tage ändern solltest.