El MAC es la herramienta correcta aquí, y HMAC / SHA-256 está bien. Usar una tolerancia de 5 segundos puede ser un poco optimista:
-
Debe asegurarse de que ambos servidores tengan relojes precisos; utilice NTP . Además, asegúrese de usar una representación bien definida, es decir, algo en UTC (de lo contrario, tendrá problemas con el horario de verano).
-
El "retraso de 5 segundos" debe ser suficiente para adaptarse al viaje de ida y vuelta: el servidor A envía la respuesta de "redireccionamiento" al cliente, luego el cliente se conecta a B y envía la solicitud. Si el cliente se encuentra en condiciones adversas (por ejemplo, un cliente que usa una computadora portátil en un tren), la red puede no estar disponible durante unos segundos a la vez.
Los ataques de reproducción de personas externas se evitan mediante SSL; La inclusión de la marca de tiempo es para derrotar los ataques de repetición por el propio usuario. Si el servidor B requiere una marca de tiempo que no tenga más de n segundos, esto implica que si bloquea el acceso al usuario en A , el usuario todavía puede hablar con B durante n segundos. Probablemente puedas tolerar un n más largo; Personalmente, usaría un retraso de 5 minutos. Otra forma de verlo es la siguiente: si, una vez que se realizó la autenticación, B permite solicitudes sucesivas dentro de un marco de tiempo dado T , por ejemplo. con una administración de sesión basada en cookies y la sesión expira después de T segundos, entonces tiene relativamente poco sentido usar un n mucho más corto que T .
Tenga en cuenta que un usuario malvado puede querer falsificar paquetes NTP para hacer que el reloj del servidor B regrese al pasado, a fin de reutilizar una URL de autenticación antigua con un MAC de larga caducidad . Los paquetes NTP no son autenticados. Un cliente NTP normal no aceptará alterar su reloj en cantidades considerables, incluso si un servidor NTP afirma que está apagado por varias semanas; sin embargo, teóricamente se puede abusar de una llamada ntpdate en el tiempo de arranque. No he observado este ataque en la práctica.
Sugerencias de mejoras:
-
Es posible que desee incluir identificadores para A y B (por ejemplo, nombres de servidor) en la URL de redireccionamiento, y como parte de la entrada MAC. Esto hace un seguimiento de quién está haciendo la autenticación + autorización, y para qué servidor está autorizado el usuario. Esto es más flexible si desea expandir más tarde el sistema con varios servidores A y B distintos.
-
Puede reemplazar el MAC por una firma digital (RSA, DSA ...): el servidor A posee la clave privada y la usa para firmar; el servidor B utiliza la clave pública de A para verificar las firmas. Esto evita compartir un secreto entre A y B (cuanto más se comparte un secreto, menos secreto se vuelve).