¿Por qué los sitios de almacenamiento de archivos tienen una identificación única y larga para sus enlaces de descarga?

  

¿Hay alguna razón (de seguridad) detrás de tenerlo de esa manera?

Sí, un tipo de Seguridad a través de la oscuridad : los archivos no son realmente seguros ya que las URL están disponibles sin autenticación. , pero los haría razonablemente privados ya que no son adivinables. Necesitaría más información (como los registros de historial del navegador) o algún tipo de fuerza bruta que no sería factible en este caso.

  

Estaba pensando que tal vez lo hacen así, de modo que las personas no puedan simplemente incrementar la ID en 1 y simplemente descargar todo lo que encuentren, lo que resultaría en la pérdida innecesaria de más ancho de banda. Pero ese no es el caso, ya que tanto la ID como el NOMBRE DE ARCHIVO deben coincidir, y los nombres de los archivos no son fáciles de adivinar.

¿No lo son? ¿Qué hay de readme.txt , password.txt , untitled.bmp , CV.doc , etc.

Las listas de palabras comunes están ampliamente disponibles y pueden alimentarse en un programa de fuerza bruta en combinación con extensiones de archivo comunes y diferentes ID para ejecutar un ataque en su sistema. Por eso es una buena idea tener un componente aleatorio seguro en sus URL.

Bueno, más que la seguridad (que puede lograr a través de otros medios, como la autenticación apropiada), el problema es que cuando tiene varios front-end, no puede implementar fácilmente un número de serie y escala, esp. Si su servicio también está distribuido geográficamente (ya sea para recuperación de desastres o simplemente por problemas de ubicación).

Imagine un servicio similar a Dropbox con miles de servidores de almacenamiento, almacenando archivos, ¿quién va a mantener un índice de lo que el número de archivo actual es? Incluso dentro de la misma cuenta, tiene el mismo problema con los clientes que cargan archivos simultáneamente.

La forma de evitarlo es crear URI para los archivos, de modo que la posibilidad de colisiones sea insignificante. Es por eso que los sistemas como el servidor SQL siempre han admitido tanto un índice primario de incremento automático como una identificación única basada en GUID. Para las personas que han trabajado en bases de datos, casi siempre usamos GUID, a menos que supiéramos que definitivamente tendríamos un único servidor de base de datos, en cuyo caso la mejor experiencia sería tener un incremento automático.

Están utilizando las URL como claves de acceso porque es mucho más fácil de escalar. En lugar de buscar el archivo, luego contactarse con una base de datos maestra para verificar si realmente se le permite acceder al archivo en base a otro secreto (una cookie de sesión, por ejemplo), asumen que la URL es lo suficientemente larga y aleatoria como para saberlo. Para ello, debe estar autorizado para acceder a él, sin necesidad de consultar un servicio de autenticación independiente.

Las desventajas son que no es fácil revocar el acceso a un archivo, especialmente si se almacenan en caché (tendrías que esperar a que caduquen las caches) y las URL pueden filtrarse más fácilmente que las contraseñas / cookies de sesión porque son fácilmente accesibles en el historial del usuario, por ejemplo, y en los registros de proxies de intercepción de HTTPS de la empresa.