Las cadenas son inmutables . Eso significa que una vez que haya creado 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. Puede sobrescribir la matriz con lo que quiera, y la contraseña no estará presente en ninguna parte del sistema, incluso antes de la recolección de elementos no utilizados.

Así que sí, este es un problema de seguridad, pero incluso usar char[] solo reduce la ventana de oportunidad para un atacante, y es solo para este tipo específico de ataque.

Como se indica en los comentarios, es posible que el recolector de elementos no utilizados mueva las matrices y deje copias sueltas 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 un tiempo durante el cual char[] contiene los caracteres reales como una ventana de ataque.

Mientras que otras sugerencias aquí parecen válidas, hay otra buena razón. Con String simple, tiene muchas más posibilidades de imprimir accidentalmente la contraseña en registros , monitores o algún 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 Java Cryptography Architecture dice esto sobre las contraseñas char[] vs. String (sobre el cifrado basado en contraseñas, pero esto es más general sobre las contraseñas, por supuesto):

Parecería lógico recopilar y almacenar la contraseña en un objeto de tipo java.lang.String . Sin embargo, aquí está la advertencia: los Object de tipo String son inmutables, es decir, no hay métodos definidos que le permitan cambiar (sobrescribir) o poner a cero el contenido de una String después de su uso. Esta característica hace que los objetos String no sean adecuados para almacenar información confidencial de seguridad, como contraseñas de usuario. En su lugar, siempre debe recopilar y almacenar información confidencial de seguridad en una char de caracteres.

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 está en el contexto del registro):

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

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

Esta directriz también tiene implicaciones para la implementación y el uso de bibliotecas de nivel inferior que no tienen 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.