13

Is it considered "safe" to use URL constructed from random characters like this?

http://example.com/EU3uc654/Photos

I'd like to put some files/picture galleries on a webserver that are only to be accessed by a small group of users. My main concern is that the files should not get picked up by search-engines or curious power-users that poke around my site.

I've set up an .htaccess file, just to notice that clicking on http://user:pass@url/ links doesn't work well with some browsers/email clients, prompting dialogs and warnings messages that confuse my not-too-computer-savy users.

4
  • No. You can use this, but not as the only or main authentication mechanism. Jun 30, 2012 at 21:03
  • 2
    I have tried this as an experiment many times, and every time the links wind up in search engines. I don't know how, but I know it happens. Jul 1, 2012 at 12:07
  • You may want to configure SSL to stop the warnings, you can get free certs from startssl.com and SSL is no longer computationally intensive (as long as its configured properly). Jul 1, 2012 at 14:34
  • This Question is a classic "Not Constructive" example. We do not know how much you value the security of your pictures. The only way you could communicate the importance of security is by the authorization methodology you implement to protect access to those pictures. What you got are "debate arguments" in the form of "Answers". But none of them is a full survey of modern security and technical implications. You should read up on the security methods provided by your platform and assess the value of each for your situation; if you have further question once you've done that, then ask again.
    – Chris S
    Jul 1, 2012 at 19:10

7 Answers 7

18

Whether it is "okay" or not depends on how sensitive the images are.

If you are not using SSL, the URLs, HTML and the images themselves will be cached on your user's computers. This could leak but I would consider it unlikely.

Browser tool bars, especially ones made by companies that run crawlers, such as Alexa and Netcraft, can report visited URLs back to their parent sites, ready for the bot to come and crawl later.

Proper authentication such as HTTP auth or a POST variable should not be cacheable this way or reported back to any parent website.

Another technique is to use unique and short-lived URLs. That way, even if they do leak, it doesn't matter much. Of course, you have to keep updating your legitimate users of the new URLs.

1
  • 1
    +1 for mentioning browser toolbars. Jul 1, 2012 at 14:35
23

No, not really, this is just security through obscurity which is no security at all. Anything which is directly accessible from the internet without some form of real protection will be found, indexed and cached.

10
  • 11
    Aren't all passwords just security through obscurity anyways? Jul 1, 2012 at 5:36
  • 4
    @WinstonEwert: Passwords themselves are nothing to do with security through obscurity which relates to secrecy of design/implementation. In the case of for example Apache basic auth it's design/implementation is fully open for all to see.
    – user9517
    Jul 1, 2012 at 7:20
  • 11
    nonsense - everything is security through obscurity. The whole point is that to get there you need a piece of information which is sufficiently unlikely to be guessable. The phrase "Security through Obscurity" is massively over-abused. A random piece of URL is exactly equivalent to putting a "password" in the URL. The only question is - who can see that, and the answer as I put in my comment is "intermediate proxies, plus it's http so anyone who can snoop" Jul 1, 2012 at 8:10
  • 2
    Security by password is has a public (username) and private (password) components. Security by obscurity refers to situations where any public component (any username, or anonymous) can give the correct private component and gain entry. Anyone arguing that all security is obscurity hasn't studied security principles.
    – Chris S
    Jul 1, 2012 at 19:06
  • 4
    You say that security through obscurity "relates to secrecy of design/implementation". But clearly, random URLS don't relate the secrecy of design/implementation. Thus, random URLs, whatever their faults, cannot be classified as security through obscurity. Jul 2, 2012 at 2:51
6

They will be logged in every proxy along the way. You'll be safe from curious power users and search engines unless someone actually publishes the link though.

And watch out for the randomness of your generator of course.

I'm guessing you're not looking for super-high security here.

2
  • If someone would publish the URL, nothing would hold him from publishing a password. Authentication by knowledge as a factor can always be "tricked out" like this. Jul 1, 2012 at 12:02
  • @ManuelFaux: Sure, if it's intentional. But it can also be accidental. For example, he may use a tool that checks URLs he visits to see if they've been reported malicious. Tools know passwords are supposed to be kept secret. They know parameters in URLs can be sensitive. But they don't know that paths in URLs do. (For example, http referer.) Jul 1, 2012 at 12:10
5

A cryptic URL is handy for single-use downloads but provides no real protection. You need to be aware that not all bots honour the robots.txt file, so if there is any link anywhere within your site leading to the disguised folder it will be indexed by some search engines and once that starts there is no going back.

I'd suggest using a simple .htaccess based authentication system instead, or in addition to, what you are proposing.

5

I'd like to add another, maybe more scary perspective on obfuscated URLs like this example. Even if your URL is not accidentially shared, it may be submitted to search engines by:

  • A visitor's ISP. HTTP visits are being collected, datamined and sometimes even outright sold to third parties by ISPs.
  • A visitor's Cloud Storage. There are a number of services storing bookmarks and history for free to sync across browser installs. Unless they pre-encrypt the data like Mozilla does, the same data mining practices can be implied.

YMMV.

1
  • oh yes - or just by a browser plugin that looks for related sites or allows users to share notes about a page Jul 1, 2012 at 12:25
2

In the past I used a similar method to allow users to create share spaces on a document management system. The shared content wasn't top secret so the system did't have to be ultra secure.

I just made each users URL contain a expiry timestamp and a MD5 of their email.

SO the URL looked like:

http://my-url.com/1343689677-cba1f2d695a5ca39ee6f343297a761a4/

with the above, if the user entered the email [email protected] before the 30th of July they'd be good to go.

Not exactly military grade security but did the job.

0

This shares same vulnerability as storing sessionID in URL. Someone can accidentally copy-paste the link to others, forget to censor it in a screenshot, or let someone look it up, as it's not asterisked like passwords.

Also, if some content is password protected, by logging in You know it is a secret. If You get a link, you can easilly forget it.

Another thing is removing user privileges. You can delete a user, so he can no longer login, but with links You would need to change them all, and send everyone (except the deleted user) new URLs.

I think it's not bad if these are just images. But if these are some images you would really, really not like to share ;) then I suggest you to use longer random word, more like the one dave e presented.

EDIT: Add ?DO_NOT_SHARE_THIS_LINK to the URL: http://example.com/DO_NOT_SHARE_THIS_LINK/EU3uc654-this-should-be-longer/Photos?DO_NOT_SHARE_THIS_LINK

That's what e.g. Kongregate does when embedding games hosted elsewhere (it puts auth credentials in frame's url). BTW, Kongregate also uses guest access links for not published games, just the way You want to use.

2
  • Actually it's much worse then session IDs, because sessions expire after some time. Search engines fetching a logged in session ID usually end up presenting a dead link / not logged in session in results. Or, if the server does not care, it may sync the session of many users and when one of them logs in, they all do. Anyways, not as bad as a permanently logged in URL :-)
    – korkman
    Jul 1, 2012 at 11:18
  • Of course it's worse, and You may also remember the IP in session as You need to login first to get the sessid in url, and then You can destroy the session if IP changed. Jul 1, 2012 at 11:42

Not the answer you're looking for? Browse other questions tagged .