Si desarrollo y administro un sitio web, ¿cómo puedo cifrar los datos del cliente para que no pueda leerlos, pero el cliente puede restaurarlos incluso si pierden su contraseña?

Puedo respetar su deseo de generar confianza diseñando un sistema en el que solo el cliente pueda descifrar y leer sus datos que están bajo su cuidado. Pero como usted dice, esto requiere que solo el usuario esté en posesión de la clave o contraseña. Desafortunadamente, los usuarios tienden a olvidar las contraseñas y perder claves, y se enojan cuando pierden sus datos (incluso si es su culpa). Entonces, ¿cómo protegerlos de sí mismos?

Creo que es instructivo ver cómo Dropbox hace las cosas, ya que son un servicio en la nube que existe específicamente para almacenar datos de clientes. Su sistema almacena los datos del cliente en bloques, que están protegidos por un cifrado fuerte (AES-256). Dropbox retiene las claves, pero ha diseñado múltiples capas de controles técnicos y de procedimiento a su alrededor para garantizar que solo el mínimo número mínimo de empleados internos pueda acceder a ellas (incluidas las auditorías de acceso y las aprobaciones de múltiples partes). También hay otras capas de controles destinados a proteger sus sistemas de ataques externos. Su sistema de controles está construido bajo las pautas ISO 27002 y desarrollado bajo un ISMS ISO 27001. El cumplimiento es auditado regularmente a un nivel detallado por organizaciones externas, y las pruebas de seguridad se realizan regularmente. Están haciendo las cosas de la mejor manera que yo podría hacer, y esto los ha hecho bastante confiables en el espacio de almacenamiento en la nube.

Un método que puede considerar es almacenar la clave de cifrado de datos del cliente localmente en una cookie segura (httpOnly). Sin embargo, esto solo estará disponible para http / https y no para JavaScript. Pero si el cliente borra la tienda de cookies de su navegador, están jodidos.

Si no está preparado para hacer el tipo de cosas que Dropbox está haciendo (que ciertamente son bastante costosas), entonces tendrá que tomar una decisión clásica de compensación de seguridad y privacidad frente a usabilidad. Si decide que la seguridad y la privacidad son primordiales, asegúrese de que sus clientes entiendan completamente que no podrá ayudarlos si pierden su clave.

Un último pensamiento más: también podría considerar un esquema de custodia de claves donde la clave del cliente se almacena en un tercero de confianza (como quizás Dropbox).

La respuesta simple es: debe dejar que el cliente tenga la opción de crear una Clave de cifrado y hacer que la posean y la administren.

Respuesta larga:

La clave de cifrado debe ser creada / propiedad del usuario y lejos del control del propietario de la aplicación. Es fácil hacer esto en aplicaciones móviles, donde puede generar las claves en el dispositivo, almacenarlas de forma segura y cifrar los datos antes de enviarlos al servidor.

Pero no todas las soluciones pueden confiar en el cifrado en el lado del cliente / dispositivo móvil.

Si es una aplicación web, tiene un par de opciones diferentes. y la mejor opción para aprovechar un servicio externo de administración de claves. (opción b)

a) puede implementar de tal manera que el cliente proporcione la clave de cifrado (larga) o la frase de contraseña, pero todavía hay muchas áreas en las que esto puede salir mal. y la implementación todavía tiene que depender de “Confianza” con usted / su aplicación.

b) La mejor opción (suponiendo que esté en la nube o pueda integrarse con AWS o Microsoft o Google o cualquier otro Servicio de administración de claves).

He examinado AWS en detalle que otros.

Aquí puede hacer que su cliente genere una clave de cifrado, que le dé acceso a la clave y que cifre y almacene los datos.

El cliente puede revocar su acceso, por lo tanto, su aplicación no puede leer los datos en texto sin formato.

AWS proporciona registros para que el cliente sepa quién accedió a la clave y cuándo.

Box ha adoptado este enfoque para que los clientes empresariales cifren los datos mientras se almacenan en Box y aún tienen las claves administradas por AWS (bajo clientes IAM).

Editar : Si su único requisito es que una persona no pueda modificar los datos, pero que pueda leerlos, entonces podría generar una clave privada en su sistema y conservar la clave pública. No podría escribir los datos, pero podría leer los datos. Si pierden la clave, aún puede recuperar los datos y cifrarlos con la nueva clave o simplemente no preocuparse por modificar los datos antiguos.

Esto es más mantener la identidad. Siempre que tenga los datos y la clave pública para leer los datos, puede descifrar los datos y cifrarlos con una nueva clave privada.

Supongo que sería una aplicación de casillero secreto que tiene la clave vinculada a su contraseña en la creación. Si cargan una nueva clave o generan una nueva clave, entonces la pondría en el casillero. Tendría que pedir su contraseña, lo que debe hacer de todos modos.

Bueno, eso no funciona exactamente. El problema es que lo más probable es que requiera que la clave esté en su sistema. Entonces, una vez que se autentican con su contraseña, se extrae de la aplicación de bloqueo de seguridad y se coloca en el almacenamiento del navegador local.

He leído sobre algoritmos de cifrado que permiten claves secundarias.

El problema con esta idea es que para que esto funcione, la única persona que tendría la clave, ya sea pública o privada, es la persona que escribe los datos y la persona que los recibe.

Proporcionar un mecanismo para recuperar los datos, si usted también tiene acceso a esos datos en cualquier momento de la transferencia, es violar su especificación.

No estoy seguro de cómo las empresas existentes hacen esto. Supongo que usan la idea del casillero de seguridad que está vinculada a su contraseña o alguna otra información que usted sabría para recuperar los datos en caso de que haya olvidado su contraseña. Técnicamente aún pueden llegar a él, pero requiere que proporciones la información.

Definitivamente es un problema difícil y es poco probable que encuentre un experto lo suficientemente bueno en este sitio para proporcionar suficientes detalles para implementarlo por su cuenta. Los programadores en este dominio probablemente estén ganando mucho dinero con un NDA para no contarles a otros secretos comerciales o al menos lo suficiente como para que puedas implementar los detalles más finos de su sistema.