Is a website published in an obscure directory comparably secure to being placed behind a login? [duplicate]

Question

Let's say I create a microsite for a client that contains confidential business information. We need to place this in a location the client can access, in order for them to approve for launch.

If we place this microsite behind a login, we have a guarantee noone can just stumble across the content and compromise it. But, what if we publish it to an undisclosed, unindexed directory with a name of the same "strength" as the aforementioned password? For the sake of argument, "undisclosed and unindexed" means it won't be manually or automatically linked to/from anywhere, or indexed by any website search on the same domain. It also won't be placed in it's own subdomain, so DNS crawling is not a concern.

My initial instinct says this is simply security by obscurity, and is much less secure due to the possibility of someone just stumbling over it. But, after thinking about it, I'm not so sure. Here's my understanding:

• Even using a dictionary-weak, two-word string for both the password and the URL, there are still billions of guessable options. Placing it in the URL doesn't magically reduce that list.
• Login pages can have brute-force protection, so an attacker would get optimistically 20 attempts to guess. URL guessing would have to be caught by the server's DoS or spam protection, and may allow 200 404-producing guesses if you're anticipating an attack - still not statistically significant to billions of options.
• The login page is linked from a website - it's a visible wall for an attacker to beat on. It's evidence that something exists worth attacking for. Guessing the URL, however, is blind. It requires being on the right domain (and subdomain), and operating on faith that, even after tens of thousands of incorrect guesses, you're still going to turn something up.
• The URL has an extra susceptibility to being index/spidered externally. However, most respectable spiders don't "guess" at sites, they just follow links. A malicious "guessing" spider would be caught by the same DoS/spam protection as point 2.

From what I can tell, the only meaningful difference between the two is imagined peace of mind. The possibility that the URL can be stumbled over makes people nervous, and the login makes things feel secure, despite them seeming comparable based on the points above. The URL option still feels like it should be much less secure, though. What am I failing to consider?

---

EDIT: A lot of valid human-error concerns popping up. This question was inspired by a client that implements a degree of human-proofing security - vpn login via keyfob, screen dimmers, 5min sleep timeouts, social media blackout, etc. For this question, please assume no public-network access and no incidental breaches like shoulder-watching or "oops! I posted the link to twitter!". I'm looking for a more systematic answer, or at least one more satisfying than "humans screw up".

---

EDIT 2: Thanks for pointing out the possible duplicate. IMHO, I think each has a value as an individual question. That question addresses image security specifically, and delves into alternate methods of securing and encoding that data (eg base64 encoding). This question more specifically addresses the concept of secrecy vs obscurity, and applies it to why a login is better than a URI independent of the type of data in question. Furthermore, I don't think the accepted answer there explains my particular question as deeply or thoroughly as @SteveDL's great answer below.

Answer 1

I'll extend on one point at a slightly more abstract level about why public authenticated spaces are preferable to hidden unprotected spaces. The other answers are all perfectly good and list multiple attacks one should know better to avoid.

Everyone with formal training should've heard at some point of the Open Design security principle. It states that systems must not rely on details of their design and implementation being secret for their functioning. What does that tell us about secret passwords vs. secret URLs?

Passwords are authentication secrets. They are known by a challenged entity that provides them to a challenging entity in order to authenticate. Both parties need a form of storage, and a communication channel. Stealing the password requires compromising either of the three. Typically:

1. The user must be trapped or forced into revealing the password
2. The server must be hacked into so that it reveals a hashed version of the password
3. The confidentiality of the channel between the user and the server must be compromised

Note that there are plenty of ways for authentication to be toughened, starting by adding an additional authentication factor with different storage requirements and transmission channels, and therefore with different attack channels (Separation of Privileges principle).

We can already conclude that obscure URLs cannot be better than passwords because in all attack vectors on passwords, the URL is either known (2 and 3) or obtainable (1).

Obscure URLs on the other hand are manipulated much more commonly. This is in large part due to the fact that multiple automated and manual entities in the Internet ecosystem process URLs routinely. The secrecy of the URL relies on it being hidden in plain sight, meaning it must be processed by all these third-parties just as if it were a public, already-known commodity, exposing it to the eyes of all. This leads to multiple issues:

• The vectors through which these obscure URLs can be stored, transmitted and copied are much more numerous
• Transmission channels are not required to be confidentiality-protected
• Storage spaces are not required to be confidentiality or integrity protected, or monitored for data leakage
• The lifetime of the copied URLs is by and large out of the control of the original client and server principals

In short, all possibilities of control are immediately lost when you need that a secret be treated openly. You should only hide something in plain sight if it is impossible for third-parties to make sense of that thing. In the case of URLs, the URL can only be functional in the whole Internet ecosystem (including your client's browser, a variety of DNS servers and your own Web server) if it can be made sense of, so it must be kept in a format where your adversaries can use it to address your server.

In conclusion, respect the open design principle.

Answer 2

Since we're talking theoretically, here are several reasons why a random URL alone is not sufficient enough to protect confidential data:

• URLs can be bookmarked.
• URLs are recorded in the browser history (public kiosk).
• URLs are displayed in the address bar (shoulder surfers).
• URLs are logged (think 3rd party proxy).
• URLs can be leaked via Referrer headers

I'm unclear about some of your bullet points.

Are you saying that this potential webserver / website / platform does indeed have directory fuzzing protection, or is this hypothetical?

Even so, it doesn't protect against the items I mentioned above.

Answer 3

Guessing the URL, however, is blind. It requires being on the right domain (and subdomain)

However, most respectable spiders don't "guess" at sites, they just follow links’

Considering major search engines not to be respectable is a defensible position, but it doesn't change the fact that they do more than follow links. In particular, search engines can and do enumerate DNS entries, so the mere existence of a subdomain is a risk.

A lot of stuff ends up on Google even though people swear they never linked to it from anywhere and Google doesn't return any page that links to the site.

That's in addition to the problem that people generally don't treat URLs as confidential, and that URLs appear in all kinds of places such as server, browser and proxy logs. URLs are also visible to, and used by, many more browser extensions than passwords. If the “hidden” site has outgoing links, the URL is likely to appear in Referer: headers.

There's also the risk that through a misconfiguration, a link to the hidden site appears in a non-hidden place, for example if the hidden site is hosted on a site that offers a local search facility.

The login page is linked from a website - it's a visible wall for an attacker to beat on. It's evidence that something exists worth attacking for.

That doesn't make sense. Use decent software and a randomly-generated password, and there's no attack surface worth pursuing. In contrast, a hidden directory doesn't even look like something worth attacking, it looks like something that's open to the public.

A secret URL is particularly risk-prone because if the URL is leaked accidentally and a search engine discovers it, the whole site content will become exposed through that search engine. A password doesn't fail as catastrophically: if the password is leaked, it still takes some voluntary action for someone to start downloading the data, it doesn't automatically start a machinery that will publish it for everyone to see.

Answer 4

I agree with the other answers that it is a bad idea, simply because people (=> developers => applications that log information) do not consider URL's to be private and thus there are a lot of different ways the key could be leaked. What you however have correctly recognized is that passwords essentially are a form of security through obscurity. And that conceptually there is nothing wrong with the scheme you're proposing. The only problem is introduced due to the fact that the scheme you're proposing is misusing systems in ways they were not intended for.

Even using a dictionary-weak, two-word string for both the password and the URL, there are still billions of guessable options. Placing it in the URL doesn't magically reduce that list.

True, but it doesn't make it safer either.

Login pages can have brute-force protection, so an attacker would get optimistically 20 attempts to guess. URL guessing would have to be caught by the server's DoS or spam protection, and may allow 200 404-producing guesses if you're anticipating an attack - still not statistically significant to billions of options.

If you're anticipating an attack you will probably limit it equally to best practices for brute-force protection for your type of application. So indeed, it isn't worse if done right, but it definitely isn't better and will likely be worse as you will have to do a lot more custom work.

The login page is linked from a website - it's a visible wall for an attacker to beat on. It's evidence that something exists worth attacking for. Guessing the URL, however, is blind. It requires being on the right domain (and subdomain), and operating on faith that, even after tens of thousands of incorrect guesses, you're still going to turn something up.

Absolutely true, and for this reason I have seen some companies hiding their intranet login pages on slightly unpredictable URLs. Is it something to rely on? Definitely not. Is it something that might stop certain low-profile attackers? Definitely.

Either way, this however only provides limited benefit on it's own compared to a large trade off as described in the first paragraph.

The URL has an extra susceptibility to being index/spidered externally. However, most respectable spiders don't "guess" at sites, they just follow links. A malicious "guessing" spider would be caught by the same DoS/spam protection as point 2.

The only issue with spiders is that they might find a random cache somewhere where the URL was linked and index this in a way that is easier to find for others. Random guessing is indeed not a problem.

Answer 5

I've personally used HTTPS-with-unguessable-URL as a protocol for delivering files securely. With browser history turned off at the receiving side, and if the URL is communicated as securely as a password would be, this is pretty much as secure as an HTTPS login page. Which is much less secure than, e.g., GnuPG.

Answer 6

Like others have said if you plan on leaving this directory and website up for a day or two with confidential information and data and you are in a serious time crunch then this would be ok but not "best practice". In other words its not recommended but if you feel you need to take the chance.

The main issue with this concept is what if the client has a rootkit or key logger on his or her machine? What if another party obtains the link? What I'm saying is anyone who obtains this link will be able to access this confidential data. I would put a quick login on the page to only allow access to the clients that data is for.