Estaba planeando utilizar el usuario AES256 para garantizar que el cliente no pueda cambiar el valor de la cookie.
El cifrado proporciona confidencialidad, no proporciona autenticación.
Si no desea que los usuarios vean un valor de datos de sesión, debe cifrar y luego autenticar el valor. Esto evita que un ataque de cambio de bit cambie el valor dentro del token cifrado porque el hash con clave ya no coincidirá si se intercambian algunos bits.
Si no se requiere confidencialidad, simplemente puede autenticar. Por ejemplo, podría usar un HMAC sobre SHA-256 . Esto le mostrará al usuario final cuál es el valor en texto claro, sin embargo, no podrán cambiar el valor porque no podrán volver a calcular el valor hash ingresado sin la clave.
por ejemplo Tu cookie se configurará de la siguiente manera:
Set-Cookie: Session=Username=admin&expires=20150809104100&hash=7C2CD7DB7DF4055E782E3A5F70487FEB9A5CABEED3FB70F5D8772586FD8B2759
Expires evita que un usuario guarde su cookie fuera de línea para su uso posterior cuando no sean administradores porque el hash también se calcula al vencimiento:
Username=admin&expires=20150809104100
Puede usar este sitio para verificar esto (la clave utilizada fue stackexchange
, sin embargo, debe usar un pseudoaleaje seguro criptográficamente clave de 128 bits generada).
Sin embargo, existe una tecnología estándar de Internet para hacer esto ya llamada Fichas web JSON . El algoritmo HS256 generará el valor del token del lado del cliente calculado por HMAC sobre SHA-256.
Si también desea el cifrado, elija A128GCM
; tenga en cuenta que una clave de 128 bits es suficiente para sus datos: una clave de 256 bits que utiliza AES-256 es más lenta e innecesaria. puede incluso ser menos seguro ya que hay diferencias significativas en cómo AES procesa una clave de 128 y 256 bits.
Como JSON Web Encryption solo admite algoritmos de cifrado autenticados, esto también evitaría el intercambio de bits.