¿Cómo almacenar datos privados de forma segura y de acceso público?

Es posible que la tarea no se pueda resolver en una formulación tan amplia como en el título, pero este es mi escenario (que es algo similar, por ejemplo, a las suscripciones a boletines informativos y, por lo tanto, ciertamente ya se ha pensado)

Quiero implementar una base de datos en un servidor web donde se almacenan datos privados sobre los usuarios. Se supone que los usuarios no deben tener un nombre de inicio de sesión elegante, sino que deben ser "validados por correo electrónico", es decir, el acceso a un buzón debe ser suficiente para la autenticación.

Los usuarios deben poder crear, actualizar y eliminar solo sus propios datos. La administración central debe poder exportar los datos del servidor web a un host seguro.

El escenario de ataque es que el servidor web junto con todos los datos (incluidos los scripts de la página web y la base de datos) se ven comprometidos. El requisito es que los datos privados almacenados allí antes el compromiso permanezca protegido (suponiendo que no se intente acceder a más usuarios).

Aquí están mis ideas hasta ahora: para autenticar solo tengo los usuarios email .

• Un nuevo ingresa su email en un formulario, lo que hace que hash(email) + publicencrypt(email) + random nonce + timestamp se almacene representando al usuario y al usuario se le envía un correo con una URL con parámetros random nonce y email . (Como solo hay email (protegido) y no username (desprotegido) password (protegido), no se pueden usar cosas como la sal y tengo que recurrir a hash(email) , ¿no?).
• Lo mismo sucede con un usuario existente, donde solo el hash(email) será el mismo que en cualquier intento anterior. publicencrypt(email) , random nonce y timestamp serán diferentes.
• Cualquier persona que acceda a una URL con los parámetros email y nonce como se generaron anteriormente puede realizar operaciones en el registro de la base de datos correspondiente después de verificar: ¿Existe un registro con hash(email) y nonce coincidentes y no demasiado antiguo? código%? En caso afirmativo, el usuario puede proceder. Tenga en cuenta que durante la sesión web de este usuario, el texto claro timestamp está disponible.
• La exportación al host de administración central seguro ocurre exportando los datos cifrados tal como están. El descifrado ocurre con la clave privada que coincide con la clave pública utilizada para cifrar (esta última se considera pública porque reside en el servidor comprometible).

La adición de una nueva entrada se completa en este punto, agregando una bandera email al registro. Por supuesto, borrar el registro es fácil. Mostrar datos no confidenciales (por ejemplo, cuándo se creó o modificó por última vez la entrada) también es una tarea trivial.

Mi problema es: ¿Cómo manejar los datos privados adicionales de forma segura? Es posible que solo lo guarde en forma cifrada (como el correo electrónico), pero en ese caso, el contenido ni siquiera se puede mostrar al usuario autenticado. Puede cambiarlo, pero no puede descifrarlo en una sesión web posterior. Esto es, por supuesto, sub-obtimal. Mi única idea es cifrar los datos adicionales con una clave diferente: en lugar de la clave pública de un par de claves asimétricas, use una clave simétrica que es reproducible producida desde isValid , es decir, almacene datos adicionales como %código%. Como el texto claro email está disponible para el propio usuario durante su sesión web, así como en la exportación descifrada en el host seguro, se puede reconstruir symmetricencrypt(data,key_generated_from(email)) .

Veo los siguientes problemas:

• Dado el formato restringido de las direcciones de correo electrónico (por ejemplo, algunos dominios pueden ocurrir muy a menudo), ¿podría una clave generada a partir del correo electrónico como se describe anteriormente ser lo suficientemente segura?
• En realidad, dado el formato restringido de las direcciones de correo electrónico, ¿es el email que usé en el concepto básico que asegura que solo el correo electrónico es lo suficientemente bueno? (¿Hay suficiente entropía en las direcciones de correo electrónico, por así decirlo?)
• ¿Hay un mejor enfoque?