Hay algunas formas en que puedes lograr esto. Espero que su objetivo sea aceptar solicitudes solo de clientes conocidos?
Clave previamente compartida
Un PSK en su forma más simple es una clave que se intercambia entre dos partes fuera de banda con el remitente que usa la clave compartida tal como está en los mensajes como credencial. Por esta razón, HTTPS generalmente es una necesidad para los PSK. Sin ayuda
Desde la seguridad del transporte, es más fácil para un usuario malintencionado obtener el PSK y utilizarlo en una solicitud maliciosa, al igual que una solicitud legítima.
Marca de tiempo para evitar ataques de reproducción
Supongamos que diseñamos nuestro mecanismo de seguridad para transmitir las credenciales, no en texto sin formato, sino encriptadas mediante el PSK.
La credencial cifrada se envía en el mensaje, generalmente en el encabezado de solicitud HTTP. Un usuario malicioso no puede descifrar
el encabezado y extraiga las credenciales, pero puede reproducir la solicitud anterior tal como está. Peor aún, un usuario malicioso puede encuadrar un nuevo
solicite y use solo el valor del encabezado que contiene las credenciales válidas de la solicitud exitosa anterior.
Se puede agregar una marca de tiempo al mensaje y cifrarse junto con el resto del contenido del mensaje. El servicio puede
recupera la marca de tiempo después de descifrar el mensaje y falla la solicitud si la marca de tiempo es demasiado antigua para el umbral
eso ya está acordado. Esto reduce la ventana de oportunidad para reproducir una solicitud.
El inconveniente es que tanto el servidor como el cliente deben sincronizarse con el tiempo.
Una alternativa a una marca de tiempo es un contador como el contador de nonce que vimos con la autenticación de resumen. Con
un contador, no debemos preocuparnos por el sesgo entre los relojes. Sin embargo, los clientes deben implementar un
contador para garantizar que el recuento enviado en una solicitud sea mayor que el recuento en la solicitud anterior al menos en uno, y el
El servidor debe mantener un registro del último contador recibido. Por supuesto, el mensaje debe ser firmado para que un usuario malintencionado
no incrementa el contador y repite el resto de la solicitud.
Evitar el mal uso del identificador
En su forma más simple, un PSK es tanto el identificador de usuario como la credencial. Por esta razón, los PSK deben ser únicos. Dado un
Clave, una aplicación debe ser capaz de identificar al usuario correspondiente sin ninguna ambigüedad. La premisa básica que tenemos
están trabajando en evitar el HTTPS. Por esta razón, el PSK no se puede transmitir como está. Necesitamos tener dos claves: una que actúa como la identidad del usuario y la otra que actúa como la credencial.
Sin embargo, estas claves no están vinculadas matemáticamente. Además, la misma clave utilizada para firmar en el extremo del remitente se usa para
validar la firma en el extremo del receptor; Por lo tanto, esto es sólo una clave compartida simétrica. Pero similar a la clave pública
Criptografía, solo la clave privada debe estar protegida.
Prevenga los ataques MIM (para comunicaciones que no sean HTTPS)
Sin HTTPS, un ataque Man-in-the-middle (MITM) es una de las amenazas más importantes. El mecanismo primario
para garantizar la integridad de los datos de los mensajes es un Código de autenticación de mensajes basado en Hash (HMAC). HMAC es solo una pieza
de datos creados a través de un algoritmo de hash criptográfico y una clave secreta compartida. En esta sección, te muestro cómo
para crear un HMAC usando el algoritmo SHA256.
Sin embargo, si el mensaje debe cifrarse por confidencialidad, puede agregar fácilmente esa funcionalidad
utilizando la misma clave privada que usamos para HMAC o puede introducir una nueva clave específicamente para el cifrado.
La solicitud debe contener los siguientes parámetros
- La clave pública, que es la clave asociada con el usuario.
- El contador
- La marca de tiempo
Además de los parámetros, la solicitud incluye una firma que garantiza que ninguno de los parámetros sea
manipulado. Es posible crear la firma basándose no solo en los tres parámetros, sino también en todo el cuerpo.
de la solicitud si el objetivo es asegurarse de que no se modifique nada en la solicitud.
Para asegurarnos de que nadie manipule los parámetros, podemos incluir un HMAC-SHA256 de los tres valores más el
Solicitud de URI y método HTTP. El listado 9-1 muestra una solicitud HTTP protegida por el mecanismo PSK. La figura 9-2 muestra
El diseño de PSK.