La criptografía de JavaScript no es una buena idea
La criptografía de JavaScript no es mala en sí misma, es simplemente ineficaz contra las amenazas consideradas con mayor frecuencia.
Si considera que un hombre en el medio (MITM) es una amenaza, SSL / TLS es un control mucho más efectivo, ya que de lo contrario, el atacante podría sustituir el JavaScript por una versión que no usa cifrado. / p>
Si considera que el software malicioso en el lado del cliente es una amenaza, es probable que pueda modificar el JavaScript de cualquier forma que le guste y su cifrado sería inútil.
Si considera que el lado del servidor es una amenaza (por ejemplo, el cliente quiere que el servidor almacene algo pero no vea el contenido), entonces puede ser efectivo, pero el cliente necesita alguna otra forma de garantizar que JavaScript no lo haya hecho. ha sido manipulado (lo que no es un problema fácil de resolver) y el cliente necesita administrar la clave ellos mismos.
En el caso de uso que has descrito, no parece que el cifrado del lado del cliente realmente agregue seguridad adicional. De cualquier manera, tiene que lidiar con el problema de comunicar la clave, que probablemente dependerá de la integridad de SSL / TLS independientemente . O bien el cliente tendrá que enviar la clave al servidor o al revés, e incluso si usa el cifrado de clave pública para solucionar este problema, tendrá el problema de asegurarse de que la clave pública enviada al cliente sea auténtica. Lo más probable es que termine de reimplementar una infraestructura típica de clave pública.
Dejando eso de lado, no hay un problema fundamental con la realización de la criptografía en JavaScript, excepto que:
- Por lo general, es bastante lento para la mayoría de los estándares
- La generación de claves seguras criptográficamente puede ser un problema, especialmente en los navegadores más antiguos que no admiten ciertas API más nuevas para esta tarea