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.

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:


The user must be trapped or forced into revealing the password
The server must be hacked into so that it reveals a hashed version of the password
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.
