Deaktivieren Sie die SVN-Klartext-Passwortspeicherung für alle Benutzer

Deaktivieren Sie die SVN-Klartext-Passwortspeicherung für alle Benutzer

Standardmäßig erlaubt Subversion Benutzern, ihr Passwort im Klartext in zu speichern ~/.subversion/auth/svn.simple. Ich untersuche Optionen fürSpeichern verschlüsselter Passwörter in SVN, aber zumindest und so schnell wie möglich möchte ich die Möglichkeit zum Speichern von Passwörtern für alle unsere Benutzer vollständig deaktivieren. Wir verwenden Subversion 1.6.17.

Ich kann dies im Home-Verzeichnis eines Benutzers über die Konfigurationsdatei deaktivieren.

~/.subversion/servers:

[global]
# Password / passphrase caching parameters:
store-passwords = no
store-plaintext-passwords = no

Der Benutzer könnte die Konfigurationsdatei jedoch ändern, wenn er dies wünscht. Gibt es keine systemweite SVN-Konfigurationsdatei? Ein paar Optionen, die ich gesehen habe:

Option 1

In 1.8-dev akzeptiert das Konfigurationsskript von Subversion eine Option --disable-plaintext-password-storage, um die Logik zu umgehen, die Passwörter im Klartext und Passphrasen für Client-Zertifikate speichert.

Ich möchte lieber nicht auf eine Entwicklungsversion aktualisieren.

Option 2

/etc/subversion/config

Soweit ich weiß, wird diese Konfigurationsdatei nur verwendet, wenn ein Benutzer noch keine Konfigurationsdatei in seinem Home-Verzeichnis hat.

Option 3

Fügen Sie einen Cron-Job hinzu, um den Authentifizierungscache des Benutzers zu löschen ~/.subversion/auth/svn.simple. Selbst wenn der Benutzer also seine SVN-Konfigurationsdatei ändert, würde unser Cron-Job alle gespeicherten Passwörter löschen. Selbst wenn er ihn jede Minute ausführt, ist jedoch nicht garantiert, dass unser Backup-System nicht die Dateien mit Klartextpasswörtern abgreift.

Ideen?

Antwort1

Das kannst du nicht.

Was auch immer Sie tun, Ihre Benutzer können es umgehen und ihr Passwort trotzdem in einer einfachen Textdatei speichern. Wenn Sie die Funktion in der Client-Binärdatei deaktivieren, werden sie einen anderen Client herunterladen oder kompilieren. Wenn Sie aufdringliche Sicherheitsmaßnahmen einrichten (wie z. B. die Notwendigkeit, für jeden SVN-Vorgang ein Passwort einzugeben), werden Ihre Benutzer diese in der Regel auf eine Weise umgehen, die die Sicherheit verschlechtert. (Zum Beispiel indem sie ein Wrapper-Skript schreiben, das ihr Passwort enthält. Das sie dann für alle lesbar lassen.) Tun Sie das also nicht.

Noch einmal: Sie können Benutzer nicht allein durch technische Maßnahmen daran hindern, ihr Passwort in einer Datei zu speichern. Sie können es ihnen verbieten, aber wenn es ihnen das Leben schwer macht, werden sie es trotzdem tun.

Wenn Sie sich Sorgen über den Diebstahl von Laptops oder Backups machen, verschlüsseln Sie das Home-Verzeichnis der Benutzer. Dadurch werden sowohl die Passwörter als auch die Daten geschützt. Wenn das gesamte Home-Verzeichnis verschlüsselt ist, ist das Verschlüsselungspasswort aus Gründen der Benutzerfreundlichkeit normalerweise dasselbe wie das Anmeldepasswort. Achten Sie darauf, eine Richtlinie zur Passwortsicherung zu haben (z. B. einen versiegelten Umschlag), da der Verlust eines Verschlüsselungspassworts unwiederbringlich ist.

Wenn Sie sich Sorgen über die Wiederverwendung von Passwörtern machen, legen Sie ein zufälliges (und damit eindeutiges) Passwort fest, das die Benutzer ein für alle Mal in ihren Client eingeben. Natürlich sollten Sie auch über ein einfaches Verfahren zum Ändern kompromittierter Passwörter verfügen.

Antwort2

Übrigens würde ich mich schon vor der Verschlüsselung um die Dateiberechtigungen kümmern: Ich habe gerade aus Neugier mein eigenes Setup überprüft und festgestellt, dass es für alle lesbar ist. Bei einer Datei mit einem eindeutigen Passwort sieht das für mich nach einer Sicherheitslücke aus.

verwandte Informationen