ubuntuusers.de

Hallo,

ich habe eine kurze Frage zur Speicherung von Passwörtern auf einem Server und einem Clienten, egal welches Programm/Protokoll/was-auch-immer. Angenommen ich richte ein Programm auf einen Server ein Programm ein auf das ich von einem Clienten zugreife und sichere es mit einem einfachen Passwort. Das Passwort muss ja irgendwie lesbar auf dem Server gespeichert werden. Es wird wohl kaum in einer für alle lesbare Textdatei im Klartext stehen. Soweit ich das verstehe wird das hier - vereinfacht - als Hash gespeichert. Wenn ich bei der Einrichtung des Server das PW "Passwort" festlege wird von "Passwort" ein Hash-Wert erstellt und nur dieser gespeichert. Selbst wenn das jemand auf dem Server im Klartext sieht kann er nicht einfach einen "Rückwärts-Hash" machen. Gebe ich das Passwort am Clienten ein wird daon ein Hash erstellt, dieser mit den gespeicherten Hash verglichen und fertig. Ist das grds. einmal so korrekt?

Es gibt nun aber Client-Programme (z. B. Remmina für VNC oder NetworkManager mit dem WLAN-Passwort) die ein Passwort am Clienten speichern. Hier geht das mit Hash ja nicht. Hier kann ein Passwort nur sicher gespeichert werden, wenn es z. B. durch ein Master-PW gesichert ist, was wieder eine aktive Eingabe des Nutzern macht. Remma und NM machen das aber nicht. Ist hier das Passwort demzufolge irgendwo im Klartext hinterlegt? Ich kann mir einen Mechanismus vorstellen wie man am Clienten ein Passwort speichern kann, das nicht im Klartext zu erkennen ist und dann dennoch ohne Nutzeingabe (Entsperren des Passwort-Managers) übermittelt werden kann. Ist das so korrekt?

Einzig vielleicht:

• ein PW ist in einer Datei als Klartext gespeichert die ein User nicht lesen darf

• ein Client kann vom Nutzer gestartet werden hat aber das Recht auf die Datei lesend zuzugreifen

Mir ist das nur mal bewusst geworden als ich einen VNC-Clienten getestet habe der keine Speichermöglichkeit für das Passwort bietet. Da stellte sich mir die Frage wie das andere Programme machen - oder eben nicht machen

Ja, den Hash-Mechanismus hast Du im Prinzip korrekt beschrieben. Es gibt unterschiedliche hashing-Formate und zus. salt.

NM speichert WLAN-Kennworte per default im Klartext in Dateien unter /etc/NetworkManager/system-connections in der Variablen psk.

Remmina speichert PWs in /home/${USER}/.local/share/remmina/ (allerdings in gehashter Form).

HTH.

steamywindows schrieb:

Remmina speichert PWs in /home/${USER}/.local/share/remmina/ (allerdings in gehashter Form).

Und genau das verstehe ich nicht. Ichbkann ein Passwort hashen, dann ist es aber auch für mich nicht mehr lesbar weil es den Rückweg ja nicht gibt. Wenn jetzt remmina "Passwort" als hash speichert und irgendwann "Passwort" übertragen muss wie bekommt es aus dem hash das richtige Passwort?

Ein Hashen auf Client und Server ergibt für mich keinen Sinn. Soweit ich das verstehe, übermittel der Client (oder Nutzer) ein ungehashtes Passwort. Der Server hasht das dann und vergleicht es mit seiner Datenbank gehashter Passwörter und erlaubt bei Übereinstimmung Zugriff. Das ungehashte Passwort soll dabei nicht gespeichert werden. Natürlich kann man eine Art Masterpasswort verwenden, welches für jeden Server durch ein Hashverfahren in ein anderes Passwort erstellt.

Eine Alternative ist ein asymmetrisches Verschlüsselungsverfahren mit öffentlichem und privatem Schlüssel. Dabei liegt auf dem Server nur der öffentliche Schlüssel, der nicht geheimgehalten werden muss. Bei beiden Verfahren bleibt aber das Problem der automatischen Authentifizierung durch den Client. Werden Passwort/privater Schlüssel lokal gespeichert, können sie prinzipiell bei einem Angriff auf den Client auch gestohlen werden.

Genau da liegt mein Verständnisproblem. Wenn ein client ein Passwort hashed muss es das ja dennoch das ungehashte passiert übertragen. Demnach muss es den hash "zurückhashen" was wiederum heißt jeder andere könnte das tun.

Wäre es, wie oben beschrieben, möglich ein PW in eine für den user nicht lesbare Datei zu packen und den clienten Zugriff auf diese Datei zu geben? zum bsp. über eine Gruppenzugehörigkeit oder so?

Schlüsselpaar können z. B. die mir bekannten vnc-server nicht.

Was ist Dein Ziel genau? Du kannst das Passwort z. B. in einer verschlüsselten Datei speichern, die nur von root entschlüsselt werden kann. Trotzdem liegt das Passwort dann während des Betriebs auch entschlüsselt im Arbeitsspeicher vor.

Ich möchte gern wissen ob/wie es möglich ist ein Passwort am Clienten zu speichern für einen Auto-Login und dennoch das Passwort für einen normalen User nicht lesbar zu haben. Falls das überhaupt geht.

Du kannst das Passwort z. B. in einer verschlüsselten Datei speichern, die nur von root entschlüsselt werden kann. Trotzdem liegt das Passwort dann während des Betriebs auch entschlüsselt im Arbeitsspeicher vor.

Das mit dem Arbeitsspeicher lässt sich vermutlich nicht vermeiden. Wenn nur root darauf zugreifen kann, kann auch das entsprechende Client-Tool die Datei nicht lesen?

Was mich wieder auf das oben genannte bringt: wäre es möglich den Clienten mit Leserechten zu starten, der den Zugriff auf die PW-Datei erlaubt?

Wenn Dir die "normale" Sicherheit des Betriebssystems reicht, musst Du das Passwort nur so abspeichern, dass es für den User des Clients lesbar ist, für andere User des Systems aber nicht.

Obwohl lokale Speicherung und Übertragung von Passworten im Klartext möglich und auch noch immer verwendet wird, gelten diese beiden Methoden als veraltet.

Zur lokalen Speicherung von Passworten verwendet man üblicherweise einen Passwort-Tresor oder keyring. in diesem liegen die Passworte verschlüsselt vor und sind erst nach Eingabe eines Master-Passwortes lokal verwendbar.

Der Linux-Kernel hat so einen keyring, eben den kernel-keyring für seine Bedürfnisse, der Gnome-Desktop hat den gnome-keyring zur sicheren Speicherung der Passworte des Benutzers, andere Desktops werden über ähnliche Mechanismen verfügen. Man kann solch einen keyring für den Benutzer auch durch externe Programme wie KeypassXC realisieren und Firefox hat so etwas auch eingebaut. In der Regel lebt man aber mit dem im Hintergrund automatisch arbeitenden gnome-keyrng bei Ubuntu-Desktop-Systemen sehr gut und sicher.

Bei Übertragung über ein unsicheres, weil abhörbares Medium wie das Internet vermeidet man Klartext-Passworte, sondern wendet das RSA-Kryptosystem (ab 1977) an, welches auf der automatischen abhörsicheren Aushandlung asymmetrischer Schlüsselpaare nach Whitfield Diffie und Martin Hellman (1976) beruht und in einschlägigen Lehrbüchern und in Wikipedia nachlesbar ist.

Es gibt funktional vergleichbare Varianten zu RSA und Erweiterungen um neuere Methoden zur Schlüsselerzeugung, das funktionale Prinzip nach Diffle/Hellman ist aber gleich geblieben.

kB schrieb:

Obwohl lokale Speicherung und Übertragung von Passworten im Klartext möglich und auch noch immer verwendet wird, gelten diese beiden Methoden als veraltet.

Auch in einem Passwort-Tresor gespeicherte Passwörter liegen nach der Entschlüsselung im Klartext vor. Werden Passwörter verschlüsselt übertragen liegen sie beim Empfänger am Ende ebenfalls im Klartext vor. Die Verschlüsselung bei Lagerung und Transport erhöht zwar die Sicherheit bzgl. bestimmter Aspekte ändert aber nichts am Grundproblem von Klartext Passwörtern. Erst asymmetrische Verschlüsselung ändert hier grundsätzlich den Bedarf Passwörter als solche zu übertragen.

Thomas_Do schrieb:

[…] in einem Passwort-Tresor gespeicherte Passwörter liegen nach der Entschlüsselung im Klartext vor.

Ja natürlich. Nach einer Entschlüsselung (und übrigens auch vor der Verschlüsselung) hat man Klartext.

Allerdings entschlüsselt ein guter Passwort-Tresor bei der Überprüfung eines ihm vorgelegten Passwort gar nicht das in ihm verschlüsselt gespeicherte Passwort, sondern verschlüsselt den ihm vorgelegten Klartext und vergleicht dann die beiden verschlüsselten Texte auf Gleichheit. Ein guter Passwort-Tresor gibt unter keinen Umständen preis, welche Klartexte in ihm gespeichert sind.

Vielleicht doch mal bei Diffle/Hellman nachlesen, wie es funktioniert und nachdenken, warum diese pfiffige Methode sicher ist?

Hallo Fried-rich,

mit deiner Frage scheidest du ein großes Thema an. Zum Einstieg ist hier sicher das Wiki zu empfehlen.

Aber als Anhalt kann man festhalten:

• Ein Prüfen aus Legalität erfolgt "serverseitig" (wer sich immer zu diesem Zeitpunkt als Server fühlen darf).

• Auf dem Server werden die Passworte in der Regel als Hashwert (Digest=unidirektionale Verschlüsselung) gespeichert. Damit diese nicht zu schnell reverse enginieered werden können, wählt man längere Schlüssel (z.B. SHA512 statt SHA1) und SALT (um den gleichen Hash in unterschiedlicher binärer Form zu speichern).

• Von der Client Seite wird das Passwort in lesbarer Form gesendet. Dies kann ein Klartext-Passwort sein, das in der Regel in einem verschlüsselten Paket transportiert wird um zu verhindern, dass ein Sniffer einfach in den Besitz des Klartext-Passworts gelangt. Sobald die Authentisierungs-Phase abgeschlossen ist, identifiziert man sich aber über einen Session-Key, der dann natürlich auch wieder verschlüsselt wird und ein Gültigkeitszeitraum hat (siehe LTPA, Kerberos Ticket usw.).

• Ist es erforderlich, auf Client Seite das Passwort abzuspeichern, damit man es in "Klartext" senden kann, verwendet man bidirektionale Verschlüsselungen (z.B. AES usw), die einem den verschlüsselten Inhalt wieder in Klartext wandeln können.

• Bei dieser Verschlüsselung verwendet man in der Regel asymmetrische Schlüssel (z.B. wie bei PGP oder S/MIME) oder symmetrische Schlüssel (z.B. bei der Transportverschlüsselung).

  • Asymmetrische Schlüssel sind langlebiger und groß sowie CPU aufwendig in der Anwendung. Sie werden in der Regel verwendet, um einen symmetrischen Schlüssel zu verabreden. Der asymmetrische Schlüssel hat einen privaten Teil, der nicht veröffentlicht werden darf und einen öffentlichen Teil, der verwendet wird, um eine mit dem privaten Key verschlüsselte Nachricht wieder in Klartext umzuwandeln. Eine mit dem öffentlichen Key verschlüsselte Nachricht kann nur mit dem private Key wieder in Klartext gewandelt werden. Um den privaten Teil des Schlüssels zu verwenden, ist in der Regel ein Passkey einzugeben, der diesen Schlüsselteil aktiviert.

  • Symmetrische Schlüssel sind klein (kurz) und benötigen weniger CPU Leistung bei der Anwendung. Aus diesem Grund werden sie für schnellen Informationsaustausch verwendet. Da sie leichter crackbar sind, werden sie in der Regel nach kurzer Zeit durch neue Schlüssel ausgetauscht. Da diese Schlüsselart nur zwischen 2 Partnern verwendet wird, nutzt das Kerberos System Ticket-Granting-Server, die von zentraler Stelle derartige Tickets ausgeben.(Beispiel: Client A fragt TGS mit einem TGT nach einem Ticket, um mit Server B kommunizieren zu können)

In der Regel nutzt man stets eine Kombination aus asymmetrischen und symmetrischen Schlüsseln und die Vorteile des jeweiligen Systems verwenden zu können.

Es gibt sehr viele Algorithmen zur Verschlüsselung und noch mehr Speicherarten. Zur Einführung in dieses Thema lohnt es wirklich, sich mit "openssl" auseinander zu setzen. Auch wenn dies eine sehr oberflächliche Einführung ist, kann sie dir aus meiner Sicht weiter helfen.

Bei einer Frage nach "Kryptologie" in der Suchmaschine der Wahl erhältst du genügend weiterführende Informationen (z.B. die Fibel "Kryptologie für Jedermann").