¿Está bien usar URL aleatorias en lugar de contraseñas? [cerrado]

12

¿Se considera "seguro" usar una URL construida a partir de caracteres aleatorios como este?

http://example.com/EU3uc654/Photos

Me gustaría poner algunos archivos / galerías de imágenes en un servidor web al que solo pueda acceder un pequeño grupo de usuarios. Mi principal preocupación es que los motores de búsqueda o los usuarios curiosos que exploran mi sitio no deberían recoger los archivos.

He configurado un archivo .htaccess, solo para notar que hacer clic en los http://user:pass@url/enlaces no funciona bien con algunos navegadores / clientes de correo electrónico, provocando diálogos y mensajes de advertencia que confunden a mis usuarios no muy expertos en informática.

— estofado
fuente

No. Puede usar esto, pero no como el único o principal mecanismo de autenticación.

— Andrew Smith

1

He intentado esto como un experimento muchas veces, y cada vez que los enlaces terminan en los motores de búsqueda. No sé cómo, pero sé que sucede.

— David Schwartz

Es posible que desee configurar SSL para detener las advertencias, puede obtener certificados gratuitos de startssl.com y SSL ya no es computacionalmente intensivo (siempre y cuando esté configurado correctamente).

— Hubert Kario

Esta pregunta es un ejemplo clásico "no constructivo". No sabemos cuánto valora la seguridad de sus imágenes. La única forma de comunicar la importancia de la seguridad es mediante la metodología de autorización que implementa para proteger el acceso a esas imágenes. Lo que tienes son "argumentos de debate" en forma de "Respuestas". Pero ninguno de ellos es una encuesta completa de la seguridad moderna y las implicaciones técnicas. Debe leer sobre los métodos de seguridad proporcionados por su plataforma y evaluar el valor de cada uno para su situación; Si tiene más preguntas una vez que haya hecho eso, vuelva a preguntar.

— Chris S

17

Si está "bien" o no depende de cuán sensibles sean las imágenes.

Si no está utilizando SSL, las URL, HTML y las imágenes mismas se almacenarán en caché en las computadoras de su usuario. Esto podría filtrarse pero lo consideraría poco probable.

Las barras de herramientas del navegador, especialmente las creadas por compañías que ejecutan rastreadores, como Alexa y Netcraft, pueden informar las URL visitadas a sus sitios principales, listos para que el bot venga y rastree más tarde.

La autenticación adecuada, como la autenticación HTTP o una variable POST, no debe almacenarse en caché de esta manera ni informarse a ningún sitio web principal.

Otra técnica es usar URL únicas y de corta duración. De esa manera, incluso si se filtran, no importa mucho. Por supuesto, debe seguir actualizando a sus usuarios legítimos de las nuevas URL.

— Ladadadada
fuente

+1 por mencionar las barras de herramientas del navegador.

— Hubert Kario

23

No, no realmente, esto es solo seguridad a través de la oscuridad que no es seguridad en absoluto. Todo lo que sea directamente accesible desde Internet sin algún tipo de protección real se encontrará, indexará y almacenará en caché.

— usuario9517
fuente

10

¿No son todas las contraseñas solo seguridad a través de la oscuridad de todos modos?

— Winston Ewert

44

@ WinstonEwert: las contraseñas en sí mismas no tienen nada que ver con la seguridad a través de la oscuridad que se relaciona con el secreto del diseño / implementación. En el caso de, por ejemplo, la autenticación básica de Apache, su diseño / implementación está completamente abierto para que todos lo vean.

— user9517

10

sin sentido: todo es seguridad a través de la oscuridad. El punto es que para llegar allí se necesita información que sea lo suficientemente improbable como para ser adivinable. La frase "Seguridad a través de la oscuridad" es abusada en exceso. Una pieza aleatoria de URL es exactamente equivalente a poner una "contraseña" en la URL. La única pregunta es: ¿quién puede ver eso? Y la respuesta que puse en mi comentario es "representantes intermedios, además es http para que cualquiera que pueda espiar"

— Bron Gondwana

1

Un error (o volver a la configuración predeterminada) en la configuración de apache y sus directorios muestran índices con todos los archivos y directorios en la palma de su mano, no tanto con las contraseñas.

— Hubert Kario

44

Usted dice que la seguridad a través de la oscuridad "se relaciona con el secreto del diseño / implementación". Pero claramente, las URL aleatorias no relacionan el secreto del diseño / implementación. Por lo tanto, las URL aleatorias, cualesquiera que sean sus fallas, no se pueden clasificar como seguridad a través de la oscuridad.

— Winston Ewert

6

Se registrarán en cada proxy a lo largo del camino. Sin embargo, estará a salvo de usuarios avanzados y motores de búsqueda curiosos a menos que alguien publique el enlace.

Y ten cuidado con la aleatoriedad de tu generador, por supuesto.

Supongo que no estás buscando una seguridad súper alta aquí.

— Bron Gondwana
fuente

Si alguien publicara la URL, nada le impediría publicar una contraseña. La autenticación por el conocimiento como factor siempre se puede "engañar" de esta manera.

— Manuel Faux

@ManuelFaux: Claro, si es intencional. Pero también puede ser accidental. Por ejemplo, puede usar una herramienta que verifica las URL que visita para ver si han sido reportadas como maliciosas. Las herramientas saben que las contraseñas deben mantenerse en secreto. Saben que los parámetros en las URL pueden ser confidenciales. Pero no saben que las rutas en las URL sí. (Por ejemplo, http referer .)

— David Schwartz

5

Una URL críptica es útil para descargas de un solo uso, pero no proporciona protección real. Es necesario tener en cuenta que no todos los robots honran el archivo robots.txt, así que si hay algún enlace en cualquier lugar dentro de su sitio llevando a la disfrazada carpeta que va a ser indexados por algunos motores de búsqueda y una vez que se inicia no hay vuelta pasando.

Sugeriría usar un sistema de autenticación simple basado en .htaccess en su lugar, o además de lo que está proponiendo.

— John Gardeniers
fuente

5

Me gustaría agregar otra perspectiva, tal vez más aterradora, en las URL ofuscadas como este ejemplo. Incluso si su URL no se comparte de manera accidental, puede ser enviada a los motores de búsqueda por:

El ISP de un visitante. Las visitas HTTP están siendo recopiladas, extraídas de datos y, a veces, incluso vendidas directamente a terceros por los ISP.
El almacenamiento en la nube de un visitante. Hay una serie de servicios que almacenan marcadores e historial de forma gratuita para sincronizar entre las instalaciones del navegador. A menos que preencripten los datos como lo hace Mozilla, pueden implicarse las mismas prácticas de minería de datos.

YMMV.

— korkman
fuente

oh sí, o simplemente mediante un complemento del navegador que busca sitios relacionados o permite a los usuarios compartir notas sobre una página

— Bron Gondwana

2

En el pasado, utilicé un método similar para permitir a los usuarios crear espacios compartidos en un sistema de gestión de documentos. El contenido compartido no era secreto, por lo que el sistema no tenía que ser ultra seguro.

Acabo de hacer que la URL de cada usuario contenga una marca de tiempo de vencimiento y un MD5 de su correo electrónico.

Entonces, la URL se veía así:

http://my-url.com/1343689677-cba1f2d695a5ca39ee6f343297a761a4/

con lo anterior, si el usuario ingresó el correo electrónico user@gmail.com antes del 30 de julio, estaría listo.

No es exactamente seguridad de grado militar, pero hizo el trabajo.

— Dave e
fuente

0

Esto comparte la misma vulnerabilidad que almacenar sessionID en URL. Alguien puede copiar y pegar accidentalmente el enlace a otros, olvidarse de censurarlo en una captura de pantalla o dejar que alguien lo busque, ya que no tiene asteriscos como contraseñas.

Además, si algún contenido está protegido con contraseña, iniciando sesión Usted sabe que es un secreto. Si obtienes un enlace, puedes olvidarlo fácilmente.

Otra cosa es eliminar los privilegios del usuario. Puede eliminar un usuario, por lo que ya no puede iniciar sesión, pero con enlaces Debería cambiarlos todos y enviar nuevas URL a todos (excepto al usuario eliminado).

Creo que no está mal si son solo imágenes. Pero si estas son algunas imágenes que realmente no le gustaría compartir;) entonces le sugiero que use una palabra aleatoria más larga, más como la que se ha presentado.

EDITAR: Añadir? DO_NOT_SHARE_THIS_LINK a la URL: http://example.com/DO_NOT_SHARE_THIS_LINK/EU3uc654-this-should-be-longer/Photos?DO_NOT_SHARE_THIS_LINK

Eso es lo que hace, por ejemplo, Kongregate al incrustar juegos alojados en otro lugar (coloca las credenciales de autenticación en la URL del marco). Por cierto, Kongregate también utiliza enlaces de acceso de invitados para juegos no publicados, tal como lo desea.

— Markus von Broady
fuente

En realidad, es mucho peor que los ID de sesión, porque las sesiones caducan después de un tiempo. Los motores de búsqueda que obtienen una ID de sesión iniciada generalmente terminan presentando un enlace muerto / sesión no iniciada en los resultados. O, si al servidor no le importa, puede sincronizar la sesión de muchos usuarios y cuando uno de ellos inicia sesión, todos lo hacen. De todos modos, no es tan malo como una URL de

— inicio de

Por supuesto, es peor, y también puede recordar la IP en la sesión, ya que debe iniciar sesión primero para obtener el sessid en la URL, y luego puede destruir la sesión si la IP cambió.

— Markus von Broady