Asegurar contraseñas de DB


18

Al observar la estructura de la mayoría de los sitios web basados ​​en PHP / MySQL que he visto, parece que no es terriblemente difícil discernir la contraseña de la base de datos si cava un poco, ya que siempre hay un archivo de instalación o configuración que almacena la información para el registro en el DB. Además de la precaución básica de asegurarme de que los privilegios de mi base de datos estén restringidos adecuadamente para solicitudes remotas, ¿qué opciones hay disponibles que podría implementar en mis propios proyectos para proteger esta información?


1
Para aclarar, está preguntando sobre el almacenamiento de las credenciales para iniciar sesión en la base de datos desde el sitio web, y no cómo almacenar correctamente las contraseñas para los usuarios del sitio web dentro de la base de datos, ¿correcto?
Joe

Correcto; a eso me refiero.
Kaji

Respuestas:


10

No es una respuesta directa sobre el almacenamiento de las contraseñas, pero generalmente uso al menos dos conexiones de bases de datos cuando construyo aplicaciones web: una se usa el 99% del tiempo para actividades relacionadas con el usuario, con privilegios restringidos, y la otra se usa para la funcionalidad 'admin' (eliminar usuarios, etc.).

En algunos casos, cuando estoy instalando el paquete de otra persona, instalaré dos instancias ... una instancia pública que solo tiene acceso a la base de datos para hacer el tipo de usuario general, y una segunda instancia que está restringida por IP a mi subred local (posiblemente incluso en una máquina diferente) que debe usarse para cualquier tipo de actividad 'admin'. Ninguno de los dos tiene acceso para modificar tablas, etc., sin embargo ... Prefiero entrar a través de las herramientas de base de datos nativas que permitir que la aplicación web ejecute sus propias tareas de actualización que no han sido examinadas.

Sin embargo, puede llevarlo aún más lejos y agregar más conexiones específicamente para tareas determinadas ... para que las tareas de creación de usuarios y administración de contraseñas pasen por un usuario que tenga privilegios adicionales en las tablas de usuarios, el inicio de sesión tiene privilegios de base de datos para autenticar y no mucho más etc.

De esta manera, si hay un ataque de inyección sql, en la mayoría de las páginas web realmente no puede hacer nada significativo: no puede ver el hash de la contraseña, no puede agregar un nuevo usuario administrador (no es que puedan hacerlo) de todos modos), etc. Todavía no ayudará si logran obtener un shell en su máquina, pero los ralentizará.


1
Hacemos algo similar Sin embargo, generalmente creamos una nueva cuenta para cada usuario / aplicación de la base de datos en lugar de hacerlo por funcionalidad. Esto nos resuelve dos problemas: 1) podemos diferenciar el uso de la base de datos en herramientas como OEM (es decir, podemos ver quién está manipulando la base de datos con granularidad) y 2) podemos adaptar individualmente lo que cada usuario ve y tiene acceso dentro de base de datos.
ScottCher


4

Soy un gran fanático del uso de la autenticación 'Ident' de PostgreSQL sobre sockets locales siempre que puedo. De esa manera, los usuarios locales se asignan directamente a los usuarios de Unix / Windows de la computadora local, y no tengo que preocuparme por almacenar contraseñas. Sin embargo, no creo que esta sea una opción en MySQL todavía.

Cuando la base de datos y el servidor web están en dos máquinas separadas, uso contraseñas MD5 sobre SSL: si un hostil tiene acceso a mi servidor frontend, es solo cuestión de tiempo antes de que descubra cómo se comunica con la base de datos.


3

Si está utilizando .NET Framework, puede usar cadenas de conexión cifradas. No sé si tal cosa es posible en otros idiomas / marcos, pero esa sería otra protección para asegurarse de que sus conexiones no se vean comprometidas.

Además de usar cadenas de conexión encriptadas, usar LDAP / Kerberos / Active Directory será su opción más segura.


3

Si sus contraseñas están almacenadas en texto plano, use los hashes (MD5, SHA), Luke.


El OP no pregunta sobre el almacenamiento de contraseñas de usuario. Pero sí, sin duda hash tus contraseñas de usuario, ¡pero nunca utilices MD5 o la familia SHA para hacerlo! Use bcrypt o PBKDF2. De lo contrario, pronto se encontrará en las noticias como estas compañías que usaron MD5 y SHA1 y, por lo tanto, expusieron a sus usuarios a simples ataques de fuerza bruta.
Nick Chammas

Claro, se requieren salazón y otras técnicas además del hash. Y uno nunca debe implementar cripto primitivas él mismo (ella misma), sino más bien usar algunas bibliotecas criptográficas ampliamente probadas.
Yasir Arsanukaev

2

Dependiendo de su lenguaje de programación, podría cifrar las credenciales de inicio de sesión, pero si está ejecutando un lenguaje interpretado, entonces no hay forma de asegurarse de que alguien no pueda descifrar las credenciales si obtiene acceso al sistema.

Si está ejecutando C ++ o similar, le recomendaría que cree / encuentre una función de cifrado / descifrado salado y ejecute las credenciales a través de eso y almacene el hash resultante como un archivo en el sistema.

Si está ejecutando PHP o similar, le recomendaría que escriba un contenedor para las mcrypt_encrypt()credenciales y luego las ejecute para ofuscar el código para ralentizar a los piratas informáticos si tienen acceso al sistema.


Si encripta las credenciales, necesita algún otro secreto para desencriptarlas nuevamente. O, alternativamente, la forma encriptada se convierte en el secreto, por lo que un atacante podría usar eso. Faltan algunos detalles.
Peter Eisentraut
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.