¿En qué caso debería uno cifrar las cookies?

Si contienen información confidencial y no tiene otra solución que enviarla en una cookie (es muy probable que no la tenga). El modelo de clave pub / priv no funcionaría fácilmente dentro de un navegador y probablemente no logrará lo que estás tratando de hacer.

Realmente no debe incluir ninguna información confidencial en una cookie, y las que sí contienen datos de estado que no desea modificar deben firmarse con algo como HMAC usando un secreto conocido solo por el servidor.

Debe cifrar las cookies al hacerlas seguras (solo se envían a través de HTTPS). Realmente no hay razón para cifrar manualmente los datos con RSA / AES del lado del servidor o similar o RSA / AES del lado del navegador. Si lo intenta, probablemente dejará vulnerabilidades abiertas en su implementación, identificación y protocolo de intercambio de claves.

Sus cookies solo deben contener información que no le importa si el navegador en el otro extremo ve o manipula. Utiliza la seguridad de la capa de transporte (TLS) para garantizar que los interceptores de la red no puedan ver sus cookies ni manipularlas.

Si tiene secretos que deben asociarse con el usuario, debe almacenar esos secretos del lado del servidor y asociarlos con el usuario a través de uno de los dos:

1. token de sesión aleatoria que es lo suficientemente largo como para que no se pueda adivinar (por ejemplo, 128 bits),
2. token de sesión generado a través de un HMAC del lado del servidor al iniciar sesión con un secreto del lado del servidor que identifica al usuario . Esta sesión se verifica del lado del servidor cada vez que se necesita usar un secreto. Algo como HMAC(username+login_timestamp, key = server_side_secret) donde básicamente hash una combinación de la información de los usuarios con la clave secreta del lado del servidor. Luego, puede asociar secretos con el nombre de usuario y, antes de usarlos, verifique que el token de sesión sea válido al verificar que HMAC sea válido. Por lo tanto, un atacante que modifica su nombre de usuario (el de otra persona) o cambia la fecha de inicio de sesión (para evitar el cierre de sesión automático) no puede pretender ser un usuario con sesión iniciada.

Ah galletas. Pequeños bocados de deliciosa información de un servidor web. Esta tecnología ha existido durante mucho tiempo, se ha probado y es verdadera, y funciona muy bien si se implementa correctamente.

Ahora digo si se implementó correctamente, y hay una razón para eso. Las cookies contienen información. Mantener la información secreta en secreto es una prioridad principal. Si esa información ya no es secreta, puede suceder algo malo. Esto conduce a la forma más fácil de decidir si una cookie debe cifrarse:

  

¿Esta cookie contiene información confidencial?
  Sí: ENCRYPT
  No: lo que sea

Entonces, ¿cómo debería cifrar la cookie? Bueno, eso depende del tipo de cookie:

  

Solo sesión / lado del servidor: nunca permita que el usuario lo modifique (privado, solo en el servidor)
  Datos privados del usuario: cifrado simétrico y seguro para que el usuario pueda utilizar la información que contiene.

Después de eso, se trata de verificar para asegurarse de que está utilizando los algoritmos correctos para cifrar sus datos de manera segura, y tener suficientes controles y saldos para asegurarse de que no se manipulen (piense en JWT)