Generando URLs únicas que pueden ser revocadas

Parece que tienes una buena idea de lo que estás haciendo.

El patrón de enlace de una sola vez es bastante común para cosas como la verificación de correo electrónico. Por lo general, almacenaría la fecha de caducidad en una base de datos y / o utilizaría una cadena firmada en la URL que incluye la caducidad en la cadena a firmar. Estas son solo precauciones para evitar confiar en las opiniones de los usuarios.

Si desea ser realmente exhaustivo, puede enviarles el ID aleatorio real o la URL del token, y luego almacenar un hash en la base de datos para evitar que alguien use el token si tiene una violación de datos.

Usted es bastante vago sobre el contexto de los parámetros encriptados AES propuestos. Por lo general, incluiría información confidencial que no es necesaria para el enrutamiento de URL en el cuerpo de un mensaje, en lugar de la URL. De esa manera, no aparece en el servidor web o en los registros de proxy. Los datos cifrados con AES también pueden hacer que superes el límite de longitud de la URL con bastante rapidez, dependiendo del tamaño del contenido en texto sin formato.

Editar: Para completar, Azure Los Tokens de almacenamiento SAS son un gran ejemplo de un método criptográfico que no requiere registro de base de datos y es revocable. La revocación se realiza cambiando la clave de API del servicio ... que revocaría todas las señales emitidas por la misma clave.

Dado que no tengo mucha información sobre el sistema en uso, Recomendaría la búsqueda de base de datos más sencilla, sobre cualquier solución que requiera medidas criptográficas sofisticadas.

Además, para que los métodos criptográficos funcionen como un enlace de una sola vez, algunos parámetros conocidos por el servicio, e incluidos en la URL, deben cambiarse cuando se usa el enlace. Este parámetro no tiene que ser una búsqueda en la base de datos, pero sí debe haber un cambio persistente. Por ejemplo, si el enlace es una URL de carga única, la presencia de un archivo en el directorio de carga podría invalidar la URL.

Por último, el valor almacenado en la base de datos es más simple, ya que solo hay una fuente para verificar la validez. Con la solución sin base de datos, deberá verificar el secreto (es decir, la clave de cifrado), y también cualquier factor invalida el enlace después del primer uso.

Utilizar criptografía simétrica para un parámetro de URL le daría una ventaja: elimina la necesidad de hacer una búsqueda en la base de datos. El inconveniente es que introduce un secreto (la clave de cifrado) que necesita proteger y mantener. Ya que tendrá que hacer la búsqueda en la base de datos de todos modos para verificar el estado de la revocación, no obtendrá ninguna ventaja. Así que me gustaría ir para el enfoque # 1.

Asegúrese de usar ID: s suficientemente largas y genérelas con un CSPRNG. Y como dice nbering , asegúrate de hacerles una copia (sin sal) para protegerte en caso de una violación.

Los gigantes de software como Google utilizan un método de URL firmadas

La premisa es simple, usted envía una solicitud con una cadena cifrada que coincide con el lado no cifrado de la consulta. Entonces todo lo que necesita hacer es descifrarlo en el servidor.

Por ejemplo

example.com?file=file.ext&time={unixtimecode}&{encryptedstringthatmatchesfileandtimestamp}

El uso de la clave de cifrado es para garantizar que el servidor / alguien con acceso a la clave realizó la solicitud que un usuario puede seguir durante un cierto período de tiempo y que la solicitud no se ha manipulado. Revocar la cadena puede ser tan simple como eliminar una clave de cifrado temporal, lo que significa que el servidor no podrá descifrar la solicitud, incluso si se almacenó en caché.