¿Es seguro el almacenamiento de sesión HTML5 para almacenar temporalmente una clave criptográfica?

7

Supongamos que estoy creando una aplicación web local (por ejemplo, una extensión de navegador) en HTML5 para cifrar una base de datos localmente. El acceso a la base de datos se controla mediante una contraseña y una clave maestra criptográfica se deriva de la contraseña mediante un PBKDF. Quiero almacenar la clave maestra derivada en la memoria solo mientras la aplicación está en uso para poder cifrar y descifrar los registros según sea necesario.

He examinado el uso de sessionStorage para este propósito. La ventaja es que la clave solo debe estar en la memoria y disponible en la pestaña del navegador actual. La clave se debe eliminar si esa pestaña o el navegador está cerrado. La ventaja es que si necesita actualizar la pestaña del navegador, seguirá teniendo la sesión activa y la clave maestra, de lo contrario tendrá que volver a ingresar la contraseña en cada actualización. Sin embargo, la actualización puede ser poco frecuente ya que es una aplicación de una sola página.

Al leer la especificación de sessionStorage en W3C, existe alguna preocupación:

  

La vida útil de un contexto de navegación puede no estar relacionada con la vida útil del proceso real del agente de usuario, ya que el agente de usuario puede admitir la reanudación de sesiones después de un reinicio.

¿Se trata de un reinicio del sistema operativo o un reinicio del navegador?

Lo que absolutamente quiero evitar es tener la clave criptográfica escrita en el disco donde es muy difícil deshacerse de ella. ¿La cita anterior indica que existe la posibilidad de que la clave en sessionStorage pueda almacenarse en el disco como parte del proceso de recuperación / reinicio de fallos? ¿O es este proceso de reinicio generalmente manejado solo en memoria?

a) ¿Alguien tiene algún conocimiento sobre cómo los exploradores de código abierto de Nivel 1 (Firefox, Chromium) manejan el SessionStorage y si los contenidos podrían escribirse en el disco, incluso temporalmente en el caso de un bloqueo del navegador?

b) ¿Existen mitigaciones para evitar que se produzcan fugas de la clave al disco en un bloqueo o reinicio del navegador? ¿Hay alguna configuración about:config que se pueda usar para inhabilitar la recuperación de la sesión después de un fallo del navegador?

c) ¿Es la opción más segura no usar sessionStorage para almacenar una clave? ¿O tal vez mitigue el riesgo utilizando también el cifrado completo del disco?

Gracias por tu ayuda.

    
pregunta sesses 23.05.2015 - 09:34
fuente

2 respuestas

6

En resumen; Un reinicio del navegador. Sin embargo, no todos los navegadores implementan la especificación definida por el W3C de la misma manera.

  

a) ¿Alguien tiene algún conocimiento sobre cómo funciona el código abierto de Nivel 1?   los navegadores (Firefox, Chromium) manejan el sessionStorage y si el   Los contenidos se pueden escribir en el disco, incluso temporalmente en el caso de un   bloqueo del navegador?

No hace mención de guardar datos que en ese momento residen en sessionStorage. Necesitará investigar la implementación de cada navegador para saberlo con certeza.

Consulte documentación de Mozilla , también hay una solicitud de error / función para migrar esta funcionalidad a una base de datos sqlite.

  

b) ¿Hay mitigaciones para evitar cualquier pérdida de la clave al disco en   ¿Un navegador falla o reinicia? ¿Hay alguna acerca de: ajustes de configuración que   podría utilizarse para deshabilitar la recuperación de la sesión después de un bloqueo del navegador?

Si bien la extensión de la API de cada navegador va a variar, cada debería implementar algún manejo de errores, así como los activadores de eventos en caso de una falla.

Por ejemplo, la documentación de Google Chrome utiliza un bloqueo evento desencadenante que no se ajusta a la estándar de eventos del progreso del W3C RFC.

  

c) Es la opción más segura de no usar sessionStorage para almacenar un   ¿llave? O tal vez mitigue el riesgo utilizando el cifrado de disco completo como   bien?

No debería necesitar almacenar la clave derivada, una vez que los registros se descifran y se escriben en el DOM durante una sesión, la clave solo debe persistir hasta que la sesión finalice cuando se realice el cifrado. El uso de sessionStorage es bueno para mantener los datos dentro del DOM solo cuando la pestaña / navegador está abierto, de ahí el nombre 'sesión'.

Dicho esto, si realmente necesita guardias seguros y siente que el cifrado completo del disco mitigaría el problema, considere los siguientes escenarios:

  1. El acceso a la partición de inicio de una máquina encriptada con disco completo permitiría la modificación de initramfs (instalación de Linux) permitiendo un método para capturar la entrada provista clave utilizada para el cifrado del disco.
  2. El transporte utilizado para llevar la aplicación web al navegador de los clientes si no está envuelto en un protocolo cifrado como TLS podría permitir la inyección de código malicioso capaz de capturar la entrada del teclado. Consulte el BeEF kit de herramientas de inyección.

Escribí esta herramienta; secStore.js . Hace lo que estás hablando de lograr. Solo asegúrese de envolver la capa de transporte con un túnel encriptado, use encabezados de seguridad para mitigar los intentos de XSS y hasta puede consulte los complementos / extensiones de navegador cargados para evitar el uso de vulnerabilidades maliciosas esa avenida.

Espero que ayude. Cualquier cosa con seguridad debe estar en capas y es casi imposible cubrir cada vector de ataque que es donde el monitoreo es útil.

    
respondido por el jas- 23.05.2015 - 15:11
fuente
4

Al parecer, sessionStorage no se borra realmente al cerrar la pestaña. Se revive fácilmente haciendo clic en "Volver a abrir la pestaña cerrada"

He escrito más sobre esto aquí: enlace

    
respondido por el guya 17.01.2016 - 18:46
fuente

Lea otras preguntas en las etiquetas