Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I'm creating a file storage site and what I would do is just have the download links format as:

https://www.domain.com/[id]/[file name] //id would just be 1, 2, 3 etc.

Dropbox and many others have it similarly except that the IDs are long / hashed:

https://www.dropbox.com/s/23d3kaz4adw9deq/anyfile.txt

Is there any (security) reason behind for having it that way?

I was thinking maybe they do it like that so that people can't just increment the id by 1 and just download everything they come across which would result in unnecessarily losing of more bandwidth. But that is not the case, because both the ID and FILE NAME need to match, and file names aren't easily guessable.

share|improve this question

2 Answers 2

up vote 4 down vote accepted

Is there any (security) reason behind for having it that way?

Yes - a type of Security through obscurity - the files aren't really secure as the URLs are available without authentication, but it would make them reasonably private as they are not guessable. You would need more information (such as browser history logs) or some kind of brute force that would be unfeasible in this case.

I was thinking maybe they do it like that so that people can't just increment the id by 1 and just download everything they come across which would result in unnecessarily losing of more bandwidth. But that is not the case, because both the ID and FILE NAME need to match, and file names aren't easily guessable.

Aren't they? How about readme.txt, password.txt, untitled.bmp, CV.doc, etc.

Common word lists are widely available, and can be fed into a brute force program in combination with common file extensions and different IDs in order to execute an attack on your system. This is why it is a good idea to have a secure random component in your URLs.

share|improve this answer
    
So giving them not guessable IDs will make the files reasonably private in the sense that if the URL has not been shared nobody other than the owner should be able to access it? –  Kid Diamond Jun 7 at 10:59
1  
@KidDiamond: That's correct - you should of course use HTTPS if possible (and disable HTTP) which will stop the URLs being recorded in any proxy logs and prevent any MITM attacks from snooping the URLs. Also, you may want to secure your server/load balancer/firewall/etc logs as these may contain the hidden file URLs. –  SilverlightFox Jun 7 at 11:40

Well, more than security (which you can achieve via other means, such as appropriate authentication), the issue is that when you have multiple front ends, you cannot easily implement a serial number, and scale, esp. if your service is also geographically distributed (either for disaster recovery or just geo-locality concerns).

Imagine a drop box like service with hundreds (if not thousands) servers saving files on hundreds (if not thousands) back end servers, who is going to keep an index of what the current file # is? Even within the same account, you have the same problem with clients uploading files simultaneously.

The way to avoid that is to come up with URIs for the files such that the possibility of collisions is negligible. That is why systems such as SQL server have always supported both an auto-increment primary index, as well as a unique ID which was based on GUID. For folks who have worked on databases (such as myself), we almost always used GUIDs unless we knew we would definitely have a single DB server, in which case having auto-increment was the best experience to have :-)

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.