Contraseñas en la memoria, formas prácticas de mejorar la seguridad

Question

Contraseñas en la memoria, formas prácticas de mejorar la seguridad

#1 de Sjoerd (2 votos)
#2 de Lie Ryan (1 votos)
#3 de nwildner (1 votos)

2

El almacenamiento de una contraseña en la memoria de una aplicación es arriesgado. El sistema operativo puede escribir una parte de la memoria en el disco como un archivo de intercambio. Los procesos pueden acceder a la memoria de los demás, aunque no deberían. (Más)

Estoy desarrollando un generador de contraseñas determinista con Java y me pregunto cuál es la mejor manera de manejar la clave maestra en la memoria. Habrá períodos de tiempo en los que la aplicación necesita "recordar" la clave maestra, antes de que pueda sobrescribirla en la memoria. Pensé en cifrar la clave maestra en la memoria y escribir la clave de descifrado generada aleatoriamente en el disco. Cuando la clave maestra ya no sea necesaria, la aplicación intentará sobrescribir tanto el archivo en el disco como la clave maestra cifrada. Este enfoque al menos brindaría cierta seguridad contra alguien que luego descubrirá un archivo de intercambio antiguo. ¿Tiene sentido? ¿Debo hacer otra cosa?

¿Cuáles son las buenas prácticas para reducir la vida útil de las contraseñas y las claves criptográficas en la memoria?

password-management data-leakage java memory

pregunta Atte Juvonen 13.01.2017 - 14:13

fuente

3 respuestas

Lea otras preguntas en las etiquetas password-management data-leakage java memory

Cifrado de objetos Java ¿Por qué usar enmascaramiento de bits en SQLi ciego?

score 2 · Answer 1

2

En Java, se recomienda que un char[] se usa para datos confidenciales en lugar de un objeto String . Esto hace posible sobrescribir los datos cuando se realiza con ellos, algo que no es posible con el objeto String inmutable.

respondido por el Sjoerd 13.01.2017 - 14:36

fuente

score 1 · Answer 2

¿Cuáles son las buenas prácticas para reducir la vida útil de las contraseñas y claves criptográficas en la memoria?

Cifre su archivo / partición de intercambio. Entonces no debería preocuparse por la pérdida de contraseñas de intercambio.

Si escribe el programa, también debería usar las características del sistema que evitan que ciertas partes de la memoria se paguen, usando mlock () o mmap () con MAP_LOCKED en Linux o VirtualLock () en Windows.

Hoy en día, muchos sistemas Linux están configurados de modo que, a menos que sea root o tenga permiso de seguimiento, no puede leer / escribir directamente en otro proceso del mismo usuario a menos que el otro proceso sea un proceso secundario del proceso de rastreo (ptrace_scope = 1 ). Si necesita una mayor seguridad, también puede configurar para que ptrace child solo sea posible por root o procesos con capacidad CAP_SYS_PTRACE (ptrace_scope = 2) o deshabilitar ptrace por completo (ptrace_scope = 3). En Windows, este permiso se llama SE_DEBUG_PRIVILEGE.

La mejor práctica si está trabajando en un lenguaje multiplataforma de nivel superior como Java es dejar la administración de claves a un proceso separado como gpg-agent o ssh-agent. O a un módulo de seguridad de hardware, que realiza la administración de claves, la autenticación o el cifrado / descifrado en un hardware separado. Otra opción es que muchos sistemas modernos también pueden admitir TPM, lo que le brinda esencialmente HSM integrado.

score 1 · Answer 3

Podría usar un GuardedString con el fin de mantener las cadenas de contraseña un poco más seguras. Es un objeto String especial diseñado para tratar los problemas de tener contraseñas guardadas en la memoria representada por String:

Paquete org.identityconnectors.common.security.GuardedString versión 0.2.3. Citando la documentación del archivo de clase GuardedString:

Implementación de cadena segura que resuelve los problemas asociados con manteniendo las contraseñas como java.lang.String. Es decir, cualquier cosa representada. como una cadena se guarda en la memoria como una contraseña de texto claro y permanece en Recuerdo al menos hasta que sea basura recogida. La clase GuardedString alivia este problema almacenando los caracteres en la memoria en una forma encriptada. La clave de cifrado será una clave generada aleatoriamente. En su forma serializada, GuardedString se cifrará usando un clave por defecto conocida. Esto es para proporcionar un nivel mínimo de protección. independientemente del transporte. Para comunicaciones con el mando a distancia. En el marco del conector se recomienda que las implementaciones habiliten SSL para cifrado de verdad Las aplicaciones también pueden desear persistir GuardedStrings. En el caso de Identity Manager, debería convertir GuardedStrings a EncryptedData para que puedan ser almacenados y administrados usando el Gestionar Características de cifrado de Identity Manager. Otras aplicaciones pueden desear para serializar APIConfiguración en su conjunto. Estas aplicaciones son responsable de cifrar el blob APIConfiguration para un adicional capa de seguridad (más allá del cifrado de clave predeterminado básico proporcionado por GuardedString).