Usar autenticación usando 2 cadenas cifradas

Esto parece ser mucho más complicado de lo necesario. ¿Cuál es el punto de las dos claves diferentes? ¿Cuál es el punto de la cadena de verificación? ¿Por qué el cifrado en lugar de solo la verificación (la identificación del usuario probablemente no es un secreto)?

Creo que puedes simplificar tu sistema a esto:

1. Cuando un usuario inicie sesión, genere un MAC utilizando la ID del usuario, una marca de hora, su clave secreta y envíe ellos el ID de usuario, la marca de tiempo y MAC como una cookie.
2. En cada solicitud, vuelva a calcular el MAC (utilizando el ID y la marca de tiempo del usuario de la cookie y la clave secreta almacenada en el servidor web). Denegar cualquier solicitud en la que el MAC calculado no coincida o la marca de tiempo sea demasiado antigua.

Java tiene una clase de Mac incorporada, y hay ejemplos de personas que lo utilizan en Desbordamiento de pila.

Debes saber que esto debilita la seguridad:

• Si alguien obtiene su clave secreta, puede iniciar sesión como cualquier persona y usted no lo notará.
• Si alguien roba la cookie de su usuario, puede iniciar sesión como ese usuario hasta que la cookie sea demasiado antigua (las cookies normales tienen este problema).
• No tiene forma de revocar el acceso, incluso si sabe que las cookies de un usuario han sido robadas (las cookies normales no tienen este problema).

En cuanto a la velocidad:

• El hash es (en general) extremadamente rápido.
• El acceso a la base de datos es más lento, pero sigue siendo tan rápido que su solución probablemente no sea necesaria.

Parece que está intentando almacenar un mensaje autenticable con un cliente. Para eso, desea utilizar un [HMAC]. Algunas de las desventajas de esta solución se discutieron recientemente en la pregunta Enlaces de restablecimiento de contraseña: ¿valor aleatorio o mensaje autenticado? .

Personalmente me inclino por las bases de datos en gran parte porque necesitará almacenar algo para ser autenticado en algún momento y las verificaciones de la base de datos le permiten caducar tokens. Una vez que pasa un mensaje autenticado, no puede eliminarlo antes de que revise una lista de revocaciones ... acceso a la base de datos nuevamente.

El problema es la revocación. Una vez que ha entregado la cookie, es infinitamente reutilizable hasta que cambian la contraseña. Si su cliente está comprometido, la cookie podría tener fugas y sería válida hasta el próximo cambio de contraseña. Una posible mejora sería utilizar una clave en el servidor para cifrar una marca de tiempo e incluirla con la cookie. Esto podría usarse para limitar la validez de tiempo de una cookie, aunque la revocación debido al cierre de sesión aún no sería posible sin una base de datos.