Wie kann man Benutzerpasswörter in Linux als Klartext anzeigen lassen?

28

Wir wissen, dass die Passwörter der Benutzer /etc/passwdin verschlüsselter Form gespeichert werden, so dass selbst der Root sie nicht sehen kann:

jane:x:501:501::/home/jane:/bin/bash
fred:x:502:502::/home/fred:/bin/bash

Stellt wie oben gezeigt :x:das Passwort dar.

Gibt es eine Möglichkeit (mögliche Konfiguration), das Passwort im /etc/passwdKlartext so zu speichern, dass der Root sie sehen kann?

password

— user78050
quelle

10

Und das ist ein Feature. Es gibt auch keinen wirklichen Grund dafür, da das Root-Konto kein Benutzerpasswort benötigt, um auf seine Dateien zuzugreifen. Unter welchen Umständen möchten Sie das?

— HalosGhost

1

Ich bin nur neugierig, warum kann der Administrator (der Root) des Systems die Passwörter anderer Benutzer nicht sehen?

— User78050

5

@ user78050, da der Root-Benutzer keinen Grund hat, die Kennwörter anderer Benutzer zu kennen. Dies zuzulassen, stellt ein erhebliches Sicherheitsrisiko dar.

— David Z

16

Weil es gegen das einfachste Sicherheitsprinzip im Geschäft verstößt: "Speichern Sie Passwörter niemals im Klartext." Wenn die Sicherheit gut ist, sollte nur der Benutzer sein Passwort kennen, sonst niemand. Außerdem gibt es absolut keinen Grund, dies zu tun. Ich kann mir keine einzige Verwaltungssituation vorstellen, in der ein Root-Benutzer das Kennwort eines anderen Benutzers besser kennen könnte.

— HalosGhost

3

Verwenden Sie die MD5-Verschlüsselungsmethode und knacken Sie dann die Passwörter mithilfe von Rainbow-Tabellen .

— Cristian Ciupitu

58

Die anderen beiden Antworten haben Ihnen - richtig! - gesagt, dass dies eine schlechte Idee ist . Aber sie haben dir auch gesagt, dass es schwierig ist, eine Reihe von Programmen zu ändern.

Das ist nicht wahr. Es ist sehr leicht. Sie müssen nur eine oder zwei Konfigurationsdateien ändern. Ich halte es für wichtig, darauf hinzuweisen, da Sie sich dessen bewusst sein sollten, wenn Sie sich in Systeme einloggen, die Sie nicht kontrollieren. Diese fügen kein Klartext-Passwort in /etc/passwdoder ein /etc/shadow, es wird in eine andere Datei geschrieben. Hinweis Ich habe diese nicht getestet, da ich mein Passwort lieber nicht im Klartext haben möchte.

Bearbeiten /etc/pam.d/common-password(um das Passwort zu ändern) oder /etc/pam.d/common-auth(um das Login zu fangen) und hinzufügen… pam_exec expose_authtok log=/root/passwords /bin/cat
Bearbeiten Sie beide und wechseln Sie mit von pam_unix zu pam_userdb crypt=none. Alternativ können Sie es auch nur in common-password eingeben (wobei auch pam_unix übrig bleibt), um Kennwörter nur dann aufzuzeichnen, wenn sie geändert werden.
Sie können die shadowOption (sowie alle starken Hash-Optionen) aus pam_unix entfernen, um die Schattendatei zu deaktivieren und zu herkömmlichen Verschlüsselungskennwörtern zurückzukehren. Kein einfacher Text, aber John the Ripper wird das für Sie beheben.

Weitere Informationen finden Sie im PAM-Systemverwaltungshandbuch .

Sie können auch den Quellcode von PAM bearbeiten oder ein eigenes Modul schreiben. Sie müssten nur PAM (oder Ihr Modul) kompilieren, sonst nichts.

— derobert
quelle

1

Ich nehme an, dass die Klartext-Passwörter geschrieben werden /root/passwords.

— Faheem Mitha

Btw. Sehr gut zu wissen, wie einfach es ist und wo ich suchen muss, wenn ich Angst vor einem kompromittierten System habe.

— Erik

8

@erik Es ist das Vorrecht des Fragestellers, die für ihn hilfreichste Antwort als akzeptierte Antwort auszuwählen. Es ist wahrscheinlich eine gute Sache, dass OP herausgefunden hat, dass man das nicht tut. Das hilfreichste… Um es klar auszudrücken, ist dies nicht die einzige Möglichkeit, Kennwörter auf einem kompromittierten oder in böswilliger Absicht verwalteten System zu stehlen. Sie können sich also nicht nur die PAM-Konfiguration ansehen, um festzustellen, ob Sie in Sicherheit sind.

— Derobert

3

Dies geht eher davon aus, dass die Distribution PAM verwendet, keineswegs alle von ihnen.

— Vality

1

@msw Ich antwortete, weil es anscheinend eine verbreitete Überzeugung ist, dass es schwierig ist, eine Linux-Box mit Klartext-Passwörtern zu betreiben (Bobby hat seiner Meinung nach seine Antwort korrigiert; Anthon lässt es immer noch schwierig klingen). Das ist ein gefährlicher Glaube, da er die Wiederverwendung von Passwörtern fördert. Wenn ich nur eine Antwort gepostet hätte "Eigentlich ist es einfach, Sie bearbeiten eine oder zwei Dateien, aber ich werde es Ihnen nicht sagen", dann hätte das niemand geglaubt. Warum mir über die (zu der Zeit) viel höher gestimmten, gründlicheren Antworten zuhören? Um auf den Punkt zu kommen, muss man sagen, wie es geht. (Es handelt sich jedoch nicht um Beispiele zum Kopieren und Einfügen. Die Verwendung von Gedanken ist weiterhin erforderlich.)

— Derobert

34

Oh je, okay, fangen wir ganz am Anfang an ...

Wir wissen, dass die Passwörter der Benutzer in / etc / passwd gespeichert werden, jedoch verschlüsselt

Nein, sie gespeichert worden ist in /etc/passwd, und das war schon vor einiger Zeit. Heutzutage werden Passwörter die meiste Zeit in einer sogenannten Shadow-Datei gespeichert /etc/shadow.

aber auf verschlüsselte Weise, so dass selbst der Root sie nicht sehen kann:

Ich weiß, dass es manchmal synonym verwendet wird, aber Hashing ist keine Verschlüsselung . Verschlüsselung ist per definitionem umkehrbar, dh Sie können die verschlüsselte Sache wieder in ihre Klartextform übersetzen. Hashing ist so konzipiert, dass es in keiner Weise umkehrbar ist (mit Ausnahme von Brute Force). Die ursprüngliche Klartextform von etwas, das gehasht wird, soll nicht wiederherstellbar sein.

Kennwörter in der Schattendatei werden als Hashes gespeichert.

wie oben gezeigt: x: repräsentiert das Passwort

In xdiesem Fall handelt es sich nur um einen Platzhalter für das alte Kennwortfeld. Das xbedeutet, dass sich das Passwort in der Shadow-Datei befindet.

Gibt es eine Möglichkeit (mögliche Konfiguration), das Kennwort in der Datei / etc / passwd im Klartext zu speichern, sodass der Root sie sehen kann?

Ja, das ist zwar möglich, aber aus bestimmten Gründen keine gute Idee. Deroberts Antwort erklärt einen ziemlich einfachen Weg, dies zu tun .

Aber warum ist das keine gute Idee? Aus einem einfachen, aber sehr wichtigen Grund: Sicherheit. Ich schlage vor, diese Fragen zu lesen:

Aber um es zusammenzufassen, nehmen wir Folgendes an: Es gibt einen Server in einem Unternehmen, alle Benutzerkonten sind durch ihre Passwörter geschützt und die Daten in diesen Benutzerkonten sind mit demselben Passwort verschlüsselt. Ein Cracker von außen erhält Zugriff auf den Server, kann jedoch nicht auf wichtige Daten zugreifen, da diese in den Benutzerkonten noch verschlüsselt sind.

Nehmen wir nun an, die Passwörter würden im Klartext gespeichert. Der Cracker hätte plötzlich Zugriff auf alles , weil die Passwörter gelesen werden können. Aber wenn sie als gehashte Werte gespeichert werden, sind sie für niemanden nutzlos, außer für Menschen mit vielen Ressourcen, um einen Brute-Force-Angriff durchzuführen.

— Bobby
quelle

2

Zur Verteidigung von OP in Bezug auf Verschlüsselung und Hashing heißt es in der Manpage crypt von glibc: «Wenn salt eine Zeichenkette ist, die mit den Zeichen beginnt, "$id$"gefolgt von einer Zeichenkette, die mit "$": abgeschlossen ist, $id$salt$encrypted und anstelle der DES-Maschine iddie verwendete Verschlüsselungsmethode und diese dann identifiziert legt fest, wie der Rest der Zeichenfolge interpretiert wird ».

— Cristian Ciupitu

1

Interessant, beantwortet aber nicht die Hauptfrage, wie es derobert tut.

— Erik

6

@erik Manchmal lautet die richtige Antwort auf eine Frage "Mach es nicht", auch wenn das technisch möglich ist. Dies ist eine dieser Zeiten.

— Gilles 'SO- hör auf böse zu sein'

1

Ich schlage vor, diese Zeile zu ändern: "Nein, es gibt keine andere Möglichkeit, als viele Anwendungen und deren Funktionsweise zu ändern." Das hinterlässt den Eindruck, dass es nicht einfach ist (oder zumindest einfach, etwas funktional Äquivalentes zu tun).

— Derobert

2

@Bobby Dies ist eine hervorragende Antwort, aber keine hervorragende Antwort. Um es zu einer hervorragenden Antwort zu machen, sollten Sie den Teil dahingehend ändern, dass es "nicht leicht möglich" ist, weil es eindeutig so ist, wie in der Antwort von derobert gezeigt.

— Michael Dorst

10

Zunächst sind die verschlüsselten Passwörter nicht in /etc/passwd, aber sie sind in /etc/shadow. Einer der Gründe dafür ist, dass /etc/passwdes öffentlich lesbar ist (so dass Sie z. B. die GECOS-Feldinformationen für einen anderen Benutzer finden können) und insbesondere bei älteren Verschlüsselungsverfahren Brute-Force-Angriffe gegen das verschlüsselte Kennwort möglich sind.

Nur die Passwörter im Klartext zu speichern, ist nicht erforderlich und erfordert Aktualisierungen des Passwortprogramms und der Bibliotheken, die die /etc/shadowInformationen lesen , um nach gültigen Passwörtern zu suchen. Und dann müssen Sie hoffen, dass alle Dienstprogramme gemeinsam genutzte Bibliotheken verwenden, um auf diese Informationen zuzugreifen, anstatt statisch mit etwas verknüpft zu sein, das die Speicherung von Klartextkennwörtern nicht versteht.

Wäre dies eine Option in der Konfiguration eines Setups, dann gäbe es immer dumme Leute, die es unangemessen einschalten würden. Und während sie noch an CRT-Bildschirmen arbeiten und diese so ausstrahlen, dass sie von außerhalb ihres Gebäudes problemlos abgerufen werden können, während sie sich die Informationen ansehen.

Abgesehen davon verwenden Benutzer in der Regel auf mehreren Systemen dasselbe oder ein ähnliches Kennwort. Daher ist es keine gute Idee, dass Kennwörter von Menschen gelesen werden können. Da einige Systemadministratoren ihre Versuche auf anderen Systemen wiederholen könnten, weiß er, dass der Benutzer ein Konto hat.

Es muss interessantere Dinge geben, deren Funktionsweise auf Ihrem System untersucht werden kann.

— Anthon
quelle

3

/etc/shadowspeichert keine verschlüsselten Passwörter, sondern Passwort-Hashes. Ja, die Funktion wird aufgerufen cryptund in der Manpage steht "verschlüsselt", aber wenn Sie einen Fisch als Fahrrad bezeichnen, werden ihm keine Räder gegeben. Beachten Sie, dass /etc/shadowKennwörter in einem anderen Format gespeichert werden können, ohne dass Programme neu kompiliert werden müssen (zumindest unter Linux und Solaris): Authentifizierungsmethoden werden immer dynamisch verknüpft. Das Speichern von Passwörtern als Klartext wäre eine schreckliche Idee , ist aber mit ein wenig Arbeit möglich .

— Gilles 'SO- hör auf böse zu sein'

@gilles Ich habe gerade die OPs-Terminologie wieder verwendet, aber Sie haben Recht, dass Hash ein passenderer Begriff ist.

— Anthon

3

Der Hauptgrund (warum dies eine schlechte Idee ist) ist, dass kein Benutzer (root, admin oder anderer) jemals Zugriff auf das Benutzerkennwort eines anderen Benutzers haben sollte.

Einfach, weil das Passwort ein Mittel zur Authentifizierung ist. Wenn ich das Kennwort eines anderen Benutzers kenne, kenne ich dessen Anmeldeinformationen (Benutzername + Kennwort), sodass ich mich als dieser Benutzer anmelden und ihn (oder sie oder es) imitieren kann.

Alle Aktionen, die ich durchführe, wenn ich als dieser Benutzer angemeldet bin, werden vom anderen Benutzer ausgeführt. Und so sollte Authentifizierung nicht funktionieren.

Die Aktionen können katastrophal sein, z. B. das Löschen einer ganzen Reihe wichtiger Dateien, das Löschen von Festplatten, das Löschen von Backups, das Herunterfahren von Atomkraftplänen usw.

Oder einfach nur illegal. Stellen Sie sich eine Bank vor, bei der ich (der Administrator) Zugriff auf alle Passwörter habe. Mit dem Passwort des Kassierers kann ich eine Million Dollar vom Bankkonto des Präsidenten auf das Bankkonto des Fensterputzers überweisen. Verwenden Sie dann das übergeordnete Passwort des Kassierers, um die Transaktion zu genehmigen. Dann genehmigen Sie einen Scheck vom Fensterputzerkonto auf mein eigenes Offshore-Bankkonto.

Dann mache ich lange Ferien auf den Bahamas ...

In dieser Ansicht kann das Hashing der Kennwörter und die Verwendung separater Schattendateien als Mittel zur Durchsetzung dieser Regel angesehen werden (kein Benutzer sollte in der Lage sein, sich als ein anderer auszugeben).

Und wie @ Mirals Kommentar ^{* zeigt} , gibt es eine Ausnahme, bei suder zwar Identitätswechsel (und Arten von Ausschlägen des obigen Arguments) zulässig sind, jedoch auch ein Protokoll über seine Verwendung geführt wird (daher werden die Regeln in "Nur Administratoren können sich als andere ausgeben" geändert, aber a Logbuch wird geführt ").

^{* Das Bankbeispiel war wahrscheinlich nicht das beste. In jeder Umgebung, in der die Sicherheit von entscheidender Bedeutung ist, sind in der Regel mehr Authentifizierungs- und Autorisierungsmittel erforderlich als nur ein Kennwort.}

— ypercubeᵀᴹ
quelle

Ein Fehler bei diesem Argument ist, dass der Root-Benutzer sich ohnehin als jeder andere Benutzer im System ausgeben kann, ohne sein Kennwort kennen zu müssen. So einfach wie su otheruser.

— Miral

@Miral du hast recht, das habe ich nicht bedacht. Und obwohl die Verwendung von suprotokolliert wird, zeichnet su nicht auf, was tatsächlich getan wird, während ein Benutzer die Identität eines anderen Benutzers annimmt. Ein böswilliger Root kann die Protokolle jederzeit ändern, um die Aktionen vor zukünftigen Ermittlern zu verbergen.

— Ypercubeᵀᴹ