¿Cómo puedo evitar poner la contraseña de la base de datos en un script de Perl?

La forma estándar es colocar las credenciales en un archivo de configuración e intentar proteger el archivo de configuración para que no sea más legible que el archivo perl. Esto ofrece un aumento moderado en la seguridad; por ejemplo, el código puede estar en el control de origen y accesible para los desarrolladores, el archivo de configuración no lo estaría. El código debe estar en la raíz cgi del servidor web y, posiblemente, descargarse bajo ciertas configuraciones erróneas, y el archivo de configuración no tiene que estar.

La forma ambiciosa es cifrar de forma reversible las credenciales y colocarlas en un archivo de configuración. Por supuesto, cualquier cosa encriptada reversiblemente puede ser descifrada. La aplicación BladeLogic hizo esto, y fue trivial (< 1 día) para descompilar su Java lo suficiente como para descubrir la función de desencriptar credenciales y usarla para desencriptarlas a mi entera satisfacción. No es una marca contra ellos; ese es solo el nombre del juego cifrado reversiblemente.

Otra opción es usar la autorización basada en el sistema operativo en concierto con restricciones de base de datos estrictamente limitadas. Por ejemplo, limite el acceso del usuario del cliente de la base de datos a un conjunto de procedimientos almacenados para limitar el potencial de abuso y permita que el usuario acceda a la base de datos sin una contraseña. Esto no funciona si está haciendo cliente-servidor a través de la red, lo que limita la frecuencia con la que es útil. Además, las personas tienden a mirar más de reojo el acceso del usuario del sistema operativo "sin contraseña" que el hecho de escribir la contraseña de una manera u otra. No es completamente lógico, pero hay estándares que dicen que todos los usuarios de bases de datos deben tener contraseñas, y eso es todo.

Con frecuencia, paso la contraseña al script en una variable de entorno de forma que el script no tenga acceso a la ubicación segura que contiene la contraseña.

PASSWORD='cat passwd_file'  perl_script.pl

luego el script lee la contraseña

my $password = $ENV{'PASSWORD'}

puntos de bonificación si el script de Perl elimina privilegios

Como ya han dicho otros, coloque las credenciales en un archivo separado que cargará el script. Los riesgos de tener la contraseña en el script incluyen su exposición a la navegación de hombro, su compromiso en sistemas de control de revisión o sistemas de gestión de configuración y su distribución más allá de lo que debería ser, copiar accidentalmente a otra ubicación al reutilizar parte del código, etc.

El archivo de credenciales debe tener los permisos mínimos necesarios. Posiblemente no debería ser incluido o tratado de manera diferente por los sistemas de administración de configuración.

Si está disponible, busque el uso de una función del sistema operativo que limite el acceso al archivo de credenciales más allá de los permisos. Por ejemplo, AppArmor o SELinux en Linux puede restringir el acceso al archivo de credenciales al único script que lo necesita. Esto solo protege contra un atacante que no puede controlar el script legítimo, así que asegúrese de que el script legítimo no sea propiedad del usuario que lo ejecuta (esta es una recomendación general: no tenga programas ejecutables que pertenezcan al usuario que los ejecuta). ).

El consenso parece ser:

1. La contraseña debe estar en un archivo separado, que no sea parte del control de versión, y debe estar protegida con permisos más restrictivos que los del script.
2. Encriptar la contraseña almacenada es una pérdida de tiempo ya que el script necesita para poder descifrar la contraseña de todos modos.

Pero estoy pensando en agregar un tercer control sobre ellos: el control de acceso basado en tiempo (temporal) también podría ayudar un poco aquí. Limitar la cantidad de tiempo que la contraseña de texto simple está disponible para los usuarios con privilegios más bajos agregaría otra capa (aunque pequeña) de control de acceso entre la contraseña y cualquier atacante local.

Mi idea es que el archivo de contraseña sea propietario de la raíz, establecido en mode 0400 . Y luego tenga un cronjob raíz que haga un chmod 0404 en el archivo de contraseña justo antes del cronjob de privilegios más bajos que ejecuta el script . A un intervalo específico más tarde (es de esperar que después de que el script haya terminado de ejecutarse), una segunda persona que hace la función de sincronización hace un chmod 0400 en el archivo de contraseña. Todo esto supone que la secuencia de comandos solo necesita la contraseña por algunos período de tiempo menor que siempre . ¿Qué piensas de este esquema?

Me gusta poner configuraciones en ~/config/appname y tener una configuración genérica para mi conexión mysql local (o cualquier otra). Si no quiere darle a su hogar un permiso X y ejecutar la aplicación, un usuario diferente tiene una carpeta de configuración estándar en algún lugar. Hago esto para no empaquetar accidentalmente o dar contraseñas o nombres de usuario a otros programadores. No creo que sea un gran problema, pero mi jefe es un fanático de la seguridad y es un buen hábito, especialmente cuando publica algo en la web.

Sería conveniente escribir un oneliner o twoliner estándar para tus archivos de configuración y copiarlos / pegarlos en cualquier nuevo script que escribas

Esto es lo que planeo hacer para un script que se conecta a una base de datos remota. Requiere 2 servidores para almacenar la clave por separado del valor cifrado.

1. En el servidor 2 (donde se almacenará la clave), cree un script que acepte un parámetro clave y lo almacene localmente.
2. En el Servidor 1 (donde se almacena el script), cree un script que acepte la cadena de conexión (host, nombre_bd, nombre de usuario, contraseña) como parámetro y genere una clave aleatoria para cifrar la cadena de conexión. Almacenamos la cadena cifrada localmente, procesamos la clave y la almacenamos localmente, luego enviamos la clave (a través de SSL) al servidor 2. Esta secuencia de comandos deberá ejecutarse manualmente con la cadena de conexión real para inicializarla y se puede volver a ejecutar para restablecer la clave si el segundo servidor se ve comprometido de alguna manera.
3. En el servidor 1 Configure la secuencia de comandos original para aceptar un parámetro de clave, valide la clave contra el hash almacenado, luego use la clave para descifrar la cadena de conexión cifrada.
4. En el servidor 2 Configure una llamada cURL al script en el servidor 1 (sobre SSL) que envía la clave y ejecuta el script. Esto se puede configurar en cron o como quiera que se ejecute.

¿Sería esta una solución adecuada?

1. La contraseña se almacena en un programa compilado de C / C ++ que está ofuscado así: contraseña de char [100]; contraseña [0] = 'a'; contraseña [1] = 'b'; contraseña [2] = 'c'; contraseña [3] = '\ 0';

O alguna otra forma de ofuscar la contraseña. (la contraseña no debería estar disponible ejecutando "cadenas" en el ejecutable)

2. El programa C / C ++ solo devuelve la contraseña a los scripts registrados de confianza: A. Obtenga ppid y verifique / proc // cmdline, / proc // comm, etc. B. Obtenga el inodo del script de la persona que llama y compare con la identidad registrada, para asegurarse de que el script no se haya modificado.