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 would like to move from sequential to random user-ids so I can host profile photos publicly. i.e. example.com/profilepics/asdf-1234-zxcv-7890.jpg

How long must user-ids be to keep anyone from finding any user photos for which they have not been given the link?

Does 16 lowercase letters and zero through nine provide a reasonable complexity? I'm basing this on 36^16 = 8x10^24, conservatively estimate 10 billion user accounts reduces the space to 8x10^14. At 1000 guesses/second it would take 25k years to find an account. Unless I'm overlooking something.

share|improve this question
    
Well AWS does that kind of thing with user files (128bit random name if I recall correctly), so you can assume it is "safe enough", as shown in practice. –  Damon May 19 at 10:24
    
@owenfi Generate 128bit+ values and you're alright. For your specific case and application, that's more than good enough. –  Adnan May 19 at 10:27
11  
It is meaningless anyway. Passwords, tokens, certificates, what security exactly isn't by obscurity? The saying when used correctly applies to the method not the secret. –  JamesRyan May 19 at 11:28
3  
This question is equivalent to "How should I choose a secure password?". I don't see any difference at all. –  usr May 19 at 13:03
    
This is the same thing as the dropbox vulnerability from last week (security.stackexchange.com/questions/57436/…) - these are public urls, they can be crawled and will be indexed, user's may share/post their own links, etc. –  Eric G May 20 at 2:55
show 1 more comment

6 Answers

up vote 44 down vote accepted

It depends entirely on what you mean by "safe".

If your only concern is an attacker guessing URLs, then 16 alphanumerics gives roughly 8,000,000,000,000,000,000,000,000 possible addresses, which is plenty to stop random guessing -- in order for an attacker to have a 50% chance of finding even one picture on a site with a thousand users in a year, they'd need to make 100 trillion tries per second, enough traffic to bring down even something like Amazon or Google.

But there are other ways for URLs to leak: people putting them in emails or blog posts, web crawlers finding pages you didn't secure adequately, and so on. If you really need to protect something, you need to put it behind the same sort of security as the rest of your website.

Personally, for making hard-to-guess URLs, I'd use GUIDs/UUIDs. The search space is absurdly huge, you don't need to coordinate generation between multiple servers, and most languages have standard routines for handling them.

share|improve this answer
13  
Most GUID generators do not guarantee unpredictable outputs. So you should generate 16 random bytes from a CSPRNG instead of using standard GUID generators. –  CodesInChaos May 19 at 10:10
10  
@R.. not necessarily, that depends on your GUID or UUID implementation. However, I think most these days are probably random, but maybe not secure random (so possibly predictable). The thing to remember is that the goal is "unique", not "unpredictable", so good implementations satisfy "unique", and only maybe are also "unpredictable". –  Tim S. May 19 at 13:43
2  
@R.. UUIDs are not cryptographic entities, they are only unique as far as everyone agree to make them so. The good thing is, for any application that use UUIDs as intended it doesn't matter if someone else copies or otherwise reuse the UUIDs, it would only be a problem if the two systems then has to share data. If you have to share data with someone who intentionally tries to break the UUID system, you have probably got bigger problems. –  eBusiness May 19 at 17:33
9  
@R.. You are incorrect; GUIDs are documented as a source of uniqueness, not randomness. A type 4 GUID is random, but that randomness is not guaranteed to be crypto strength and in practice it is not. More generally: GUIDs were not designed to be a part of any security system; use of them in a security system is an "off label" use and is therefore a very bad idea. –  Eric Lippert May 19 at 17:43
2  
@R..: The GUID system is deliberately not designed to be resistant to malicious usage. It's like a stop sign; a stop sign does not compel you to stop. If someone wants to ignore it and blow through an intersection because they're malicious and enjoy causing accidents, the stop sign isn't going to stop them. GUIDs are a cooperative system for ensuring uniqueness; all parties are presumed to be non-hostile. –  Eric Lippert May 19 at 17:45
show 15 more comments

Maybe not the answer to your question, but if you would like to "hide" the location of your profile pictures on a website, you could just embed the image as data URIs. You can base64 encode the image on your server and embed the string on your website, instead of exposing any image paths.

see http://css-tricks.com/data-uris/ and http://css-tricks.com/examples/DataURIs/ for a description and demo.

share|improve this answer
2  
@FaridNouriNeshat, Data URIs aren't limited to 2000 characters the way http URIs are. If you need to support Internet Explorer 8 or earlier, the limit is 32k; if you can require IE9 or later, there is no limit. –  Mark May 19 at 10:20
    
@Mark You're right. Sorry, I was confusing this with another method. –  Farid Nouri Neshat May 19 at 10:46
9  
This has a problem: Bandwidth. Caches cannot work here, so you end up sending the same 30KiB image quite more often, which translates into money and performance. –  Darkhogg May 19 at 10:47
    
Holy smokes these are cool when called for! –  owenfi May 19 at 21:05
add comment

Since you already brought up dropbox, I think we can give at least one reason why doing this is a bad idea:

Dropbox disables old shared links after tax returns end up on Google

Basically it's way too easy for URLs to leak inadvertently considering how many users use them. If your users are educated about this and avoid these problems I guess it's reasonably safe, but that's a big assumption to make.

share|improve this answer
1  
Thanks, this a very good point to bear in mind for this topic. In my case it should only be consumed through an app privately, so it is very unlikely the average user will get a hold of the URL to share it in the first place (short of reverse engineering the API). –  owenfi May 19 at 19:56
    
@owenfi In that case I think we can consider this reasonably safe assuming you use a large enough address space and a secure random algorithm to create the URL. –  Voo May 19 at 20:53
1  
The article Voo cited contained a link to another article even more appropriate to the question: theregister.co.uk/2011/05/08/file_hosting_sites_under_attack "In 2011, researchers found that it was possible to access shared files by guessing the URLs." –  WGroleau May 20 at 2:10
    
@WGroleau It should be pointed out that in that link all the given examples are of systems that are in one way or another broken. None of the broken systems used a large search space combined with a secure random generator. I mean really.. sequential URLs? So I find that less applicable than the given link which shows an inherent flaw in the system (for some uses only) and not just problems with broken implementations. Although it shows that people will try to exploit such a system so better make sure it's sound! –  Voo May 20 at 20:42
add comment

The other answers are generally good, but another consideration is the transport. If you're using plain http or any other non-encrypted protocol (or sending the urls via email), all data you transmit and receive, including these urls, should be considered completely public from a security standpoint. A large portion (anyone have stats?) of users are on public wifi access points with no encryption and active url/image scraping of such networks is common.

share|improve this answer
    
Aha, I had overlooked that! Thanks! Fortunately, in my service's case SSL is enforced. –  owenfi May 19 at 19:57
add comment

As mentioned by others, a URI for a specific image will leak out sooner or later, no matter how long or convoluted it is. If you are willing to restrict viewing to logged-in users, you could use, say, .../image/profile.php?u=12345 to display user 12345's image without a direct URI to the photo being available to pass around to the general public. It is assumed that random people (not logged in) would get nothing back from profile.php. Note that nothing prevents a logged-in user from saving that image (especially if it's cached) and passing it around. There are things that might be done with cache control headers, etc., or putting the image in Flash, or whatever, but if an image is viewable on someone's browser, with enough work it will be possible to grab and save it.

share|improve this answer
    
There's nothing you can do to stop the user taking a screen-shot, for instance! :) –  nicodemus13 May 20 at 15:04
add comment

The problem with your scheme is that the numerous users of your URLs will probably not all guess that these contain sensitive information. And part of that problem is that you likely have no idea just how big the user base is; for these URLs, the users include

  1. The people you think of as users.

  2. Their browser plugins/addons/extensions.

  3. Just about any third-party content on your site (ads, analytics, social plugins, ...) will likely, one way or another, inform third-parties of the URLs in question.

  4. Seemingly random websites seeing the URL as referrer URL (do you really know what curious extra links your users conjure into your web site through browser addons?).

Empirical evidence is that https-only URLs advertised as password-equivalent get indexed by Google, repeatedly, e.g. in the case of the password-free Bitcoin online wallet Instawallet (note they have gone so bankcrupt over this that they don't even afford themselves a valid SSL certificate anymore).

share|improve this answer
    
Thanks, some really good edge cases pointed out here. Looks like before rolling this out on a website I need to put it behind auth. (For now it's in an app-api only, so the 3rd parties will be limited somewhat to networking modules, and maybe 3rd party tools observing my documents directory.) –  owenfi May 21 at 1:56
1  
People might even enter the whole URL into the Google search bar, and therefore disclosing the URL to Google. –  queueoverflow May 21 at 12:52
add comment

protected by Community May 21 at 4:48

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

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