URL security - what is considered a secure unguessable URL?

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 开发者_如何学Pythonyou maintain authentication across multiple domains? Let's say the content of two albums could be delivered from to different servers.

---

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.

---

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.

---

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,

---

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.

---

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)