Does a file linked by a long URL need encryption to prevent brute force attack?

I'm working on a website that allows users to be able to upload files. Each file could be linked to via a unique URL, e.g.

http://mysite.com/docs/4324fdf54f65487878788776876564724/456456878acd454bd454457877903631/file.pdf

The links would be sent only to people who would require them. But even if they did forward on the link to some one else, its no big deal about the file being visible to that person. It may well be sent to a person who is not logged in to the system and it still needs to be visible to them. The thing is that they should not be able to find other files easily by simply changing the URL. Given the length of the URL, I would think it unlikely a user would be able to find other documents, even under a brute force attack.

I've been looking at encrypting the files but in this case it probably 开发者_JAVA技巧adds an unnecessary load to the system and will require that ALL users log in to the system in order to provide a means of authenticating them.

How safe would you consider the URL to be? Would there be a need to encrypt the file or is the length of the URL enough to prevent a brute force attack discovering a file?

Thanks

The ID you are showing, assuming it was generated through a properly randomized process, should be pretty, pretty safe against any kind of brute force attack.

You could consider using the same mechanism to create the file name as your platform uses to generate session IDs: Session IDs need to be as safe against bruteforcing as your URLs.

Well, this is a pretty long URL, and given the fact that you've 16^64 possibilities with 0-9, a-f and a length of 64, it's not easily brute-forced.

It should not be a md5 of something, but something random.

It sounds like your saying the data isn't sensitive, so could be ok. You could ip log requests and block brute force attacks That way

If all that gibberish is random, that should be safe. But if you are expecting brute force attacks it would be better to implement some mechanism to prevent those, maybe by limiting requests per time per IP.

I think if your long file name contains enough randomness, you don't need to encrypt the file. It will be very difficult to mount a brute force attack to loop through the files.

It really depends on the data. This is still basically security through obscurity, which most consider a bad idea. It may be hard to brute force your way through, but all it would take is one person getting lucky and changing one character for the heck of it, getting a different file and that file happening to be sensitive enough that it's a problem.

Also consider the only promise GUIDs make is they are mostly unique. A curious enough person may be ableg to study your GUIDs and find a pattern.

I'm mostly playing devil's advocate, all in all your scheme is probably ok.