Quiero cifrar ciertas entradas en una base de datos. ¿Es este un buen plan?

Dado que dices que esta no es una aplicación real, solo comentaré un par de puntos aquí. El primero es un detalle de implementación que tal vez ya haya considerado, el segundo es más teórico "¿vale la pena?" pregunta.

1. Cambios de contraseña.

En general, se considera una buena práctica exigir a los usuarios que cambien su contraseña cada cierto tiempo. Si esta contraseña se ha usado directamente para derivar la clave utilizada para proteger sus datos, entonces tendrá un gran daño por delante: tendrá que descifrar sus datos almacenados con la clave antigua y luego cifrarlos con la nueva llave Puaj Ciclos de máquinas desperdiciados y una olla de miel potencial para un atacante, ya que tienes que volver al texto sin formato para hacer esto.

Un mejor esquema sería asignar al usuario una clave aleatoria (su Clave de cifrado de datos o DEK) cuando se registre, y cifrar esa clave con una clave derivada de su contraseña (su Clave de cifrado , o KEK). El DEK se utiliza para cifrar los datos reales, el KEK se utiliza para proteger el DEK y nunca se almacena. Luego, cuando cambian su contraseña, simplemente están cambiando el KEK: el DEK no cambia, por lo que no es necesario actualizar los datos almacenados, a excepción del valor cifrado del DEK, que ahora está cifrado con el nuevo KEK .

2. ¿Es esta una buena idea?

Sí. Absolutamente. El cifrado de los datos reales en una base de datos protege los datos contra algunos vectores de amenazas que los enfoques menos granulares no cubren. Por ejemplo, ni un sistema de archivos cifrado para almacenar las tablas de la base de datos ni el cifrado de la tabla de la base de datos protege contra un administrador de base de datos malintencionado con la capacidad de emitir una consulta select * from customers; . Si los datos están protegidos y las claves son seguras (una consideración importante), todo lo que un atacante puede obtener son los datos cifrados.

Dicho esto, hay algunas cuestiones a considerar. Por ejemplo, si encripta los SSN de los clientes en su base de datos, ¿afectará eso a los empleados de su centro de llamadas que habitualmente solicitan a los clientes su SSN para autenticarlos? Además, ¿qué ocurre cuando se deben exportar los datos de su sistema para poder enviarlos a un socio comercial que no tiene acceso a sus claves?

Ninguno de estos problemas es una razón para no implementar la seguridad en sus aplicaciones, pero debe tener en cuenta que esto no es una tarea trivial.

En primer lugar, en HTTP no hay forma de hacerlo de forma segura.
 Y cuando se incluye una conexión TLS (a.k.a. HTTPS), ¿por qué descifrar en el navegador? Eso suena como posiblemente el peor lugar para hacerlo.

Si la confidencialidad es realmente lo que se necesita, use tecnologías de encriptación adecuadas como PGP / GPG y haga que el usuario las descifre / encripte en su máquina. Todo lo que haces es almacenarlo.
O si se requiere conveniencia para cifrar / descifrar en el servidor, siempre tiene que confiar en el servidor de todos modos, así que no hay diferencia real allí.

Le sugiero que primero vuelva a leer la página que descartó como fuente e intente comprender con mayor claridad por qué la gente dice que el cifrado no se usa de esta manera.