Esto, que en principio puede parecer un gran avance porque evita problemas de seguridad en los programas (uno de los motivos por los que en Java no se pueden manejar punteros), al final se demuestra que es un nido de bugs. Porque 212 no son -44. Y esto puede ser un auténtico problema en algo tan visible como una fecha.

El mes de marzo es un mes muy especial. Su mes anterior es de longitud variable (28 ó 29 días) y el siguiente es de 30, siendo el propio marzo de 31. Ved el siguiente código:

Calendar cal = new GregorianCalendar();
cal.set (Calendar.DAY_OF_MONTH, 30);
cal.set (Calendar.MONTH, 2);
System.out.println (cal.getTime ());
System.out.println (cal.getActualMaximum (Calendar.DAY_OF_MONTH));
cal.set (Calendar.MONTH, cal.get(Calendar.MONTH) -1);
System.out.println (cal.getActualMaximum (Calendar.DAY_OF_MONTH));

Esencialmente, lo que hace es ponernos en 30 de marzo de este año y sacar por pantalla los siguientes datos:

• Fecha actual
• Número de días del mes de marzo
• Número de días del mes de… ¿febrero?

Java, en su excelsa sabiduría, ha decidido que en este caso que 2-1=2. Porque al restar uno al mes nos quedamos en 30 de febrero o, lo que es lo mismo, 2 de marzo. Esta chorrada (obviamente en un código más complejo) nos tuvo en el trabajo una mañana entretenidos porque el número de días de los meses siempre eran 30 ó 31, incluído un inexistente febrero.

En parte fue una suerte que estuviéramos a 30 de marzo y no en 2 de abril, en cuyo caso nos daríamos cuenta del problema casi un año después de sacar el proyecto a producción. A veces Java es realmente odioso con su “deja que la JVM piense por ti“.

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.

Si alguna vez habéis necesitado internacionalizar en Java, os habréis encontrado con la clase ResourceBundle, esta clase permite la traducción a partir de un archivo tipo properties (que se basa en líneas campo = valor).

Lo malo es que Java trata estos archivos properties utilizando la codificación ISO-8859-1, de modo que si utilizas un archivo properties guardado en UTF-8 algunos símbolos (por ejemplo: la eñe) se mostrarán de forma incorrecta. Para solucionar este problema, se debe usar el siguiente truco:

import java.io.UnsupportedEncodingException;
import java.util.ResourceBundle;

public class UTFi18n {

    // Messages es el nombre del archivo que contiene los mensajes traducidos
    private ResourceBundle messages =  ResourceBundle.getBundle ("Messages");

    public static String getMessage (String message) {

        String value = messages.getString (message);
        String ret;

        try {
            // Hack to manage properties files using UTF-8
            ret = new String (value.getBytes ("ISO-8859-1"), "UTF-8");

        } catch (UnsupportedEncodingException encEx) {
            ret = value;
        }

        return ret;
    }
}

Basado en Quick and Dirty Hack for UTF-8 Support in ResourceBundle de Thoughts About.

Este mecanismo ofrece una clase llamada JSObject que permite realizar la comunicación del applet a JavaScript, esta clase se localiza en el paquete netscape.javascript.

Lo malo es que esta clase tiene varios problemas y fallos relacionados que no vienen documentados en ningún sitio, sólo en algunas páginas de gente que ha conseguido averiguarlos por su cuenta.

JSObject no es thread safe

En los ejemplos de la página de Sun dedicada a la clase JSObject, se puede ver un ejemplo de su uso:

import netscape.javascript.*;
import java.applet.*;
import java.awt.*;

class MyApplet extends Applet {
    public void init() {
        JSObject win = JSObject.getWindow (this);
        JSObject doc = (JSObject) win.getMember ("document");
        JSObject loc = (JSObject) doc.getMember ("location");

        // document.location.href
        String s = (String) loc.getMember ("href");
        win.call ("f", null);   // Call f() in HTML page
    }
}

Bien, pues este uso no es correcto, ya que esta clase no es thread safe y en las versiones más recientes del complemento de Java para los navegadores, puede que la máquina virtual de Java ejecute varios hilos y el uso de esta clase acabe fallando. Para arreglarlo, sólo se debe hacer lo siguiente:

synchronized (JSObject.class) {
    win = JSObject.getWindow (applet);
}

Básicamente, se trata de encapsular el uso de la clase JSObject en un bloque synchronized para evitar fallos por cualquier causa relacionada con hilos.

JSObject.getMember () no funciona en Firefox sobre Mac OS X

Otro problema que tiene esta clase es que en la versión de Firefox para Mac OS X, el método getMember no funciona bien y siempre devuelve null, lo que obliga a usar un trozo de código algo feo. Por ejemplo, para obtener el userAgent del navegador:

synchronized (JSObject.class) {
    win = JSObject.getWindow (applet);
}
JSObject nav = win.getMember ("navigator");
String userAgent = (String) nav.getMember ("userAgent");

Utilizando el método getMember.

synchronized (JSObject.class) {
    win = JSObject.getWindow (applet);
}
String userAgent = (String) win.eval ("navigator.userAgent");

Un apaño, utilizando el método eval.