Cifrado del lado del cliente con la sostenibilidad como un servicio

He will always provide his key to decrypt data.

Bueno, si se trata de datos confidenciales y usted los mantiene encriptados, sería bueno evitar la transmisión de una clave que tiene a través de la red. Si te refieres solo a encriptar la línea, entonces sí lo hará HTTPS, pero eso no garantiza que solo él pueda ver los datos, ya que, como ya sabes, ya tienes posesión de ellos.

Should i go for it or rely only on good https, password strength and server database encryption?

Https protege los datos en tránsito. El cifrado en el nivel de la base de datos protege los datos en reposo. Sin embargo, la única garantía de que usted o cualquier persona que administra el servidor no puede ver los datos es que nunca tendrá las claves de descifrado en ningún momento del proceso. Si el usuario te envía la clave, puedes ser malicioso y mantenerla para siempre.

Por lo tanto, para que el usuario esté seguro, él o ella debe aferrarse a la clave, y usted nunca debe verla.

Sus opciones y sus requisitos no parecen coincidir. Si confía en HTTPS, la seguridad de la contraseña y el cifrado de la base de datos del servidor, entonces el administrador puede, de hecho, acceder a los datos descifrados. SO , si el requisito 1 es realmente un requisito, esta opción no es viable. Sin embargo, si el requisito 1 es simplemente "bueno tener", esta opción podría funcionar.

Entonces, la pregunta es: ¿el requisito 1 es realmente un requisito? Si es así, entonces su única opción real es el cifrado del lado del cliente. Para cualquier garantía razonable de integridad, esto requiere una aplicación del lado del cliente o un complemento del navegador sin mecanismos de actualización automática. Los mecanismos basados en servidores son simplemente demasiado fáciles de subvertir como para ser contendientes serios.