Estoy buscando un algoritmo de cifrado con un uso intensivo de la CPU, para pasar los tokens de autenticación de sesión.
Como ejemplo:
- El usuario iniciará sesión en el sitio web (a través de OAuth, ya sea por el sitio como proveedor o un proveedor externo)
- Independientemente de cómo se autenticaron originalmente, un nuevo token de sesión producido aleatoriamente (en este caso, una cadena de 64 caracteres) está asociado a su cuenta y se almacena en una cookie.
- En cada solicitud de página nueva, el token de sesión se toma de la cookie, se cifra con un nonce basado en el tiempo (para evitar la reproducción) y se coloca en los encabezados como una etiqueta meta y se procesa.
- El usuario hace algo que dispara una solicitud AJAX de javascript a la API del sitio. El javascript recoge el token cifrado de la etiqueta meta.
- La API recibe los parámetros, saca la información cifrada y la descifra.
- Las cosas pasan ...
Obviamente, esto podría terminar en una gran cantidad de cifrado. Por supuesto, los datos solo serán pequeños, pero es el volumen lo que me preocupa. Para ello estoy buscando un algoritmo de cifrado que:
- Es bajo en el uso de la CPU
- Ampliamente disponible estaría bien.
- Fácil de usar sería bueno.
He echado un vistazo a mi alrededor, pero el detalle de algunas de las comparaciones que he visto está más allá de mi conocimiento y es completamente útil. Si alguien pudiera dar una sugerencia, sería útil. Además, si alguien ve un agujero deslumbrante con la seguridad en el ejemplo anterior, hágamelo saber.
Información adicional debido a los comentarios:
- SSL se usaría para todas las comunicaciones.
- La cookie (completa) se cifra mediante AES. Los pares de valores clave específicos no lo son.
- No deseo manipular el valor usando el navegador, quiero que el valor ya cifrado se envíe a través de AJAX y luego se descifre del lado del servidor en la API de datos.
- No deseo que los propios usuarios tengan acceso a un token de sesión sin cifrar.
- La mayoría del estado se mantiene en la base de datos, el token de la sesión está justo ahí para que la API sepa quién realiza las solicitudes. Casi nada más se mantiene del lado del cliente.
La razón principal para este tipo de configuración es permitir que muchos clientes diferentes accedan a la API a través de HTTPS, ya sea web o móvil o lo que sea, por lo que el servidor de la API de datos no puede residir en la misma casilla que el sitio web, y el sitio web no tiene acceso directo a la base de datos.