Désactiver le stockage de mot de passe en clair svn pour tous les utilisateurs


9

Par défaut, Subversion permet aux utilisateurs d'enregistrer leur mot de passe en texte brut dans ~/.subversion/auth/svn.simple. J'étudie les options de stockage des mots de passe cryptés dans svn , mais au moins et dès que possible, je veux désactiver complètement la possibilité de stocker les mots de passe pour tous nos utilisateurs. Nous exécutons Subversion 1.6.17.

Je peux désactiver cela dans le répertoire personnel d'un utilisateur via le fichier de configuration.

~ / .subversion / serveurs :

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

Cependant, l'utilisateur peut modifier le fichier de configuration s'il le souhaite. N'y a-t-il pas un fichier de configuration svn à l'échelle du système? Quelques options que j'ai vues:

Option 1

Dans la version 1.8-dev, le script configure de Subversion accepte une option --disable-plainxt-password-storage pour contourner la logique qui stocke les mots de passe en clair et les phrases secrètes des certificats client.

Je préfère ne pas mettre à jour vers une version de développement.

Option 2

/etc/subversion/config

AFAIK, ce fichier de configuration n'est utilisé que lorsqu'un utilisateur n'a pas de fichier de configuration déjà dans son répertoire personnel.

Option 3

Ajoutez un travail cron pour supprimer le cache d'authentification de l'utilisateur ~/.subversion/auth/svn.simple. Donc, même s'ils modifient leur fichier de configuration svn, notre tâche cron tuerait tous les mots de passe stockés. Cependant, même en l'exécutant toutes les minutes, cela ne garantit pas que notre système de sauvegarde ne récupérera pas le ou les fichiers contenant des mots de passe en texte brut.

Des idées?


Contrôlez-vous le serveur? Pourquoi ne pas utiliser la clé SSH plus ou Kerberos au lieu de l'authentification par mot de passe?
Mikel

oui je suis l'administrateur.
Banjer

Réponses:


6

Tu ne peux pas.

Quoi que vous fassiez, vos utilisateurs peuvent le contourner et stocker leur mot de passe dans un fichier texte en tout cas. Si vous désactivez la fonctionnalité dans le binaire client, ils téléchargeront ou compileront un client différent. En règle générale, si vous configurez des mesures de sécurité désagréables (comme devoir saisir un mot de passe pour chaque opération svn), vos utilisateurs les contourneront d'une manière qui aggrave la sécurité. (Par exemple, écrire un script wrapper qui contient leur mot de passe. Qu'ils laisseront lisible par le monde.) Alors ne faites pas ça.

Pour réitérer: vous ne pouvez pas, par des mesures techniques seules, empêcher les utilisateurs de stocker leur mot de passe dans un fichier. Vous pouvez l'interdire, mais si cela rend leur vie difficile, ils le feront quand même.

Si vous êtes préoccupé par le vol d'ordinateur portable ou de sauvegarde, chiffrez le répertoire personnel des utilisateurs. Cela protégera les mots de passe ainsi que les données. Si l'ensemble du répertoire personnel est crypté, le mot de passe de cryptage est généralement le même que le mot de passe de connexion, pour des raisons d'utilisabilité. Assurez-vous d'avoir une politique de sauvegarde de mot de passe (par exemple une enveloppe scellée), car la perte d'un mot de passe de cryptage est irrécupérable.

Si vous êtes préoccupé par la réutilisation des mots de passe, imposez un mot de passe aléatoire (donc unique), qu'ils taperont une fois pour toutes dans leur client. Bien sûr, ayez un processus simple pour changer les mots de passe compromis.


Grands points tout autour. J'ai certainement vu des utilisateurs contourner les protocoles que nous avons mis en place afin de leur faciliter la vie. Je vais devoir voir ce que svn propose d'autre en termes d'authentification qui ne dérange pas les utilisateurs, comme les clés.
Banjer

0

BTW avant même de crypter quoi que ce soit, je m'occupais des autorisations de fichiers: j'ai juste vérifié ma propre configuration par curiosité, et j'ai découvert que c'était lisible dans le monde entier. Pour un fichier contenant un mot de passe clair, cela me semble être une faille de sécurité.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.