5

I was just thinking about the URLs of my current web project. The user can access different resources, like images using a web site. The URLs look something like this http://localhost:2143/p/AyuducjPnfnjZGfnNdpAIumehLiWaYQKbZLMeACUqgsYJfsqarTnDMRbwkIxWuDd

Now, I really need high performance, and one way could be to omit the extra round trip to the database for authentication and just rely on the URL to be unguessable.

Google does this with Picasa Web Albums, you can make an album private or unlisted. This secures the album but not the photo itself. Take this photo of Skagen (Denmark); http://lh4.ggpht.com/_Um1gIFfF614/TQpVMvN3hPI/AAAAAAAANRs/GY5DxrDPHUE/s800/IMG_4074.JPG, it's actually in a private album, but you can all see it.

So what is your take on this? Is a 64 character long random string "secure" enough? Are there other approaches?

Let's say I choose to do authentication for each request to the resources. The users have logged in to the site on somedomain.com, where they access their, let's say photo albums. A cookie is dropped to maintain their authentication.

Now the actual photos are served through some form of CDN or storage service on a completely different URL.

How would you maintain authentication across multiple domains? Let's say the content of two albums could be delivered from to different servers.

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
Christian Sparre
  • 955
  • 3
  • 15
  • 25
  • Following comment is via Martona: – Marc Gravell Dec 24 '10 at 09:06
  • If the storage service can talk to the same database server that your web server doing the authentication can talk to, then it's simple. One way would be to generate a single-use token (say, 64 chars :) on your webserver after auth, which is put it into the database. You then send the user to the storage server with a redirect, where the URL contains your token. The storage server looks it up in the database, and if it checks out, then it drops its own session cookie on the browser. The storage server may access the database via a web service exposed by your webserver. No direct conn needed. – Marc Gravell Dec 24 '10 at 09:06

5 Answers5

5

Do the math. 64 characters chosen cryptographically randomly (NOT rand()!) from the alphabet of 62 possible values (26+26+10: caps/lowercase/numbers) will yield 5.16e+114 possible values (62^64). Trying a million combinations a second, it would take 1.63e+101 years (moar than a googol) to guess the code. It's probably good enough. A shorter one is probably pretty good too.

martona
  • 5,760
  • 1
  • 17
  • 20
  • As Stefan H pointed out in his answer... to each his own. The URL itself is quite unguessable. But it's an URL that's displayed in the browser's address bar, saved in its history, etc. So it really depends on what you're trying to do. – martona Dec 16 '10 at 18:23
1

64 characters * 6 bits of entropy each (Base-64 encoding, right?) is a 384-bit key. That would be considered quite weak by today's standards, if the key can be tested off-line. As long as the key can only be tested using your live system, it will probably be quite effective and you can also add active countermeasures to block clients that try many bad keys.

You're probably at much higher risk of the keys becoming public through server logs, browser logs, referrer headers, transparent proxies, etc.

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
  • 1
    384 bits is not "quite weak" when it comes to secret keys (which this is, in essence). On the contrary. It's stronger than you'll ever need. A 384-bit RSA key _is_ very weak but that is not 384 bits of pure randomness... far from it. You're right about everything else. – martona Dec 16 '10 at 18:37
  • @martona: Yeah I think you're right. Even clusters of hardware accelerators probably aren't going to be able to process even 2^60 combinations per second (if there was an off-line test, and there shouldn't be). Guessing isn't an attack that needs to be feared. – Ben Voigt Dec 16 '10 at 18:43
0

There is definitely a risk to only using an "unguessable" URL. It really depends on what sort of stuff you are trying to secure. Take picasa, they are photos that are being secured, not bank records, therefore a random query string is fine. Plus, the larger your website gets the larger attack surface you will open up. It is one thing if there is only one page, that could take a fair bit of scanning to try and figure out what single URL is in use. But if you have hundreds of thousands of pages like that, then attackers are far more likely to "guess" the right page.

So, I don't really have an answer for you, just some advice on the "unguessable" url approach: don't do it. It's not secure.

Cheers,

Stefan H
  • 6,635
  • 4
  • 24
  • 35
0

There's no such thing as an unguessable URL, and even if there were the very first time you used it over a non-SSL connection it could be seen by anyone who wanted to, by ISPs and by proxies, caches, etc. Do you really want your users/customers to trust their private photos to "unguessability"?

Making URLs unguessable isn't a great approach to security, unless your unique URLs have a time limit on their usefulness (e.g. they're short-lived URLs)

Martin Peck
  • 11,440
  • 2
  • 42
  • 69
0

Here is my 2-cent. I had similar problem. Our intial approach was to rename the file with random but unique name and do a two way encryption with a complex key for that name. But the things eventually boiled down to the fact that once a URL is in someone's hand, you can't guarantee the stuff's privacy. We eventually went down to DB based authentication route. See here

Edit#1: On CDN issue, I am not sure what the solution would be. But even if what martona is saying is correct. One of the purposes of CDN is to reduce load from your main servers, and pinging back to server for each resource is probably not a good idea.

Community
  • 1
  • 1
Nishant
  • 54,584
  • 13
  • 112
  • 127