1. Visión general

Casi todas las aplicaciones web modernas necesitan, de un modo u otro, cifrar las contraseñas de sus usuarios. Se podría decir que, desde el momento en que la aplicación tiene usuarios, y los usuarios se identifican usando una contraseña, esas contraseñas se deben guardar usando algún tipo de cifrado.

Hay muchas razones básicas para esto: las bases de datos pueden estar comprometidas, y por tanto también las comunicaciones. Pero la razón más importante es que se tiene que pensar que las contraseñas de los usuarios son datos personales. Sus contraseñas son sus claves para su privacidad, por tanto son personales, y nadie tiene el derecho de conocerlas. Y se debe cumplir esto si se quiere ganar la confianza de los usuarios.

2. El algoritmo

Ahora que se quieren cifrar las contraseñas, se debe saber cómo. Aquí entra la primera regla:

I. Cifrar las contraseñas usando técnicas de un sentido, es decir, funciones resumen (o hash).

Esto se debe a que, excepto para algunos escenarios específicos, no hay ninguna razón para que una contraseña sea descifrada. Si se cifran las contraseñas usando cifrados basados en claves (una técnica de dos sentidos) y un atacante consigue saber la clave de cifrado, se revelarán todas las contraseñas. Si no se tiene una clave para el cifrado, el riesgo desaparece, y el atacante tendrá que confiar en el uso de técnicas de fuerza bruta o similares.

Pero, ¿qué ocurre si un usuario pierde su contraseña? ¿No podrá recuperarla? La respuesta es NO. No sólo no se puede recuperar, si no que ni siquiera existe una manera de leer/conocer/ver las contraseñas de los usuarios, no importa si se es el administrador del sistema. Si un usuario pierde su contraseña, sólo se podrá reiniciarla a un nuevo valor y enviárselo por algún canal seguro al usuario, y pidiéndole que la cambie lo más pronto que pueda.

Ahora que está claro que las funciones resumen son necesarias en las contraseñas, ¿cuál algoritmo se debería usar? Hay bastantes, y dependen de las necesidades de cada uno. Los más usados son:

• Algoritmo MD5.
• Familia SHA: SHA-1 y la variantes de SHA-2 (SHA-224, SHA-256, SHA-384 y SHA-512)

En la mayoría de los casos, MD5 o SHA-1 serán elecciones adecuadas para los resúmenes de contraseñas, aunque aplicar estos algoritmos no será suficiente, como se verá a continuación.

Cuando se dice que se deberían usar funciones resumen para los cifrados de las contraseñas, y dado que estas funciones resumen son técnicas de un sentido, la siguiente pregunta es: «Si no se pueden descifrar las contraseñas, ¿cómo se comprueba que un usuario tiene una contraseña correcta?»

Hay una respuesta muy simple a esta cuestión, que será la segunda regla:

II. La entrada y las contraseñas guardadas se comparan usando los resultados de las funciones resumen, no usando cadenas sin cifrar.

Lo que significa que, una vez los usuarios han introducido sus contraseñas en la identificación, se realizará la función resumen sobre la contraseña introducida con el mismo algoritmo que se ha usado con las contraseñas guardadas, y se compararán ambos resultados. Como estas funciones garantizan que dos entradas iguales obtienen el mismo resultado (lo que no es cierto en el sentido contrario), si los resultados coinciden se considerará que la contraseña introducida por el usuario es correcta.

3. Mejorando la seguridad de los resúmenes

Todos los algoritmos de funciones resumen mencionados anteriormente comparten una característica: son públicos. Son algoritmos muy conocidos y ampliamente implementados, por lo que cualquiera puede usarlos.

Si cualquiera puede usar el mismo algoritmo que la aplicación, y por alguna razón los atacantes pueden ver la base de datos de los resúmenes de las contraseñas, ¿cómo se puede estar seguro que los atacantes no serán capaces de conseguir alguna contraseña de los usuarios probando todas las posibilidades hasta que encuentren algún resumen que coincida con uno de los guardados?

La respuesta es que no se puede. Pero se puede hacer que todo eso sea una tarea enorme y con un gran tiempo de realización, de modo que no resulte útil, a menos que puedan esperar toda la eternidad. Para lograr esto, se van a explicar dos conceptos: «salt» y el contador de iteración.

3.1. «Salt»

«Salt» es una secuencia de bytes que se añaden a la contraseña antes de conseguir su resumen. Esto hace que estos resúmenes sean diferentes a los que deberían ser usando sólo la contraseña, y como resultado se consigue protección contra los ataques de diccionario. Se pueden seguir dos estrategias para usar «salt»:

• Usar un «salt» fijo, una secuencia de bytes que se utilizarán para resumir cualquier contraseña. Se puede guardar oculto el «salt» y considerarlo un valor añadido de seguridad, pero esto puede hacer que el sistema se vuelva más vulnerable a ataques de cumpleaños y, en general, a ataques dirigidos contra la base de datos de contraseñas.
• Usar un «salt» variable, que normalmente es una opción segura (especialmente si es aleatorio). Este se genera independientemente para cada contraseña a resumir, y permite que cada contraseña guardada esté desacoplada de las demás, creando una gran protección general y un alta seguridad contra ataques dirigidos contra la base de datos de contraseñas.

En la práctica, un «salt» aleatorio (o variable) es la mejor idea porque, aunque al generarse aleatoriamente tendrá que guardarse junto al resumen de la contraseña (por lo que cualquiera podrá recuperarlo) y esto hará que sea trivial para un atacante conocerlo, permitirá que cada contraseña de usuario sea independiente del resto, por lo que tendrán que atacarse una por una.

Se tiene que pensar que, si se usa un «salt» fijo y el atacante consigue saberlo, la seguridad de toda la base de datos de contraseñas será nula. Y hay muchos métodos para que el atacante pueda conocer este «salt», como aplicar fuerza bruta en sus contraseñas o en contraseñas que tenga de algún usuario válido. En un escenario de un «salt» fijo, una contraseña débil podría hacer que el sistema de contraseñas fuera débil.

Sin embargo, si se quiere mantener una parte del «salt» en secreto, se puede usar una técnica que mezcle las otras dos, usando un «salt» compuesto de una parte fija y otra aleatoria, guardando los bytes aleatorios junto al resumen de la contraseña.

El tamaño mínimo de un «salt» es de 8 bytes. Si se usa una opción mixta, al menos 8 bytes deberían ser aleatorios.

Así, se puede definir la tercera regla:

III. Se debe usar un «salt» que contenga al menos 8 bytes aleatorios, y añadir esos bytes junto al resumen de la contraseña.

3.2. El contador de iteración

El contador de iteración es el número de veces que la función hash que realiza el resumen se aplica a sus propios resultados.

Esto significa que, una vez se ha seleccionado un «salt» y concatenado con la contraseña, se deberá aplicar la función hash (por ejemplo, MD5), conseguir el resultado, y pasarlo de nuevo como entrada a la misma función, y hacer lo mismo las veces que indique el contador de iteración.

El número mínimo recomendado de iteraciones es 1.000, y esto proporcionará una buena seguridad extra. Hay que pensar que, cuando se crea un único resumen de una contraseña para un nuevo usuario, la diferencia entre aplicar la función hash una vez o 1.000 veces no será un problema, tal vez doscientos milisegundos, pero los atacantes deberán tener que generar una enorme cantidad de intentos de resumen mediante fuerza bruta y, para un atacante, la diferencia entre aplicar la función hash una vez y aplicarla mil veces para cada intento será un gran problema computacional.

Así, se obtiene la cuarta regla:

IV. Iterar la función hash al menos 1.000 veces.

4. Secuencia de traducción de caracteres a secuencia de bytes

Antes de poder guardar correctamente los resúmenes de las contraseñas, hay algo que se debería tener en cuenta, que es la diferencia entre cadenas de caracteres y secuencias de bytes: dos cadenas de caracteres se pueden representar con diferentes secuencias de bytes dependiendo de la codificación empleada (ISO-8859-1, UTF-8, …)

Esto afecta, ya que las contraseñas suelen ser cadenas de caracteres, pero las funciones hash trabajan a nivel de byte.

4.1. Problemas codificando la contraseña introducida

En el supuesto de que un nuevo usuario se identifique con una contraseña que no contiene caracteres ASCII, y que la aplicación de identificación, que se está ejecutándo en Windows 2000 en Europa Occidental, convierta la cadena de caracteres a bytes sin elegir una codificación específica para la operación, e incluso usando la que haya de forma predeterminada, en Windows suele ser ISO-8859-1. De modo que el resumen se realice sobre esa secuencia de bytes y quede almacenado.

Entonces, este usuario vuelve de nuevo y esta vez no visita la aplicación de identificación anterior, en vez de eso usa cualquier otra aplicación con la misma base de datos de contraseñas pero en Linux. El usuario introduce correctamente su contraseña y … ¡no coincide!

¿Por qué? Porque la mayoría de los sistemas Linux, usan UTF-8 como codificación predeterminada, y las contraseñas que ha introducido el usuario en ambos casos se han codificado en diferentes secuencias de bytes, afectando a la correcta concordancia de las contraseñas.

Cómo se puede resolver esto, pues utilizando una codificación fija para las codificaciones de las cadena de caracteres a secuencia de bytes. Así se enuncia la quinta regla:

V. Antes de resumir, realizar una codificación de cadena de caracteres a secuencia de bytes usando una codificación fija, preferiblemente UTF-8.

Si se usa Java, donde las cadenas de caracteres (clases String) se codifican independientemente (aunque usan de fondo UTF-16), no habrá que preocuparse de si la aplicación usa ISO-8859-1 o alguna otra codificación en lugar de UTF-8 para su interfaz de usuario, al igual que no será necesario que la codificación para los resúmenes de las contraseñas coincidan con las de la interfaz de usuario. Sólo será necesario que la codificación sea una fija, y UTF-8 proporciona un buen equilibrio entre tamaño y conjunto de caracteres.

4.2. Problemas codificando en el almacenamiento del resumen

Normalmente se quiere gestionar y almacenar el resumen de contraseñas como una cadena de caracteres, pero la función hash dará como resultado una secuencia de bytes que no necesariamente representará un carácter válido en alguna codificación. Por esto, la secuencia de bytes del resumen no se puede codificar en una cadena de caracteres, habiendo peligro de pérdidas de datos si se realizase.

Aquí es donde entra al rescate la codificación BASE64. Codificando la secuencia de bytes del resumen en BASE64, se asegura que la secuencia de bytes de salida representa una cadena de caracteres US-ASCII válida. Por lo que se podrá codificar una secuencia de bytes en BASE64 en una cadena de caracteres US-ASCII.

VI. Finalmente, se debe aplicar la codificación BASE64 y guardar el resumen como una cadena de caracteres US-ASCII.

5. Resumen de las reglas para el cifrado de contraseñas

La lista completa de reglas a aplicar:

1. Cifrar las contraseñas usando técnicas de un sentido, es decir, funciones resumen (o hash).
2. La entrada y las contraseñas guardadas se comparan usando los resultados de las funciones resumen, no usando cadenas sin cifrar.
3. Se debe usar un «salt» que contenga al menos 8 bytes aleatorios, y añadir esos bytes junto al resumen de la contraseña.
4. Iterar la función hash al menos 1.000 veces.
5. Antes de resumir, realizar una codificación de cadena de caracteres a secuencia de bytes usando una codificación fija, preferiblemente UTF-8.
6. Finalmente, se debe aplicar la codificación BASE64 y guardar el resumen como una cadena de caracteres US-ASCII.

6. Realizándolo en Java

La forma más sencilla de cifrar contraseñas en Java, mediante las técnicas explicadas es usar Jasypt.

Si no se puede usar jasypt, o si por alguna razón se quiere desarrollar alguna característica de cifrado propia, se necesitarán:

• La clase java.security.MessageDigest para crear resúmenes. Esta clase permite especificar el algoritmo que se va a usar.
• La clase java.security.SecureRandom para generar «salt» aleatorios de una manera segura, usando algoritmos como SHA1PRNG.
• El método java.lang.String.getBytes (String charsetName), para obtener una secuencia de bytes desde una cadena de caracteres, especificando una codificación fija (UTF-8).
• La clase org.apache.commons.codec.binary.Base64, parte de la biblioteca Apache Commons-Codec, para realizar codificaciones BASE64 en la salida de la función hash.

También, se puede utilizar el código fuente para las clases org.jasypt.digest.StandardByteDigester y org.jasypt.digest.StandardStringDigester, disponible en el repositorio de jasypt.

7. Defensa frente a los típicos ataques

7.1. Ataques de fuerza bruta

Realizado sobre: Una única contraseña.

Descripción: El atacante intenta conseguir la contraseña del usuario generando todas las contraseñas posibles, resumiéndolas y probando si coinciden con el resumen de la contraseña del usuario.

Defensa: La iteración de la función hash un número de veces, como 1.000 (mínimo recomendado), el coste de la creación del resumen de la contraseña en el tiempo de identificación del usuario no es significante, pero el coste de un ataque de fuerza bruta por parte de un atacante que genera millones de resúmenes será muy grande. Hay que recordar que una de las mejores maneras de proteger los datos cifrados es haciendo que el coste de romper la seguridad sea más alto de lo que cuesta el esfuerzo.

7.2. Ataques de diccionario

Realizado sobre: Cada contraseña o una base de datos de contraseñas

Descripción: El atacante intenta conseguir la contraseña de un usuario comparando sus resúmenes contra un conjunto de resúmenes de contraseñas más probables, normalmente se generan desde una lista de palabras de un diccionario. Este ataque explota una debilidad actual de las aplicaciones, ya que muchos usuarios usan palabras del diccionario como contraseña.

Defensa: Añadiendo un «salt» aleatorio, la debilidad de las contraseñas basadas en diccionario se reduce, y la posibilidad de de que el resumen aparezca en un conjunto de resúmenes previamente creados por el atacante es mínima.

7.3. Ataques de cumpleaños

Realizado sobre: La base de datos de las contraseñas.

Descripción: Este ataque explota la paradoja del cumpleaños, la cual en resumen consiste en, teniendo un gran conjunto de resúmenes de contraseñas, las posibilidades de generar una contraseña cuyo resumen coincida con al menos uno de los resúmenes en el conjunto es mucho más alto que lo esperado. Y estas posibilidades aumentan bastante cuando el tamaño del conjunto (el número de usuarios) aumenta.

Defensa: Añadiendo un «salt» aleatorio las posibilidades de que un ataque de cumpleaños tenga éxito son mínimas, porque el atacante tendría que atacar cada contraseña por separado, y no el conjunto de contraseñas, para encontrar una coincidencia. Esto es porque se tendría que encontrar una contraseña que crease el mismo resumen que el del atacante usando el mismo «salt» que se usó para el resumen, y que es diferente para cada contraseña haciendo que el ataque pase a ser de fuerza bruta.

Espero que este pequeño manual os sea de utilidad, a mí me sirvió para mi PFC.

Todo esto no deja de ser curioso, porque hace unos días salía la noticia de que la CMT prohibía dar acceso WiFi gratis al ayuntamiento de Madrid en los autobuses, ya que no era su servicio principal, así que para ofrecer dicho servicio debería cobrar una tasa extra.

No me entere bien de la noticia de los taxis, pero me pareció ver que dicha conexión a internet era un servicio gratuito, por lo que todo esto me parece un poco contradictorio.

Además, me pregunto qué nivel de seguridad proporcionarán en dichos ultraportátiles, es decir, el taxista me puede asegurar que dicho portátil no tiene virus, que los datos (cookies, archivos temporales, …) que maneje serán borrados antes de que otro cliente lo use, que el disco está cifrado por si alguien lo roba no poder acceder a los datos, … No sé, pero recomendaría no usar dichos ordenadores para tareas que contengan datos personales.

Así que estuve buscando diferentes opciones, siendo importante que funcionase en Linux y en Windows (por si las moscas). Al final había dos opciones Truecrypt (el archiconocido) y dm-crypt (un gestor de dispositivos cifrados de Linux), me decanté por dm-crypt porque Truecrypt, curiosamente, no está en los repositorios de Debian y porque con dm-crypt no necesitaría de un programa a parte para utilizar mi dispositivo en Linux (aunque sí, en Windows).

Pasos a seguir

Directo al grano, estos son los pasos que realicé:

1. Paquetes necesarios:

   # apt-get install cryptsetup hashalot dmsetup

2. Rellenar la memoria con datos aleatorios (no es necesario, aunque sí recomendable):

   # dd if=/dev/urandom of=/dev/sdX

3. Cargar los siguientes módulos si no lo están ya:

   # modprobe aes
   # modprobe dm_crypt
   # modprobe dm_mod
   # modprobe sha256

4. Crear el contenedor cifrado (pedirá la contraseña para poder luego descifrarlo):

   # cryptsetup -v --key-size 256 luksFormat /dev/sdX NOMBRE-CONTENEDOR

5. Formatear el contenedor (yo utilicé FAT para que funcione en Windows) para ello primero hay que montar el contenedor utilizando cryptsetup:

   # cryptsetup -v luksOpen /dev/sdX NOMBRE-CONTENEDOR
   # mkfs.vfat /dev/mapper/NOMBRE-CONTENEDOR

6. Y ya está, ya se puede montar:

   # mount -t vfat /dev/mapper/NOMBRE-CONTENEDOR /mnt/usb_cifrado

Uso

Lo bueno de este método es que al enchufar la memoria en Linux, éste pedirá la contraseña y se montará automáticamente, aunque en la versión de GNOME que uso no lo monta. Así que, por si las moscas, siempre lo puedes montar ejecutando:

$ pmount-hal /dev/sdX

Y desmontar ejecutando:

$ pumount /dev/sdX

Para poder utilizar el dispositivo cifrado en Windows se necesita un programa llamado FreeOTFE que es compatible con este tipo de cifrado.

Basado en Manual de Cifrado de una particion concreta desde Linux Debian/Ubuntu.

Y es que WordPress adolece de las siguientes debilidades:

1. Proporcionar demasiada información al fallar la identificación: Siempre se ha aconsejado que cuando una identificación falle, el mensaje de error sea ambiguo y nunca menciones que parte ha fallado (usuario o contraseña), en WordPress en cambio te dice claramente que parte ha fallado, gracias a esto se podría conseguir una lista de los usuarios registrados en el blog.
2. Número máximo de intentos de identificación: Para que la gente no te pueda realizar un ataque de fuerza bruta se suele limitar el número de intentos, o incluso poner un retardo cada vez mayor entre intentos. WordPress no hace ni lo uno ni lo otro.

Gracias a estos dos puntos, se puede conseguir realizar un ataque de fuerza bruta contra WordPress, ya que se pueden conseguir los usuarios (amén de que siempre existe uno llamado admin) para acto seguido atacar a cada uno de ellos con un script (los hay en abundancia) que se dedique a probar contraseñas, mientras nosotros esperamos (el tiempo que estaremos esperando dependerá de la complejidad de la contraseña) a que acierte.

Actualización: Para solventar el problema de los intentos (a mí juicio el más grave) he encontrado el complemento Login LockDown.

Hay que decir que el evento fue magnífico, estuvo muy bien organizado y encima vinieron unos ponentes de relumbrón, aunque la estrella era Bruce Schneier.

La mesa redonda estuvo muy entretenida, hablaron sobre cómo mejorar la situación actual de la seguridad, centrándose casi siempre en si se debería enfocar desde la educación a la gente o que fuese la tecnológica la que mejorase en este apartado.

Yo me quedaría con la explicación que realizó un miembro del grupo de delitos telemáticos de la guardia civil, sobre todos los pasos que tienen que dar hasta atrapar al tipo malo y como se hace casi imposible cuando las herramientas que usan (por ejemplo: una botnet) están en fuera de España.

Al final de todo había un cocktail dónde la gente se relacionaba, yo sólo conocía a mis compañeros de trabajo y a Victor Pimentel al que saludé, aunque por la cara que puso creo que tardó en reconocerme.

Por supuesto, repetiré en la próxima edición.

[+] Resumen del security blogger summit en security by default
[+] Resumen del security blogger summit en error500

Muchos clicks para mi gusto, si queréis un ejemplo visitad Google Reader con dominio es.

Por este motivo, se me ocurrió hacer un pequeño programa (en C) que genera contraseñas aleatorias (llamado passwdgen), con una serie de opciones:

• En base al conjunto alfanumérico (alfabeto en mayúsculas, minúsculas y/o números).
• Longitud mínima y/o máxima personalizable, si se le da una mínima y otra máxima se escogerá una longitud aleatoria entre los valores dados. (La longitud predeterminada es de ocho caracteres)

De este modo, se genera aleatoriamente una cadena de caracteres en base al conjunto de caracteres y la longitud que queramos. Lo he subido a Google Code para que todos podáis hacer uso de él y/o si queréis trastear con el código, está licenciado bajo GPL 2.

Si estáis interesados, visitad la web de passwdgen.

PD: Seguramente ya lo hayáis visto en muchos otros sitios, pero es que la tira es genial.