Objetivo: tener autenticación basada en token / cookie que no requiera mantener sesiones en el servidor
TL; DR: ¿Cuál es, si existe, el mecanismo aceptado para solucionar la limitación de 72 caracteres de BCrypt?
Versión larga:
Después de leer esta respuesta intenté implementar la autenticación en un servidor basado en REST utilizando BCrypt como un algoritmo hash y un secreto del lado del servidor de rotación. La idea básica era que, tras la autenticación exitosa con un nombre de usuario y contraseña, el servidor configuraría una cookie que contenía un hash basándose en la concatenación de lo siguiente:
- El secreto del lado del servidor
- El ID de usuario y los grupos a los que pertenece el usuario
- La hora en que se entregó el token
Esto se incluiría con un salt y el resultado iría a la cookie, para que el servidor la lea y verifique (es posible porque la identificación del usuario, los grupos y la fecha son transmitidos en forma simple por el cliente, y el secreto del lado del servidor está en la memoria, y el secreto sirve como garantía de que el cliente no hizo todos los demás valores por sí mismos).
Todo esto funcionó bien hasta que me di cuenta de que BCrypt tiene un límite de 72 caracteres en el texto sin cifrar que está encriptado (cualquier cosa después de esos 72 caracteres no influye en el hash de salida).
Esto es un problema porque los datos anteriores suman más de 72 caracteres y permiten que el tiempo, la identificación del usuario, los grupos o la clave secreta sean 'los últimos' en la entrada y no influyan en los agujeros abiertos de salida en la seguridad del sistema. (o los tokens antiguos son infinitamente válidos, o las personas pueden modificar su ID de usuario / rol de manera arbitraria).
Irónicamente, cuando finalmente descubrí por qué mi sistema producía hashes idénticos basados en diferentes entradas y buscaba en Google, parece que este tipo de situación fue previsto por algunos .
De todos modos, la pregunta: ¿Cuál, si existe, es el mecanismo aceptado para evitar la limitación de 72 caracteres de BCrypt?
Algunos pensamientos preventivos: inventarme sus propias variaciones en algoritmos criptográficos estándar es algo que me advirtieron durante el tiempo que puedo recordar, por lo que no estoy 100% seguro de cuál sería el mejor curso de acción.
Las opciones obvias incluyen:
- dividiendo la entrada y aplicando BCrypt a cada uno de ellos y / o en cascada;
- usando otro hash (¿no criptográfico?) en la entrada para reducir su tamaño
- usar compresión simple (pero eso podría no ser efectivo con tan poco texto sin formato)
- cambiar a otro algoritmo (SHA-3 se finalizó recientemente, por ejemplo).
(puede haber otras cosas incorrectas con la idea anterior, en cuyo caso, por supuesto, me encantaría que me corrigieran)