I never leave backdoors in my system, but out of curiosity I was wondering if I left a secret URL like /x52d23r that allowed to bypass some sort of security, and this was only for my personal use---would that be somehow discovered by a third party without getting the information from me?
For example, secret ports can be port scanned and fingerprinted, but can the same sort of tactic be done for secret URLs?
The reason using a "secret URL" is usually insecure is not because it is "security through obscurity". In information theory, a secret URL is no different than a password or private key. Are passwords and private keys considered a poor practice because they are "security through obscurity"? No.
So what's the difference between a hard-to-guess URL and a hard-to-guess password?
The difference is in the myriad of insecure places and ways that URLs are stored, displayed, and transmitted. Examples:
HTTPS can protect some of these, but not all of them (items marked with a * are not protected against by using HTTPS.)
In a highly controlled environment, hard-to-guess URLs can be secure. But when using common web browsers, web servers and web frameworks, hard-to-guess URLs should not be relied upon unless no other option exists (and even then you should consider carefully).
Original Answer: Security through obscurity is something that should never be practiced.
I'd like to expand on this, as I see some argument is still being made that a secret URL is no different than a password. I would highly disagree with that comparison. A secret URL and a password do share one similar characteristic: they are known to one or more specific person/people. That is where the similarity ends.
Strength of Passwords
Making a password out of a series of random words makes the password very strong and very hard to guess or brute force.
A password has to be coupled with a user name, which also can increase security if the user name is not common.
User name and password combinations are not statically shown on the screen, nor stored anywhere in the browser (unless you chose to have your browser "save" your login credentials).
Passwords can be changed in the case of a breach without the need to change the entry-point into the system.
Good password systems don't store them in plain-text on the filesystem.
Weakness of Secret URL
Unless used in "Incognito", "Private", etc. mode, the URL will be stored in your local history/cache.
URLs are shown in the browser window and can be privy to wandering eyes.
If the secret URL is compromised, you have to change it and notify anyone using it.
The URL exists in plain text on the server somewhere, whether as real directory/files or as a rewrite (however, a rewrite could be down at a much higher level).
Everything else that @Mike Clark has mentioned in his answer.
What it really comes down to:
Secret URLs are only practicing security through obscurity. That's it.
Passwords may be obscured information by definition, but the extra efforts, precautions, and safeguards taken around passwords adds a level of security on top of it all. In other words, passwords are layered and are practicing security through other means in addition to obscurity. This, in turn, makes them a better choice than a simple obscured URL.
Recommendation: Use both a "secret" URL and a very strong user name/password combination. Don't rely on JUST a "secret" URL.
Never practice security using obscurity as the only safeguard.
I'd say if you're careful they can be secure. The biggest security hole would be the people using it. It will be unintentionally shared or posted somewhere Google will index it. Design for that, and use it appropriately - like the Google docs "Anyone with this link" sharing method.
Stops the URL being sent in plaintext
Doesn't set referrer headers if they click a HTTP link
If people access your secret URL via HTTP, warn them and immediately change it
It's not security through obscurity - that's a misunderstanding of the normal use of the phrase.
"A system relying on security through obscurity may have theoretical or actual security vulnerabilities, but its owners or designers believe that the flaws are not known, and that attackers are unlikely to find them."
In contrast here you're being open about implementation and design.
I don't see that this is less secure than the average password when used with a long secret URL (64 characters anyone? 2000 - domain_length?), in combination with a tar-pit.
I'm planning to use it in an app where I feel people will value simplicity above security.
It's not secure.
For HTTP traffic your secret URL would effectively be public as soon as you use it. Without any password protection an eavesdropper listening to your network traffic could see the URL you send and then visit the same page.
Not good idea because:
The Waterken web server is a web platform designed by the security folk at HP research around secret (specifically cryptographically unguessable) URLs.
Applications built on it have some very interesting security properties as a result.
Done right, cryptographically strong secret URLs can provide high levels of security.
ACLs Don't is a paper from the waterken team on their security architecture.
Comparing the suggested defense to the capability based solution for the compilation scenario, and again assuming a Unix-like system: the URL is like the filename; and the unguessable token is like a file descriptor, approximating the unforgeability of a capability with unguessability. A legitimate page from the stock broker’s Web site first opens the stock purchase resource, receiving an unguessable secret. The browser then uses this unguessable secret to write to the stock purchase resource.
this is actually a pretty reasonable idea IF you use a large, and randomly generated url. there are many systems that actually work like this already. for example, in google docs, you can create a link that anyone with that link can edit the document. It's long enough that you could never feasibly guess that link. Also, password reset links are basically this, except they are (hopefully) only usable once. (see below)
You'll need to ensure that the secret is not leaked. That means using https, not logging accesses, or returning the secret in other api calls.
That said, as many above commenters mention, a URL is stored all sorts of insecure places on your computer, but if an adversary has access to your computer you are already screwed. It's pretty typical to assume that your end user device is secure.
Also, any secret is only secret inversely proportional to how many people know it. It may be tempting to share a url with other people who require access. A much better system might be to make each URL work once, but add a cookie to the user's browser, which is the actual token. Basically, just like a password reset flow/email confirm flow, except without passwords.
Guessing an ascii hex string corresponding to 16 bytes presents a challenge of guessing a 128 bit AES key - which is considered impossible.
would that be somehow discovered by a third party without getting the information from me? For example, secret ports can be port scanned and fingerprinted, but can the same sort of tactic be done for secret URLs?
Yes. You are thinking of the threat as a human being sitting at a computer typing the URL into their browser. The reality is that attackers use automated programs that perform reconnaissance on systems and use that information to attempt a variety of attacks. Trying random URLs has little cost for an automated system than can produce hundreds of HTTP requests per second. Second as others have noted, once you use the URL it is no longer secret. Those automated programs listen to internet traffic and collect URLs to attempt attacks on. The fact that only you know the URL means that no other person can divulge its value. It does not prevent technical means from divulging the value.
