Deshabilite el almacenamiento de contraseña de texto sin formato svn para todos los usuarios


9

Por defecto, Subversion permite a los usuarios guardar su contraseña en texto plano ~/.subversion/auth/svn.simple. Estoy investigando opciones para almacenar contraseñas cifradas en svn , pero al menos y lo antes posible, quiero deshabilitar por completo la capacidad de almacenar contraseñas para todos nuestros usuarios. Estamos ejecutando Subversion 1.6.17.

Puedo desactivar esto dentro del directorio de inicio de un usuario a través del archivo de configuración.

~ / .subversion / servidores :

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

Sin embargo, el usuario podría cambiar el archivo de configuración si quisiera. ¿No hay un archivo de configuración svn en todo el sistema? Algunas opciones que he visto:

Opción 1

En 1.8-dev, el script de configuración de Subversion acepta una opción --disable-plaintext-password-storage para omitir la lógica que almacena las contraseñas de texto sin formato y las frases de contraseña del certificado del cliente.

Prefiero no actualizar a una versión de desarrollo.

opcion 2

/etc/subversion/config

AFAIK, este archivo de configuración solo se usa cuando un usuario no tiene un archivo de configuración ya en su directorio de inicio.

Opción 3

Agregue un trabajo cron para eliminar la caché de autenticación del usuario ~/.subversion/auth/svn.simple. Entonces, incluso si alteran su archivo de configuración svn, nuestro trabajo cron eliminaría cualquier contraseña almacenada. Sin embargo, incluso ejecutarlo cada minuto no garantiza que nuestro sistema de copia de seguridad no tome los archivos que contienen contraseñas de texto sin formato.

Ideas?


¿Controlas el servidor? ¿Por qué no usar la clave SSH plus o Kerberos en lugar de la autenticación de contraseña?
Mikel

Sí, soy el administrador.
Banjer

Respuestas:


6

No puedes

Hagas lo que hagas, tus usuarios pueden omitirlo y guardar su contraseña en un archivo de texto sin formato. Si deshabilita la función en el binario del cliente, descargarán o compilarán un cliente diferente. Como regla general, si configura medidas de seguridad desagradables (como tener que escribir una contraseña para cada operación svn), sus usuarios las omitirán de una manera que empeorará la seguridad. (Por ejemplo, escribir una secuencia de comandos de contenedor que contenga su contraseña. La cual dejarán legible para el mundo). Así que no hagas eso.

Para reiterar: no puede, solo por medidas técnicas, evitar que los usuarios almacenen su contraseña en un archivo. Puedes prohibirlo, pero si les dificulta la vida, lo harán de todos modos.

Si le preocupa el robo de una computadora portátil o de respaldo, cifre el directorio de inicio de los usuarios. Esto protegerá las contraseñas y los datos. Si todo el directorio de inicio está cifrado, la contraseña de cifrado suele ser la misma que la contraseña de inicio de sesión, por razones de usabilidad. Asegúrese de tener una política de respaldo de contraseña (por ejemplo, un sobre cerrado), ya que perder una contraseña de cifrado es irrecuperable.

Si le preocupa la reutilización de la contraseña, imponga una contraseña aleatoria (por lo tanto, única), que escribirán de una vez por todas en su cliente. Tenga un proceso simple para cambiar las contraseñas comprometidas, por supuesto.


Grandes puntos por todas partes. Ciertamente, he visto a usuarios eludir los protocolos que tenemos para facilitarles la vida. Tendré que ver qué más ofrece svn en la forma de autenticación que no molesta a los usuarios, como la basada en claves.
Banjer

0

Por cierto, incluso antes de encriptar cualquier cosa, me encargaría de los permisos de archivo: solo revisé mi propia configuración por curiosidad y descubrí que esto es legible en todo el mundo. Para un archivo que contiene una contraseña clara, me parece un agujero de seguridad.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.