Quiero exponer un recurso en la web. Quiero proteger este recurso: asegurarme de que solo sea accesible para ciertas personas.
Podría configurar algún tipo de autenticación basada en contraseña . Por ejemplo, solo podría permitir el acceso al recurso a través de un servidor web que verifica las solicitudes entrantes para obtener las credenciales correctas (tal vez contra alguna base de datos de respaldo de los usuarios) antes de entregar el archivo.
Alternativamente, podría usar una URL privada . Es decir, podría simplemente alojar el recurso en una ruta imposible de adivinar, por ejemplo https://example.com/23idcojj20ijf..., que restringe el acceso a aquellos que conocen la cadena exacta.
Desde la perspectiva de un malhechor que quiere acceder a este recurso, ¿son equivalentes estos enfoques? Si no, ¿qué los hace diferentes? Y en cuanto a la capacidad de mantenimiento, ¿hay ventajas y desventajas de cualquiera de los enfoques que debería tener en cuenta antes de implementar uno u otro?
fuente
Respuestas:
Una URL privada es algo más débil que la autenticación con credenciales, incluso si el tamaño de bits 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. (También puede ser visto por personas que miran por encima del hombro).
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 generalmente se usan solo para operaciones de una sola vez, como restablecimientos de contraseña, y normalmente solo están activas por 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 terminan en Google . Por lo tanto, no es solo un riesgo teórico.
fuente
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 confiable 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 suponer que puede verse comprometida; debe diseñar dicha URL de modo 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, más bien son URL "oscuras".
Hay ciertos casos en los que es aceptable usar una URL "privada", pero son intrínsecamente menos seguros que los métodos de autenticación tradicionales, como la autenticación con contraseña o la autenticación basada en claves.
Algunos de los lugares que he visto comúnmente utilizar URL "privadas" son:
Lo común aquí es que las URL aleatorias generalmente solo son buenas para operaciones de una sola vez. Además, la autenticación tradicional y las URL aleatorias no son mutuamente excluyentes ; de hecho, se pueden usar conjuntamente para proporcionar seguridad adicional al entregar un recurso.
Como Robert Harvey ha señalado, la única manera de usar de forma segura una URL aleatoria / privada es generar la página dinámicamente y enviar la URL al usuario de tal manera que el usuario pueda considerarse semi-autenticado. Esto podría ser correo electrónico, SMS, etc.
Una URL privada / generada aleatoriamente tiene algunas propiedades:
Diferentes recursos requieren diferentes niveles de seguridad. Si desea 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.
fuente
Casi todos los esquemas de autenticación se reducen a probar que sabes un secreto. Usted se autentica en algún servicio demostrando que conoce una contraseña secreta o una URL secreta o ...
Algunos protocolos más avanzados (por ejemplo, OAUTH, Kerberos, ...) le permiten probar que conoce el secreto sin transmitirlo realmente . Esto es importante porque hay más formas de obtener un secreto "incuestionable" además de adivinarlo.
Podría estar sentado en el mismo cibercafé que tú, espiando tu conexión WiFi cuando escribes tu URL "incuestionable". En ese momento, si no estaba utilizando SSL, o si puedo explotar el último error nuevo en su implementación de SSL, entonces también sabría su secreto.
fuente
<form>, JavaScript, datos cifrados de grado militar (tal vez sea necesario un rastreo activo). Es fácil solucionarlo: use HTTPS.Muchas buenas respuestas ya en este hilo, pero para abordar directamente la pregunta:
Déjame establecer una definición. "Autenticación" es la provisión de credenciales para probar una declaración de identidad. El control de acceso generalmente se basa en la identificación del usuario.
Su URL secreta no está vinculada a un usuario específico. Como otros han señalado, podría terminar en el archivo de registro de un proxy, o en una solicitud de búsqueda que Google indexa, o en 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 brinda un control mucho más granular del acceso.
El control de acceso permite el acceso de una identidad (sujeto) a un recurso (objeto). En su ejemplo de URL, la identidad es "cualquiera que obtenga la URL, por cualquier medio".
Vaya con el nombre de usuario / contraseña si puede. Las URL se filtran de muchas formas inesperadas con el tiempo.
fuente
Una URL secreta es tan segura como una contraseña secreta. Sin embargo, las contraseñas son más fáciles de mantener en secreto que las URL, porque 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á contraseñas con su permiso y ofrecerá medios para proteger ese almacenamiento de contraseña (como el almacenamiento cifrado desbloqueado por una contraseña maestra). Por el contrario, siempre mostrará las URL en la pantalla, posiblemente las filtre a través del encabezado de referencia y las almacene automáticamente en su historial de navegación sin ninguna protección adicional.
Del mismo modo, los servidores proxy HTTP generalmente no registrarán las contraseñas, mientras que las URL se registran comúnmente.
El uso de URL para autenticación también significa que compartir URL comparte autenticación, lo que dificulta la revocación (o 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 cualquiera que pueda leer su comunicación.
fuente
Otro elemento que no se menciona en ninguna parte es la aceleración de las "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 se bloqueen o limiten más intentos de autenticación.
Si bien podría hacer algo similar con 'conjeturas' en contra de su esquema de URL, sería algo más difícil de implementar. Si hay un patrón reconocible para su generación de URL, entonces puede ser difícil detener a alguien que se configura para abrirse camino a través de su espacio de URL 'aleatorio'.
fuente
Hay otro aspecto que no vi mencionado todavía: acortadores de URL.
En una publicación reciente (abril de 2016), se afirmó que los servicios de acortador de URL anulan por completo la mayor seguridad proporcionada por las URL "no cuestionables" generadas al azar. El espacio de URL del servicio más corto es considerablemente más pequeño que su URL generada aleatoriamente, lo que significa que cualquier URL "segura" compartida con un servicio más corto se puede adivinar de una manera más fácil de lo previsto.
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 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á efectivamente protegida por clave de 128 bits.
Luego, supongamos 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 que efectivamente hemos reducido a la mitad la intensidad 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 combina la fuerza bruta con canales laterales (muy probablemente búferes de URL aleatorios previamente asignados).
El artículo original: http://arxiv.org/pdf/1604.02734v1.pdf
Una publicación de blog que resume el artículo (por el autor): https://freedom-to-tinker.com/blog/vitaly/gone-in- seis caracteres-urls cortas-consideradas-dañinas-para-servicios en la nube /
fuente
Gah! My password/private key is too long and complex. I know! I'll just write it in a text document and put that in a zip file with an easier password.ambos son fallas transparentes, lo que uno espera contra la esperanza de que las personas no sean lo suficientemente tontas como para hacer. Pero sí, en realidad, lamentablemente probablemente se necesite su advertencia;)