¿Son las URL privadas e indiscutibles equivalentes a la autenticación basada en contraseña?

Una URL privada es algo más débil que la autenticación con credenciales, incluso si el tamaño de bit de la URL es el mismo que el de las credenciales. La razón es que la URL puede "filtrarse" más fácilmente. Se almacena en caché en el navegador, se registra en el servidor, etc. Si tiene enlaces salientes, la URL privada puede aparecer en el encabezado de referencia en otros sitios. (Las personas que miran por encima del hombro también lo pueden ver.)

Si se filtra (por accidente o por descuido del usuario), puede terminar siendo público e incluso indexado por Google, ¡lo que permitiría a un atacante buscar fácilmente todas las URL filtradas a su sitio!

Por esta razón, las URL privadas se suelen usar solo para operaciones de un solo disparo, como el restablecimiento de contraseñas, y normalmente solo están activas durante un tiempo limitado.

Hay un hilo relacionado en Seguridad de la información: ¿Son las URL aleatorias una forma segura de proteger las fotos de perfil ? - una respuesta comparte esta historia: Dropbox desactiva los enlaces compartidos antiguos después de que las declaraciones de impuestos terminen en Google . Así que no es solo un riesgo teórico.

Nota:

Mucha gente parece estar confundiendo una URL "privada" con la autenticación. Además, parece haber cierta confusión de que enviar el enlace a través de una entidad de confianza es un intento de autenticación de dos factores. Para ser claros, estamos hablando de un recurso de acceso público, aunque sea lo suficientemente difícil de adivinar.

Al usar una URL privada, siempre debe asumir que puede estar comprometida, debe diseñar dicha URL para que, incluso si está comprometida, el recurso no filtre información al atacante.

Las URL privadas / difíciles de adivinar no son equivalentes a la autenticación basada en contraseña. Por naturaleza, las URL privadas no son privadas en absoluto, son recursos de acceso público. Creo que el término "URL privada" es un nombre inapropiado, en lugar de que sean URL "oscuras".

Hay ciertos casos en los que usar una URL "privada" es aceptable, pero son intrínsecamente menos seguros que los métodos de autenticación tradicionales, como la autenticación de contraseña o la autenticación basada en clave.

Algunos de los lugares que he visto comúnmente como URL "privados" son:

1. Contraseña para restablecer correos electrónicos
2. Correos electrónicos de generación de certificados
3. Correos electrónicos de confirmación de cuenta / correo electrónico
4. Entrega del contenido comprado (libros electrónicos, etc.)
5. Otras cosas misceláneas como el registro de vuelo, imprimir la tarjeta de embarque, usar URL privadas además de la autenticación tradicional

Lo común aquí es que las URL aleatorias normalmente solo son buenas para operaciones de un solo disparo. Además, la autenticación tradicional y las URL aleatorias no se excluyen mutuamente , de hecho, se pueden usar conjuntamente para proporcionar seguridad adicional al entregar un recurso.

Como ha señalado Robert Harvey, la única forma de utilizar de forma segura una URL aleatoria / privada es generar la página de forma dinámica y enviar la URL al usuario de forma tal que el usuario pueda considerarse semi-autenticado. Esto podría ser correo electrónico, SMS, etc.

Una URL privada / generada aleatoriamente tiene algunas propiedades:

1. Debería caducar después de un período de tiempo razonable
2. Debería ser una URL de un solo uso: IE debería caducar después de la primera vez que se acceda.
3. Debería diferir la autenticación del usuario a alguna otra entidad en la que confíe para autenticar al usuario de forma segura. (Enviando el enlace por correo electrónico o SMS, etc.)
4. Para una computadora moderna debería ser imposible forzar la fuerza bruta de la URL en el período de tiempo anterior al vencimiento, ya sea limitando la velocidad de la API que expone el recurso o creando un punto final de URL con suficiente entropía para que no se pueda adivinar. / li>
5. No debe filtrar información sobre el usuario. IE: Si la página es para restablecer una contraseña: la página no debe mostrar la información de la cuenta del solicitante. Si Alice solicita un enlace para restablecer la contraseña y Bob de alguna manera adivina la URL, Bob no debería tener forma de saber de quién se está restableciendo la contraseña.
6. Si filtra información sobre el usuario, debe usarse sobre la autenticación tradicional, por ejemplo, una página puede considerar a un usuario autenticado si tiene un conjunto de cookies o si su session_id sigue siendo válido.

Los diferentes recursos requieren diferentes niveles de seguridad. Si quieres compartir una receta secreta con algunos amigos, por ejemplo, sería aceptable usar una URL aleatoria / privada para compartirla con ellos. Sin embargo, si el recurso pudiera usarse para robar la identidad de alguien o comprometer sus cuentas con otros proveedores de servicios, es probable que le importe mucho más restringir el acceso a ese recurso.

Casi todos los esquemas de autenticación se reducen a demostrar que conoces un secreto. Usted se autentica ante algún servicio al demostrar que conoce una contraseña secreta o una URL secreta o ...

Algunos protocolos más avanzados (por ejemplo, OAUTH, Kerberos, ...) le permiten demostrar que conoce el secreto sin que transmita el secreto. Esto es importante porque hay más formas de obtener un secreto "indiscutible" además de adivinarlo.

Podría estar sentado en el mismo cibercafé que tú mismo, escuchando a escondidas tu conexión WiFi cuando escribes tu URL "indiscutible". En ese momento, si no estuviera usando SSL, o si pudiera explotar el último error nuevo en su implementación de SSL, también sabría su secreto.

Muchas respuestas correctas ya están en este hilo, pero para abordar directamente la pregunta:

  

Desde la perspectiva de un malhechor que quiere acceder a este recurso, ¿son estos enfoques equivalentes? Si no, ¿qué los hace diferentes?

Déjame establecer una definición. "Autenticación" es la provisión de credenciales para probar un reclamo de identidad. El control de acceso generalmente se basa en la identificación del usuario.

Tu URL secreta no está vinculada a un usuario específico. Como han señalado otros, podría terminar en un archivo de registro de proxy, o una solicitud de búsqueda que se indexa por Google, o muchas otras formas en que podría filtrarse.

Por otro lado, una contraseña está vinculada a una cuenta de usuario única. Tiene la capacidad de restablecerlo, o solo permitir que se use desde la ubicación de inicio del usuario, o la dirección IP conocida, o cualquier número de otros controles.

Un nombre de usuario / contraseña le da un control mucho más granular del acceso.

El control de acceso permite que una identidad (sujeto) acceda a un recurso (objeto). En su ejemplo de URL, la identidad es "cualquier persona que obtenga la URL, por cualquier medio".

Vaya con el nombre de usuario / contraseña si puede. Las URL se filtran de muchas maneras inesperadas con el tiempo.

Una URL secreta es tan segura como una contraseña secreta. Sin embargo, las contraseñas son más fáciles de mantener secretas que las URL, ya que todos y sus programas saben que las contraseñas deben permanecer secretas.

Por ejemplo, su navegador no mostrará una contraseña en la pantalla, solo almacenará las contraseñas con su permiso y ofrecerá medios para proteger el almacenamiento de esa contraseña (como el almacenamiento cifrado desbloqueado por una contraseña maestra). Por el contrario, siempre mostrará las URL en la pantalla, posiblemente puede filtrarlas a través del encabezado del remitente y almacenarlas automáticamente en su historial de navegación sin ninguna otra protección.

Del mismo modo, los servidores proxy HTTP no registrarán las contraseñas, mientras que las URL se registran con frecuencia.

Usar las URL para la autenticación también significa que compartir las URL comparte la autenticación, lo que dificulta la revocación (o el registro) individual del acceso.

Y, por supuesto, las URL secretas heredan todas las debilidades de las contraseñas secretas. En particular, el uso de una contraseña para la autenticación revelará esa contraseña al servidor y a cualquier persona que pueda leer su comunicación.

Otro elemento que no se nota en ninguna parte es la limitación de "conjeturas". Para la mayoría de los sistemas de autenticación de contraseña, obtiene un número limitado de intentos de adivinar una contraseña para un usuario antes de que los intentos de autenticación adicionales estén bloqueados o limitados.

Si bien podría hacer algo similar con 'adivinar' contra su esquema de URL, sería algo más difícil de implementar. Si hay un patrón reconocible en su generación de URL, puede ser difícil impedir que alguien se configure para trabajar en su espacio de URL 'aleatorio'.

Hay otro aspecto que aún no he visto mencionado: los acortadores de URL.

En una publicación reciente (abril de 2016), se afirmó que los servicios de acortador de URL anulan completamente el aumento de la seguridad proporcionada por las URL "no ingeribles" generadas al azar. El espacio de la URL del servicio shorterner es considerablemente más pequeño que su URL generada de forma aleatoria, lo que significa que cualquier URL "segura" compartida con un servicio de acortador se puede adivinar de una manera más fácil de lo que se anticipa.

Para ilustrar, supongamos que su URL aleatoria tiene una longitud de 128 bits (es decir, una guía). Además, supongamos que su generador de números aleatorios es realmente fuerte y que usted genera esos bits de manera uniforme. Adivinar un número de 128 bits es muy difícil y puede llevar un tiempo considerable: su URL está protegida por una clave de 128 bits.

Entonces, asumamos que alguien compartió esta URL en el acortador de URL de Google. Hoy ese servicio emite una identificación de 10 caracteres, compuesta de letras y números. (26 + 10) ^ 10 ~ = 3.6 * 10 ^ 15 < 2 ^ 52 - por lo tanto, hemos reducido a la mitad la fuerza de la clave de 128 bits a 52 bits.

Agregue a ese hecho que los generadores no usan todo el espacio debido a otra consideración y puede montar un ataque efectivo que combine la fuerza bruta con los canales laterales (lo más probable es que haya búferes de URL aleatorios previamente asignados).

El artículo original: enlace
Una publicación de blog que resume el artículo (por el autor): enlace