Deaktivieren Sie den svn-Klartext-Kennwortspeicher für alle Benutzer

Standardmäßig können Benutzer mit Subversion ihr Kennwort im Klartext in speichern ~/.subversion/auth/svn.simple. Ich untersuche Optionen zum Speichern 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 führen Subversion 1.6.17 aus.

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 kann jedoch die Konfigurationsdatei ändern, wenn er dies möchte. Gibt es keine systemweite SVN-Konfigurationsdatei? Einige Optionen, die ich gesehen habe:

Option 1

In 1.8-dev akzeptiert das Konfigurationsskript von Subversion die Option --disable-plaintext-password-storage, um die Logik zu umgehen, in der Klartextkennwörter und Passphrasen für Clientzertifikate gespeichert sind.

Ich bevorzuge es, nicht auf eine Entwicklungsversion zu aktualisieren.

Option 2

/etc/subversion/config

AFAIK, diese Konfigurationsdatei wird nur verwendet, wenn ein Benutzer noch keine Konfigurationsdatei in seinem Ausgangsverzeichnis hat.

Option 3

Fügen Sie einen Cron-Job hinzu, um den Authentifizierungscache des Benutzers zu löschen ~/.subversion/auth/svn.simple. Selbst wenn sie ihre SVN-Konfigurationsdatei ändern, würde unser Cron-Job alle gespeicherten Passwörter löschen. Selbst wenn Sie es jede Minute ausführen, kann dies nicht garantieren, dass unser Sicherungssystem die Datei (en) mit Klartextkennwörtern nicht abruft.

Ideen?

Das kannst du nicht.

Was auch immer Sie tun, Ihre Benutzer können es umgehen und ihr Passwort trotzdem in einer Nur-Text-Datei speichern. Wenn Sie die Funktion in der Client-Binärdatei deaktivieren, wird ein anderer Client heruntergeladen oder kompiliert. Wenn Sie abscheuliche Sicherheitsmaßnahmen einrichten (z. B. für jeden SVN-Vorgang ein Kennwort eingeben müssen), umgehen Ihre Benutzer diese in der Regel auf eine Weise, die die Sicherheit verschlechtert. (Schreiben Sie beispielsweise ein Wrapper-Skript, das ihr Kennwort enthält. Damit bleiben sie weltweit lesbar.) Tun Sie das also nicht.

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

Wenn Sie über Laptop- oder Backup-Diebstahl besorgt sind, verschlüsseln Sie das Home-Verzeichnis der Benutzer. Dies schützt sowohl die Passwörter als auch die Daten. Wenn das gesamte Home-Verzeichnis verschlüsselt ist, entspricht das Verschlüsselungskennwort aus Gründen der Benutzerfreundlichkeit normalerweise dem Anmeldekennwort. Stellen Sie sicher, dass Sie über eine Kennwortsicherungsrichtlinie verfügen (z. B. einen versiegelten Umschlag), da der Verlust eines Verschlüsselungskennworts nicht wiederherstellbar ist.

Wenn Sie Bedenken hinsichtlich der Wiederverwendung von Passwörtern haben, legen Sie ein zufälliges (daher eindeutiges) Passwort fest, das sie ein für alle Mal in ihren Client eingeben. Natürlich haben Sie einen einfachen Prozess zum Ändern kompromittierter Passwörter.

Übrigens, noch bevor ich etwas verschlüsselte, würde ich mich um die Dateiberechtigungen kümmern: Ich habe nur aus Neugier mein eigenes Setup überprüft und herausgefunden, dass dies weltweit lesbar ist. Für eine Datei mit einem eindeutigen Kennwort sieht es für mich wie eine Sicherheitslücke aus.