¿Por qué se prefiere char [] sobre String para contraseñas?

En Swing, el campo de contraseña tiene un método getPassword()(devoluciones char[]) en lugar del método habitual getText()(devoluciones String). Del mismo modo, he encontrado una sugerencia de no usar Stringpara manejar contraseñas.

¿Por qué Stringrepresenta una amenaza para la seguridad cuando se trata de contraseñas? Se siente incómodo de usar char[].

Las cuerdas son inmutables . Eso significa que una vez que haya creado el String, si otro proceso puede volcar la memoria, no hay forma (aparte de la reflexión ) de que pueda deshacerse de los datos antes de que comience la recolección de basura .

Con una matriz, puede borrar explícitamente los datos una vez que haya terminado con ella. Puede sobrescribir la matriz con lo que desee, y la contraseña no estará presente en ninguna parte del sistema, incluso antes de la recolección de basura.

Entonces, sí, esto es un problema de seguridad, pero incluso el uso char[]solo reduce la ventana de oportunidad para un atacante, y es solo para este tipo específico de ataque.

Como se señaló en los comentarios, es posible que las matrices que mueve el recolector de basura dejarán copias perdidas de los datos en la memoria. Creo que esto es específico de la implementación: el recolector de basura puede borrar toda la memoria a medida que avanza, para evitar este tipo de cosas. Incluso si lo hace, todavía hay el tiempo durante el cual char[]contiene los personajes reales como una ventana de ataque.

Si bien otras sugerencias aquí parecen válidas, hay otra buena razón. Con plain Stringtiene muchas más posibilidades de imprimir accidentalmente la contraseña en registros , monitores u otro lugar inseguro. char[]Es menos vulnerable.

Considera esto:

public static void main(String[] args) {
    Object pw = "Password";
    System.out.println("String: " + pw);

    pw = "Password".toCharArray();
    System.out.println("Array: " + pw);
}

Huellas dactilares:

String: Password
Array: [C@5829428e

Para citar un documento oficial, la guía de Java Cryptography Architecture dice lo siguiente acerca char[]vs. Stringcontraseñas (sobre la encriptación basada en contraseña, pero esto es más general acerca de las contraseñas, por supuesto):

Parece lógico recopilar y almacenar la contraseña en un objeto de tipo java.lang.String. Sin embargo, estas son las advertencias: Objectlos tipos Stringson inmutables, es decir, no hay métodos definidos que le permitan cambiar (sobrescribir) o poner a cero el contenido de un String uso posterior. Esta característica hace que los Stringobjetos no sean adecuados para almacenar información confidencial de seguridad, como las contraseñas de los usuarios. En su lugar, siempre debe recopilar y almacenar información confidencial de seguridad en una charmatriz.

La Pauta 2-2 de las Pautas de codificación segura para el lenguaje de programación Java, versión 4.0 también dice algo similar (aunque originalmente se encuentra en el contexto del registro):

Pauta 2-2: No registrar información altamente confidencial

Parte de la información, como los números de Seguro Social (SSN) y las contraseñas, es altamente confidencial. Esta información no debe conservarse durante más tiempo del necesario ni donde pueda verse, incluso por los administradores. Por ejemplo, no debe enviarse a archivos de registro y su presencia no debe ser detectable a través de búsquedas. Algunos datos transitorios pueden guardarse en estructuras de datos mutables, como las matrices de caracteres, y borrarse inmediatamente después de su uso. La eliminación de estructuras de datos ha reducido la efectividad en los sistemas de tiempo de ejecución Java típicos, ya que los objetos se mueven en la memoria de forma transparente al programador.

Esta guía también tiene implicaciones para la implementación y el uso de bibliotecas de nivel inferior que no tienen un conocimiento semántico de los datos con los que están tratando. Como ejemplo, una biblioteca de análisis de cadenas de bajo nivel puede registrar el texto en el que trabaja. Una aplicación puede analizar un SSN con la biblioteca. Esto crea una situación en la que los SSN están disponibles para los administradores con acceso a los archivos de registro.

Las matrices de caracteres ( char[]) se pueden borrar después del uso al establecer cada carácter en cero y las cadenas no. Si alguien puede ver de alguna manera la imagen de la memoria, puede ver una contraseña en texto sin formato si se usan cadenas, pero si char[]se usa, después de purgar los datos con 0, la contraseña es segura.

Algunas personas creen que tiene que sobrescribir la memoria utilizada para almacenar la contraseña una vez que ya no la necesita. Esto reduce el tiempo que un atacante tiene que leer la contraseña de su sistema e ignora por completo el hecho de que el atacante ya necesita acceso suficiente para secuestrar la memoria JVM para hacer esto. Un atacante con tanto acceso puede atrapar tus eventos clave y hacer que esto sea completamente inútil (AFAIK, así que corrígeme si me equivoco).

Actualizar

Gracias a los comentarios tengo que actualizar mi respuesta. Aparentemente, hay dos casos en los que esto puede agregar una mejora de seguridad (muy) menor, ya que reduce el tiempo que una contraseña podría aterrizar en el disco duro. Aún así, creo que es excesivo para la mayoría de los casos de uso.

• Su sistema de destino puede estar mal configurado o debe asumir que lo es y debe ser paranoico con respecto a los volcados del núcleo (puede ser válido si los sistemas no son administrados por un administrador).
• Su software debe ser demasiado paranoico para evitar fugas de datos con el atacante obteniendo acceso al hardware, utilizando cosas como TrueCrypt (descontinuado), VeraCrypt o CipherShed .

Si es posible, deshabilitar los volcados del núcleo y el archivo de intercambio se encargará de ambos problemas. Sin embargo, requerirían derechos de administrador y podrían reducir la funcionalidad (menos memoria para usar) y extraer RAM de un sistema en ejecución seguiría siendo una preocupación válida.

No creo que sea una sugerencia válida, pero al menos puedo adivinar el motivo.

Creo que la motivación es querer asegurarse de que puede borrar todo rastro de la contraseña en la memoria de manera rápida y segura después de su uso. Con un char[]podría sobrescribir cada elemento de la matriz con un espacio en blanco o algo seguro. No puede editar el valor interno de Stringesa manera.

Pero eso solo no es una buena respuesta; ¿por qué no simplemente asegurarse de que no se escape una referencia al char[]o Stringno? Entonces no hay problema de seguridad. Pero la cuestión es que los Stringobjetos pueden ser intern()editados en teoría y mantenerse vivos dentro del grupo constante. Supongo que usar char[]prohíbe esta posibilidad.

La respuesta ya se ha dado, pero me gustaría compartir un problema que descubrí últimamente con las bibliotecas estándar de Java. Si bien ahora tienen mucho cuidado de reemplazar las cadenas de contraseña por char[]todas partes (lo que, por supuesto, es algo bueno), otros datos críticos de seguridad parecen pasarse por alto cuando se trata de borrarlos de la memoria.

Estoy pensando, por ejemplo, en la clase PrivateKey . Considere un escenario en el que cargaría una clave RSA privada desde un archivo PKCS # 12, utilizándola para realizar alguna operación. Ahora, en este caso, solo rastrear la contraseña no lo ayudaría siempre y cuando el acceso físico al archivo de clave esté restringido adecuadamente. Como atacante, estaría mucho mejor si obtuviera la clave directamente en lugar de la contraseña. La información deseada puede ser filtrada, volcados de núcleo, una sesión de depurador o archivos de intercambio son solo algunos ejemplos.

Y resulta que no hay nada que le permita borrar la información privada de a PrivateKeyde la memoria, porque no hay API que le permita borrar los bytes que forman la información correspondiente.

Esta es una mala situación, ya que este documento describe cómo esta circunstancia podría ser potencialmente explotada.

La biblioteca OpenSSL, por ejemplo, sobrescribe secciones de memoria críticas antes de liberar las claves privadas. Como Java se recolecta basura, necesitaríamos métodos explícitos para borrar e invalidar la información privada de las claves Java, que se aplicarán inmediatamente después de usar la clave.

Como dice Jon Skeet, no hay manera, excepto mediante el uso de la reflexión.

Sin embargo, si la reflexión es una opción para usted, puede hacerlo.

public static void main(String[] args) {
    System.out.println("please enter a password");
    // don't actually do this, this is an example only.
    Scanner in = new Scanner(System.in);
    String password = in.nextLine();
    usePassword(password);

    clearString(password);

    System.out.println("password: '" + password + "'");
}

private static void usePassword(String password) {

}

private static void clearString(String password) {
    try {
        Field value = String.class.getDeclaredField("value");
        value.setAccessible(true);
        char[] chars = (char[]) value.get(password);
        Arrays.fill(chars, '*');
    } catch (Exception e) {
        throw new AssertionError(e);
    }
}

cuando corre

please enter a password
hello world
password: '***********'

Nota: si el carácter de String [] se ha copiado como parte de un ciclo de GC, existe la posibilidad de que la copia anterior esté en algún lugar de la memoria.

Esta copia antigua no aparecería en un volcado de almacenamiento dinámico, pero si tiene acceso directo a la memoria sin procesar del proceso, podría verla. En general, debe evitar que alguien tenga dicho acceso.

Estas son todas las razones, uno debe elegir una matriz char [] en lugar de String para una contraseña.

1. Dado que los Strings son inmutables en Java, si almacena la contraseña como texto sin formato, estará disponible en la memoria hasta que el recolector de basura lo borre, y dado que String se usa en el conjunto de String para su reutilización, existe una posibilidad bastante alta de que lo haga permanecer en la memoria durante un período prolongado, lo que representa una amenaza para la seguridad.

Dado que cualquiera que tenga acceso al volcado de memoria puede encontrar la contraseña en texto sin cifrar, esa es otra razón por la que siempre debe usar una contraseña encriptada en lugar de texto sin formato. Dado que las cadenas son inmutables, no hay forma de que el contenido de las cadenas se pueda cambiar porque cualquier cambio producirá una nueva cadena, mientras que si usa un carácter [] aún puede establecer todos los elementos en blanco o cero. Por lo tanto, almacenar una contraseña en una matriz de caracteres mitiga claramente el riesgo de seguridad de robar una contraseña.

2. Java mismo recomienda usar el método getPassword () de JPasswordField que devuelve un char [], en lugar del método obsoleto getText () que devuelve las contraseñas en texto claro indicando razones de seguridad. Es bueno seguir los consejos del equipo de Java y adherirse a los estándares en lugar de ir en contra de ellos.

3. Con String siempre existe el riesgo de imprimir texto sin formato en un archivo de registro o consola, pero si usa una matriz, no imprimirá el contenido de una matriz, sino que se imprimirá su ubicación de memoria. Aunque no es una razón real, todavía tiene sentido.

String strPassword="Unknown";
char[] charPassword= new char[]{'U','n','k','w','o','n'};
System.out.println("String password: " + strPassword);
System.out.println("Character password: " + charPassword);

String password: Unknown
Character password: [C@110b053

Referenciado desde este blog . Espero que esto ayude.

Editar: Volviendo a esta respuesta después de un año de investigación de seguridad, me doy cuenta de que tiene la desafortunada implicación de que realmente compararía las contraseñas de texto sin formato. Por favor no lo hagas. Use un hash unidireccional seguro con sal y un número razonable de iteraciones . Considere usar una biblioteca: ¡esto es difícil de entender!

Respuesta original: ¿Qué pasa con el hecho de que String.equals () utiliza la evaluación de cortocircuito y, por lo tanto, es vulnerable a un ataque de sincronización? Puede ser poco probable, pero teóricamente podría cronometrar la comparación de contraseña para determinar la secuencia correcta de caracteres.

public boolean equals(Object anObject) {
    if (this == anObject) {
        return true;
    }
    if (anObject instanceof String) {
        String anotherString = (String)anObject;
        int n = value.length;
        // Quits here if Strings are different lengths.
        if (n == anotherString.value.length) {
            char v1[] = value;
            char v2[] = anotherString.value;
            int i = 0;
            // Quits here at first different character.
            while (n-- != 0) {
                if (v1[i] != v2[i])
                    return false;
                i++;
            }
            return true;
        }
    }
    return false;
}

Algunos recursos más sobre ataques de tiempo:

• Una lección de ataques de tiempo
• Una discusión sobre el tiempo de los ataques en el intercambio de pilas de seguridad de la información
• Y, por supuesto, la página Wikipedia de Timing Attack

No hay nada que le dé char array frente a String a menos que lo limpie manualmente después de su uso, y no he visto a nadie realmente haciendo eso. Entonces, para mí, la preferencia de char [] frente a String es un poco exagerada.

Eche un vistazo a la biblioteca Spring Security _{ampliamente utilizada} aquí y pregúntese: ¿son incompetentes los tipos de Spring Security o las contraseñas char [] simplemente no tienen mucho sentido? Cuando un pirata informático desagradable toma volcados de memoria de su RAM, asegúrese de obtener todas las contraseñas, incluso si utiliza formas sofisticadas para ocultarlas.

Sin embargo, Java cambia todo el tiempo, y algunas características aterradoras como la función de deduplicación de cadenas de Java 8 pueden internar objetos de cadenas sin su conocimiento. Pero esa es una conversación diferente.

Las cadenas son inmutables y no se pueden modificar una vez que se han creado. Crear una contraseña como una cadena dejará referencias parciales a la contraseña en el montón o en el conjunto de cadenas. Ahora, si alguien realiza un volcado del proceso Java y lo escanea cuidadosamente, podría adivinar las contraseñas. Por supuesto, estas cadenas no utilizadas se recogerán como basura, pero eso depende de cuándo se active el GC.

Por otro lado, char [] son ​​mutables tan pronto como se realiza la autenticación, puede sobrescribirlos con cualquier carácter como todas las M o barras invertidas. Ahora, incluso si alguien realiza un volcado de almacenamiento dinámico, es posible que no pueda obtener las contraseñas que no están actualmente en uso. Esto le da más control en el sentido de borrar el contenido del Objeto usted mismo frente a esperar a que el GC lo haga.

La cadena es inmutable y va al grupo de cadenas. Una vez escrito, no se puede sobrescribir.

char[] es una matriz que debe sobrescribir una vez que haya usado la contraseña y así es como debe hacerse:

char[] passw = request.getPassword().toCharArray()
if (comparePasswords(dbPassword, passw) {
 allowUser = true;
 cleanPassword(passw);
 cleanPassword(dbPassword);
 passw=null;
}

private static void cleanPassword (char[] pass) {

Arrays.fill(pass, '0');
}

Un escenario en el que el atacante podría usarlo es un crashdump: cuando la JVM se bloquea y genera un volcado de memoria, podrá ver la contraseña.

Eso no es necesariamente un atacante externo malicioso. Este podría ser un usuario de soporte que tiene acceso al servidor para fines de monitoreo. Podía echar un vistazo a una caída de emergencia y encontrar las contraseñas.

La respuesta corta y directa sería porque char[]es mutable mientras que los Stringobjetos no lo son.

StringsEn Java son objetos inmutables. Es por eso que no pueden modificarse una vez creados, y por lo tanto, la única forma de eliminar su contenido de la memoria es recolectar basura. Será solo entonces cuando la memoria liberada por el objeto pueda sobrescribirse y los datos se habrán ido.

Ahora la recolección de basura en Java no ocurre en ningún intervalo garantizado. Por Stringlo tanto, puede permanecer en la memoria durante mucho tiempo, y si un proceso se bloquea durante este tiempo, el contenido de la cadena puede terminar en un volcado de memoria o algún registro.

Con una matriz de caracteres , puede leer la contraseña, terminar de trabajar con ella tan pronto como sea posible y luego cambiar de inmediato el contenido.

La cadena en Java es inmutable. Por lo tanto, cada vez que se crea una cadena, permanecerá en la memoria hasta que se recolecte basura. Por lo tanto, cualquiera que tenga acceso a la memoria puede leer el valor de la cadena.
Si se modifica el valor de la cadena, terminará creando una nueva cadena. Por lo tanto, tanto el valor original como el valor modificado permanecen en la memoria hasta que se recolecta basura.

Con la matriz de caracteres, el contenido de la matriz se puede modificar o borrar una vez que se cumple el propósito de la contraseña. El contenido original de la matriz no se encontrará en la memoria después de que se modifique e incluso antes de que comience la recolección de basura.

Debido a la preocupación de seguridad, es mejor almacenar la contraseña como una matriz de caracteres.

Es discutible si debe usar String o Char [] para este propósito porque ambos tienen sus ventajas y desventajas. Depende de lo que el usuario necesite.

Dado que las cadenas en Java son inmutables, cada vez que algunos intentan manipular su cadena, crea un nuevo objeto y la cadena existente no se ve afectada. Esto podría verse como una ventaja para almacenar una contraseña como una cadena, pero el objeto permanece en la memoria incluso después de su uso. Entonces, si alguien obtuvo de alguna manera la ubicación de la memoria del objeto, esa persona puede rastrear fácilmente su contraseña almacenada en esa ubicación.

Char [] es mutable, pero tiene la ventaja de que después de su uso, el programador puede limpiar explícitamente la matriz o anular los valores. Entonces, cuando termina de usarse, se limpia y nadie podría saber sobre la información que había almacenado.

En base a las circunstancias anteriores, uno puede hacerse una idea de si ir con String o ir con Char [] para sus requisitos.

Cadena de caja:

    String password = "ill stay in StringPool after Death !!!";
    // some long code goes
    // ...Now I want to remove traces of password
    password = null;
    password = "";
    // above attempts wil change value of password
    // but the actual password can be traced from String pool through memory dump, if not garbage collected

Caso CHAR ARRAY:

    char[] passArray = {'p','a','s','s','w','o','r','d'};
    // some long code goes
    // ...Now I want to remove traces of password
    for (int i=0; i<passArray.length;i++){
        passArray[i] = 'x';
    }
    // Now you ACTUALLY DESTROYED traces of password form memory