Passwort "hard codieren": Beste Lösung?

[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.

Gibt es hierzu eine best-practice? Einfachste Variante wäre natürlich, das Passwort direkt als Konstante in den Code zu schreiben. Etwas besser wohl, es erst durch eine Funktion während der Laufzeit zu erzeugen (bspw. MD5). Die Kommunikation ist mit SSL verschlüsselt, somit reicht die Basic-Auth. für meinen Bedarf aus.

[Klaus01]

.. ich denke für das Problem gibt es keine beste Lösung, nur viele schlechte.
Ich halt nichts davon Userkennungen im Source festzulegen.

Wenn ein User mit dem System arbeiten will, kann er/sie auch die Kennungen eingeben.

Grüße
Klaus

[DieDolly]

Weitere Ideen:
das Passwort erst gar nicht in die EXE schreiben
das Passwort verschlüsselt in die EXE schreiben. Der Benutzer muss dann nur den Schlüssel zum entschlüsseln eingeben.

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

Aber ich bleibe dabei. Passwörter haben nichts in einer EXE zu suchen.

[peterbelow]

Zitat:

Zitat von rhuber (Beitrag 1428859)

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.

Gibt es hierzu eine best-practice? Einfachste Variante wäre natürlich, das Passwort direkt als Konstante in den Code zu schreiben. Etwas besser wohl, es erst durch eine Funktion während der Laufzeit zu erzeugen (bspw. MD5). Die Kommunikation ist mit SSL verschlüsselt, somit reicht die Basic-Auth. für meinen Bedarf aus.

Ich hab sowas (accounts/password die der Benutzer normalerweise nicht kennt oder kennen soll) immer mit einer externen, verschlüsselten Datei gelöst, in der die Zugangsdaten stehen. Das Programm enthält dann zwar den Schlüssel für die Datei, aber das ist einfach eine Folge von 128 bytes (ursprünglich durch Verkettung von GUIDs erzeugt) und kein Text, also nicht so ohne weiteres zu finden, wenn man sich die Exe in einem hex-editor ansieht.
In meinem Fall lag die Datei im Firmennetzwerk an einer "bekannten" Stelle und konnte von diversen Anwendungen verwendet werden. Falls das in deinem Fall unpraktikabel wäre kannst Du die Datei auch als Resource in die Anwendung einbinden.

[Sherlock]

So ist es.
Es kann kein "Muß" geben, eine Sicherheitslücke (großen Ausmaßes btw) zu implementieren. Darum muß halt Benutzer und Kennwort zur Laufzeit abgefragt werden.

Vernünftige Betriebssysteme erlauben übrigens auch folgendes Verfahren:
Credentials kann man in einer entsprechenden Datei ablegen, die nur der User, in dessen Kontext die Applikation läuft, auslesen kann. Das geht unter Windows nicht? Komisch.

Sherlock

[rhuber]

Danke euch für die Antworten! Ja, sauber ist es sicher nicht, das gilt aber meines Erachtens für die Basic-Authentication allgemein. Digest-Auth. wäre mir lieber, leider unterstützt dies Synapse aber nicht.

Es geht darum, mit möglichst minimalem Aufwand die aktuelle Lösung etwas sicherer zu machen. Bei dieser ist der Datenverkehr zwar SSL-verschlüsselt, der Hash zur Authentifizierung des Benutzers wird aber als Parameter in der URL übergeben. Die URL inkl. Hash könnte man somit einfach im Browser eingeben, was sicher nicht ideal ist. Mit einer Basic-Auth. und einem allgemein gültigen PW wäre dies schon mal etwas entschärft, ohne den Server gross umbauen zu müssen. Natürlich würde ich im Client dann das PW mittels einer Hash-Funktion erst während der Laufzeit erzeugen.

[franktron]

Mann könnte doch auch den Benutzernamen und das Passwort zur laufzeit erzeugen.

[Neutral General]

Zitat:

Zitat von franktron (Beitrag 1428877)

Mann könnte doch auch den Benutzernamen und das Passwort zur laufzeit erzeugen.

Und wie erzeugt man einen Benutzernamen + Passwort für einen (3rd Party) Webservice zur Laufzeit?

[Andreas13]

Ich benutze einen stark modifizierten Ansatz nach dem Buch: Doberenz + Kowalski: Borland Delphi 7 – Kochbuch (2003) S. 894-895.

Erstelle dazu zwei Routinen:

Delphi-Quellcode:

Function String_Verschluesseln(S: Str255): AnsiString; // Hexadezimal-String-Array

Delphi-Quellcode:

Function String_Entschluesseln(SS: AnsiString): Str255;

Für die Ver- und Entschlüsselung benutze einen Zufallszahlen-Generator, dessen Zufallsfolge Du selber festlegen kannst (= eindeutig reproduzierbar) z.B. über

Delphi-Quellcode:

System.RandSeed:= MeinGeheimCode;

MeinGeheimCode ist üblicherweise eine LongInt-Zahl z.B.

Delphi-Quellcode:

CONST
  MeinGeheimCode:= 123456789;

Damit erstellst Du einen langen Vektor

Delphi-Quellcode:

VAR
  SuperKey: Array[1..KeySize] of Byte;

KeySize kann z.B. 1000 oder länger sein.

Diesen füllst Du mit zufälligen Bytes z. B. bei

Delphi-Quellcode:

System.RandSeed:= 0;

mittels obigen Zufallszahlen-Generator und verschlüsselst Du Dein Passwort aus den Zeichen des SuperKey-Arrays bei

Delphi-Quellcode:

System.RandSeed:= MeinGeheimCode;

Im Programm musst Du nur die zwei an und für sich harmlosen Konstanten speichern:

1): Das verschlüsselte Passwort als Hexadezimale String-Constante ab z. B:

Delphi-Quellcode:

Const
 MeinGeheimPasswort ='168AEEAF481AE6E2911D8E1EB1F7A9CCBCE145A2E0AFC1';

2):

Delphi-Quellcode:

CONST
  MeinGeheimCode:= 123456789;

Vorsicht! Im Programm musst Du mindestens einmal einen Zugriff auf diese Konstanten machen, damit Delphi’s Optimierer sie nicht aus dem Code rauschlöscht.

Wichtig ist beim Zufallszahlen-Generator, daß Du den kompletten Quellcode dazu hast, weil Delphi’s Zufallszahlen-Generatoren sich manchmal von Version zu Version sich unterscheiden und daher nicht kompatibel (reproduzierbar) sind!
Gute Zufallszahlen-Generatoren, aber auch komplette Verschlüsselungsroutinen findest Du z.B. bei

https://sslsites.de/wolfgang-ehrhardt.de/index_de.html

Gruß, Andreas

[generic]

Sind Server und Client in der gleichen Domäne?

Wenn ja, Windows-Authentifizierung des Rechner Kontos oder des Benutzerkontos, welche den Client ausführt.
Dann brauchst du gar keine Passwörter speichern.

Wenn nicht über einen OAuth-Server ein Token anfordern und der OAuth-Server macht die Windows-Authentifizierung.

Wenn das auch nicht geht, über Kerberos dürfte es sicherlich auch noch etwas geben.