Nada es inútil, y no hay balas de plata. Todo depende.
Había una barra lateral sobre el uso de cifrado de disco. Eso es proteger contra una superficie de ataque diferente, así que ignorémosla.
La pregunta pregunta si tiene sentido cifrar los datos que se encuentran en una base de datos, bajo el supuesto de que necesita ser texto simple para un cliente web. Las opciones presentadas son usar un token maestro (fuera de la base de datos) para descifrar el criptotexto almacenado, o usar un token proporcionado por el usuario, con la observación de que esto es una mala idea y no funcionaría para la colaboración.
Si lo que le preocupa es que alguien pueda violar la confidencialidad del servidor web, digamos que para levantar ese token maestro almacenado y la base de datos, entonces de hecho no tiene suerte. La mitigación aquí es que a menudo la violación de la base de datos y la violación de las configuraciones web son diferentes, y una sin la otra no es útil. Por lo tanto, es protector en, por ejemplo, el ejemplo clásico de un ataque de inyección de sql que descarga la base de datos.
En ese momento, usar un token proporcionado por el usuario es muy útil, y no lo llamaría una mala idea. Tenga en cuenta que, en teoría, esto todavía puede ser útil en aplicaciones colaborativas: el criptotexto almacenado puede cifrarse utilizando un cifrado de flujo cuya clave está cifrada (por ejemplo, a través de una PKI) contra las claves de varias personas. Ahora, la confidencialidad del servidor no es un problema (suponiendo que no tengan acceso al tiempo de ejecución): ninguna recopilación de información en el servidor puede convertir el criptotexto a texto simple sin los tokens del usuario.
Pero, si se cuestiona la integridad del servidor, entonces esta solución falla. El texto sin formato está en la memoria del servidor, por lo que su juego finaliza ... el programa puede reconfigurarse para conservar el texto sin formato en cualquier lugar deseado, o incluso para cambiar la mensajería entre los clientes. Ahí es donde entra en juego la tercera solución. Si tiene un código ejecutándose en la máquina cliente que realiza el descifrado de la información pasada y el cifrado de cualquier respuesta, está nuevamente en agua segura. (Aunque, por supuesto, ahora depende de la opsec de los clientes finales, pero ese es siempre el caso).
Evalúe los riesgos y costos de varios casos de pérdida de integridad en el servidor y haga su elección.
Barra lateral: si realmente te importa esto, DEJA DE USAR CONTRASEÑAS. Si no lo hace, en mi humilde opinión un token maestro está bien.