Grimpi IT Blog

marzo 11, 2009

Como almacenar passwords en una base de datos?

Filed under: Arquitectura, Seguridad — Etiquetas: — grimpi @ 9:53 pm

Supongamos que tenemos que hacer el típico sistema donde el usuario se autentica contra una tabla de nuestra base de datos.
Entre todas las cuestiones de seguridad que hay que tener en cuenta, surge un problema muy común: De que manera almacenar el password de los usuarios en nuestra base de datos?

Existen 4 maneras clásicas de hacer esto:

  • Guardarlo así como viene, en un campo sin encriptar, como si fuera un campo de texto normal.
  • Guardarlo encriptado.
  • Aplicarle una función hash y guardar el hash del password.
  • Aplicarle una función hash + un salt y guardar el hash del password.

Password plano:

La primer opción, por obvias razones, es la más simple de todas, pero extremadamente insegura y salvo en sistemas donde la seguridad NO IMPORTE EN ABSOLUTO, no debe ser utilizada. Sin embargo no es infrecuente encontrar sistemas donde nadie se haya tomado la molestia al menos, de dificultar mínimamente el acceso al password.
Un argumento que se puede dar a favor de este enfoque, es que si el acceso a la base de datos y la tabla de usuarios, está correctamente configurado y restringido, no debería haber problemas de seguridad. Lo que es una mentira atroz, porque tanto el DBA como los desarrolladores, tendría potencialmente acceso a estos datos.
Y si un hacker termina rompiendo de alguna manera la seguridad de nuestra base de datos, podría llegar a leer sin ningún problema, el password de todos los usuarios.

Password encriptado reversible:

La segunda opción, consiste en encriptar el password. Es mejor que nada, pero tiene sus problemas. El primer inconveniente que surge con este enfoque, es donde guardar la llave de encriptación. En un archivo de configuración? De qué sirve usar el algoritmo de encriptación más complejo y seguro que exista, si luego guardamos la llave de encriptación, en un archivo plano o de fácil acceso?
Y el segundo problema de este enfoque, es que el password es reversible. Que significa esto? Que es posible obtener el password sin apelar a la fuerza bruta. Por lo tanto, una potencial debilidad.
Si se pueden desencriptar, el riesgo de que alguien conozca la llave y tenga acceso a todo el sistema con todos los usuarios es muy grande. En un organización para el programador/DBA resulta extremadamente fácil obtener el password de los usuarios del sistema que mantiene/desarrolla, ya que tiene acceso a las tablas y a la clave de encriptación.

Password encriptado irreversible:

Perfecto, ya vimos que las primeras 2 opciones, son bastante débiles. Qué hacemos?
La tercera manera de almacenar el password, es usar una función hash. Como es esto?
Una función hash, es una función que encripta un determinado texto de forma no reversible, esto significa que no existe forma de “desencriptar” dicho texto. Lo que es perfecto para almacenar password. En la tabla ahora tenemos que guardar el hash del password. Es un método mucho más seguro que los otros 2 anteriores. Al no poder ser “desencriptado” el password, no existe forma de obtenerlo.
Entonces, si no puedo desencriptar una contraseña, ¿Cómo puedo saber entonces si una contraseña entregada es válida? La respuesta es muy simple. Se encripta la contraseña entregada y se compara el resultado de la encriptación con la contraseña previamente almacenada.

CLAVE_HASH = FUNCION_HASH(Password)

Existen principalmente 2 algoritmos para hacer Hash: MD5 y SHA-1 (también existen variantes de este como el SHA-256 y SHA-512).
Sin embargo, existe una debilidad, veamos el siguiente ejemplo de una tabla Usuario:

ID Usuario Password
1 Pepe ADC2-1234….
2 Rosario ADC2-1234….
3 Juan FA3D-BC56….
4 Grimpi FFD3-D045….

Si somos observadores, el hash del password de los usuarios Pepe y Rosario son el mismo. No podemos saber cuál es el password exacto de ambos, pero si podemos saber que son iguales. Supongamos que nuestro sistema tiene 50000 usuarios. Cuál es la posibilidad de que existan passwords repetidos? Muy grande. Si un Hacker por alguna razón, obtiene el password de Pepe, instantáneamente, ya sabría cual es el password del usuario Rosario. Mala idea.
Por otro lado, este enfoque también tiene otro grave inconveniente, que son los diccionarios de claves hash (Rainbow tables). Un diccionario de estas características, no es más que una enorme tabla de 2 campos, donde en el primer campo figura la clave hash y en el segundo campo, el texto plano correspondiente a esa clave.
Los usuarios no suelen poner claves muy complejas a excepción que uno se lo exija, por lo tanto, un diccionario de claves hash muy amplio, seguramente contendrá la mayoría de las password de los usuarios.

Entonces, que hacemos?

Password encriptado irreversible + Salt:

Que es un salt?
Un salt no es ni mas ni menos que texto o un conjunto de caracteres que varían por usuario/registro que se le concadena al texto antes de ser encriptado por una función hash. Y para qué queremos hacer esto? Para evitar los problemas del enfoque anterior. Si a un password se le concadena un texto que varia por usuario, como por ejemplo, el ID del mismo o el login, el hash sería diferente aun si tuviésemos 2 o más usuarios con exactamente el mismo password.
Pero además, dificultamos enormemente el ataque del hacker usando un diccionario de claves. Por supuesto, que a medida que el Salt sea más complejo, más dificultosa será la tarea del hacker.

CLAVE_HASH = FUNCION_HASH(Password + Salt)

Existen básicamente 2 estrategias diferentes para determinar el salt de un password. Recordemos que a la hora de autenticar el password, debemos saber el valor del salt para generar una clave encriptada idéntica a la que tenemos en la base de datos.

La primera estrategia consiste en generar un texto aleatorio (convenientemente con caracteres “raros” para dificultar todavía más la tarea de un ataque por diccionario) y asociárselo al usuario, por lo tanto, sería necesario agregar un nuevo campo a la tabla de Usuarios, que tenga el valor del Salt:

ID Usuario Salt Password
1 Pepe AB_D!#$2 BFC3-8234….
2 Rosario T5&/021? AAC2-1290….
3 Juan ¿+}s34@” EC3D-4C56….
4 Grimpi D*-34r$Q AFC4-A145….

La otra estrategia consiste calcular el salt en función de algún dato del usuario, como por ejemplo el username (que se supone que debe ser único), el ID de la tabla o algún otro campo del mismo. La ventaja de esta estrategia es que no tenemos que agregar un nuevo campo a la tabla, pero debemos asegurarnos que usamos un valor univoco en toda la tabla!!.

Recomiendo ver este link con una interesante discusión que hubo en un foro, con respecto a las distintas maneras en que se puede obtener el valor salt y este paper que explica mejor el metodo recomendado.

diciembre 13, 2008

Un ejemplo de inseguridad…

Filed under: Opinion, Seguridad — Etiquetas: — grimpi @ 1:09 pm

La semana pasada tuve que ir a instalar un sistema en una planta de una empresa de bebidas muy pero muy conocida.
Me sorprendió de sobremanera, la increíble inseguridad a nivel accesos a datos que existe en dicha planta.
Paso a enumerar los horrores bizarros que encontré:
1) El password sa del servidor SQL Server de PRODUCCION era vacio.
2) El password de administrador de todas las PC era el mismo, incluyendo el del Servidor SQL y estaba anotado en marcador rojo indeleble en unos de los monitores!!!.
3) Estaba habilitado el acceso por Terminal Server al servidor de producción (cuya password recordemos estaba anotada en el monitor). No vaya ser que un potencial hacker tenga que tomarse la molestia de tener que ir físicamente al rack de servidores…
4) El usuario administrador del repositorio de reportes (Crystal Reports Server) también era vacio.

Es realmente difícil encontrar un cuadro más patético e inseguro que este. El que instaló todo esto, debía ser un junior y muy vago, porque de otra manera no se explica como un profesional de sistemas sea tan pero tan irresponsable. Como también es terrible que no exista una auditoria, control interno o normas de seguridad mínimas que detecten este tipo de situaciones.
Un dato importante a tener en cuenta que el sistema que instalamos monitorea en tiempo real determinados aparatos de la fábrica, que luego son volcados a una base de datos y visto por distintos reportes. Tal vez no sean datos estratégicos para la empresa que requieran un nivel de acceso excesivamente restrictivos, pero definitivamente semejante nivel de inseguridad no es aceptable en NINGUN sistema. Creo que no tengo que aclarar los desastres que una persona con suficientes conocimientos puede hacer con un acceso tan amplio y fácil a los servidores.

Y no estamos hablando de una pyme familiar de 50 empleados, sino de una empresa multinacional que en la Argentina solamente su facturación debe ser de cientos de millones de dólares y seguramente más.
No es la primera vez que veo este tipo de situaciones, especialmente en las plantas de las empresas. Recuerdo que una vez también en una importante farmacéutica, descubrimos que el password administrador del dominio era de toda la red era “administrador”. En muchas plantas industriales, independientemente del rubro, el sector informático está totalmente ausente.
Porque estoy seguro que en su sector administrativo y contable, este tipo de situaciones no ocurren. Pero como en las plantas, no suele existir ningún tipo de empleado en sistemas, sino mas bien consultores que instalan sistemas y tratan de hacer las cosas lo mas fácil y rápido posible, nadie controla el aspecto de la seguridad.
Me pregunto en cuantos lugares sucederán este tipo de cosas y en cuantas situaciones hay riesgo de desastre absoluto porque el que instalo el servidor de base de datos, no puso un password.

Blog de WordPress.com.