2009-10-02 8 views
6

Supongamos que hay una variable String que contiene una contraseña de texto sin formato.¿Alguien puede robar una contraseña de una aplicación Java?

Existe la posibilidad de leer esta contraseña mediante un volcado de memoria. (Supongamos que usa el motor de trucos.) Estoy desconcertado con esta cosa de JVM. ¿JVM proporciona algún tipo de protección contra esto? Si no, ¿cuáles son las prácticas que necesito usar para evitar ese "robo"?

Una amenaza práctica sería un troyano; que envía los segmentos del volcado de memoria a una parte externa.

+2

Me gustaría señalar que todas las respuestas hasta la fecha son igualmente aplicables a casi todos los idiomas, no solo a Java. El problema es exactamente el mismo. Algunos idiomas pueden hacer que sea un poco más fácil o más difícil que otros, pero todos tienen la misma "vulnerabilidad" básica. –

+0

Si ese "alguien" tiene acceso a la JVM sin ningún motivo obvio, hay cosas peores que los ataques de inspección de montón de los que preocuparse. La mayoría de la gente diría 'Game Over'. Pregunta SO similar en http://stackoverflow.com/questions/646224/how-does-one-store-password-hashes-securely-in-memory-when-creating-accounts –

+0

almacene la contraseña en un servidor y compruébela cuando necesario –

Respuesta

11

como ya se dijo, sí, cualquiera puede extraer la contraseña, de diversas maneras. Encriptar la contraseña no será de gran ayuda: si la aplicación la descifra, la forma desencriptada también estará presente en algún momento, además la clave de descifrado (o código) se convierte en una vulnerabilidad. Si se envía a otro lugar en forma encriptada, el simple hecho de conocer la forma encriptada es suficiente para suplantar la transacción, por lo que tampoco ayuda mucho.

Básicamente, siempre que el "atacante" sea también el "emisor", eventualmente se va a agrietar, esta es la razón por la cual las industrias de música y video no pueden hacer que DRM funcione.

Le sugiero que obtenga una copia de Applied Cryptography y lea la primera sección, "Protocolos criptográficos". Incluso sin entrar en las matemáticas de la criptografía real, esto le dará una buena visión general de todo tipo de patrones de diseño en esta área.

7

Si mantiene la contraseña en texto sin formato en la aplicación, alguien puede leerla al jugar con volcados de memoria, independientemente del idioma o el tiempo de ejecución que utilice.

Para reduzca la posibilidad de que esto ocurra solo mantenga la contraseña en texto sin formato cuando realmente lo necesita, luego voltéela o encripte. Una cosa a tener en cuenta aquí es que JPasswordField devuelve un char [] en lugar de una cadena. Esto se debe a que no tienes control sobre cuándo desaparecerá la cadena. Si bien no tienes control sobre cuándo desaparecerá un char [], puedes llenarlo con basura cuando hayas terminado con la contraseña.

Digo reducir ya que esto no detendrá a alguien. Siempre y cuando la contraseña esté en la memoria, se puede recuperar y, como el descifrado también debe ser parte del entregable, también se puede descifrar dejando abierta su contraseña.

+0

Sí, para (char nextChar: pw) nextChar = 0; // Lo que puede no funcionar, tenga en cuenta también: final char [] no es final –

+0

Deberá utilizar un bucle for normal en lugar de un foreach. Y sí, vale la pena indicar que la final se aplica a la referencia de una matriz y no a los valores. –

2

Si el programa conoce la contraseña, cualquiera que use el programa puede extraer la contraseña.

+3

cualquiera con suficiente habilidad técnica ... –

2

En teoría, usted podría simplemente conectarlo al depurador ... ... establecer un punto de interrupción y leer los contenidos de la cadena

4

Esto no tiene nada que ver con Java - exactamente el mismo problema (si realmente es uno) existe para aplicaciones escritas en cualquier idioma:

  • Si el ejecutable contiene una contraseña, no importa qué tan ofuscado o encriptado , cualquiera que tenga acceso al ejecutable puede encontrar la contraseña.
  • Si una aplicación conoce temporalmente una contraseña o clave (por ejemplo, como parte de un protocolo de autenticación de red), cualquiera que pueda observar la memoria en la que se está ejecutando la aplicación puede encontrar la contraseña.

Este último no se considera habitualmente un problema, ya que un sistema operativo moderno no permite aplicaciones arbitrarias para observar la memoria de cada uno, y privilege escalation ataques normalmente se basan en diferentes vectores de ataque.

+0

Es un problema si no lo conoce y desarrolla su sistema como si la clave "encriptada" fuera realmente segura. –

Cuestiones relacionadas