Ask HN: How safe are unique URLs as an authentication method?

https://news.ycombinator.com/item?id=235340

by edb • 18 years ago

4 10 18 years ago

news.ycombinator.com

I recently built a webapp for my company to track the progress of a certain process we were engaging. According to the logs, the google robot came in, followed all our delete links and erased the whole database of information. I have no idea how it figured out our unique url... Luckily this was neither critical or hard to recover from backup, but this begs the question:

How safe are unique URLs as an authentication method? Can you really replace a username/password prompt safely with a url like www.myservice.com/go/HDSFF98XC6Y219G23KJBVXC986R23/ without concern?

pg• 18 years ago

Google didn't guess your url. So the way you've set up the question also answers it: safe unless you happen to expose a link to one.

edb3• 18 years ago

The issue though, is that we had thought that the address wasn't exposed. We're still baffled as to how the address got exposed to google, but we're assuming one of our employees must have done it somehow.

That made me thing though... can you trust your users not to expose their private URL addresses? Aren't you trusting it to them, and if you have a user without internet experience signing up, what happens if he submits his private URL to google and makes it public? Doesn't that create a security hole?

makecheck• 18 years ago

There is no such thing as a "private URL" that is hosted on a public web site. You need to augment the URL with something like: - A server-side authentication scheme; so if the URL is visited, it can't trigger anything important without a password. - An expiration mechanism; so that after a certain amount of time, a particular URL has no effect even if it is "visited". - A cookie; so that the URL only works if visitors are people you expect (because they have the right cookie on the client side, and someone like Google would not). Cookies are actually another way to implement expiration, too.

toni• 18 years ago

Of course it creates a security hole! You are vulnerable to 'reply attacks'. It seems to me that you already know the answer to your question, but are struggling in a last chance to refuse believing the reality.

Putting any sensitive information into a url is bound to be exploited sooner or later. Liberally, you can hold the info in urls for the duration of user session but anything beyond that is totally unwise. For the reasons you already mentioned.

Other possibilities for unintentional exposing of your personal ulr include: - Users who have google/alexa/amazon/etc. toolbars installed on their browsers, they browse to their personal page, or maybe bookmark it, and alexa/google immediately realize that it is not indexed so they start crawling it.

- Other phenomenons like Google Desktop Search crawls and caches all user bookmarks.

You should not use http GET method to perform unrelated operations. If you want to offer a delete option to your users, use http POST method. For authentication purposes, i absolutely recommend using HTTPS with POST method.

icey3• 18 years ago

Outside of the safety of URLs (which, in my opinion are not terribly secure); you really should set up a robots.txt file, so that you don't have a repeat occurrence of this.

edb3• 18 years ago

Of course. We got lucky this time, it was just a robot, which is easy to fend off with robots.txt. But what if it was a user who did the same thing?

icey3• 18 years ago

Which is my point about the safety of URLs... If a user is authenticating to your site, why not use a session to track whether or not they are authenticated?

mdasen• 18 years ago

They can be made pretty secure for those purposes. Most likely what happened in your case was that one of your clients/coworkers/other posted such a URI in a blog/forum/other that Google spiders. As a rule of thumb, GET requests should never add, destroy, or alter data. Spiders won't* follow POST.

Here are my thoughts on making these URIs secure:

First, always have such a URI on a 72-hour dead clock. You send the URI to the user and it's good until used or 72-hours later. Then they need to generate a new one.

Second, make it two factor. Rather than having something.com/reset_pass/12345, have it be something.com/reset_pass/{user_id}/12345. Just another level of protection.

Third, use base 62 numbers (0-9, a-z, A-Z). It's something any browser can handle with no special chars. Remember, base is more important than length. A 6-digit, base 62 number will go to greater than 56 billion different combinations. If someone guesses from one of 56 billion numbers, holy sh*t do they deserve to break in. If you're paranoid, make it 10 digits and get over 800 quadrillion combinations. No one is going to brute force that and 10 digits is still small to display.

Fourth, you can rate limit by IP address. Set it high - like, 100 attempts per hour limit. Why so high? You don't want to piss off users who are, well, stupid. And to get to 800 quadrillion making 100 attempts per hour would take millions of years - heck, let's say you're so high-profile that they'd put a farm of 100,000 IP addresses on it you're still looking at over a million years.

In many ways, these URIs can be made more secure than passwords since most passwords won't be as random or strong. There are some caveats:

These URIs will show up in browser histories and your server logs. They are one-time secure things. Once the user has used it, the next time they need such a thing, they need a new URI. If someone gets into your logs, they can see these URIs and reset peoples passwords unless they expire on use. Same with browser history.

As I've mentioned, they can be posted. Users post things they shouldn't all the time (including passwords). Have it time out so it's only a breach for a short period.

Don't use it as a replacement for user/pass. Just don't. If the same URI stays good, it is insecure.

Good luck!

Ask HN: How safe are unique URLs as an authentication method?

Related Stories