tags:

views:

40

answers:

6

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 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

+2  A: 

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.

Pekka
The links are being generated by using System.Guid.NewGuid().
JWB
@JWB on what platform?
Pekka
I'm using .NET 4.0
JWB
A: 

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.

Pablo Santa Cruz
+1  A: 

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.

Lekensteyn
+1  A: 

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

Paul Hadfield
Well its sensitive to a certain point. But if I attach the document to an email and send it, that email could be forwarded on to anybody. I really see this as just being the emailing of a link to the file, instead of just the file itself.
JWB
Very true, could make it very secure and people could still screen grab content
Paul Hadfield
+1  A: 

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.

Martinho Fernandes
True, in which case it wouldn't matter if the files were encrypted or not. The trick is to prevent the brute force attacks in the first place.
JWB
A: 

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.

Matt Greer
Yes that's my concern as well. But I was ideally hoping not force users to log in. The link should be able to be passed around via email much like the original document would be. There is some pattern to the use of the GUID's. For example, the first one is the company to which the document belongs. So once you had a document from one company that does immediately reduces the numbers. But its still 16^32. The URL provided was really only an example but I can go to further levels, e.g. company/task/documentid/filename where company/task/documentid would be GUIDs.
JWB