22

I know that this question is a little bit on the side of Opinion/Discussion, but I think there's a provable answer to it.

I think the common view of "Security Through Obscurity" is that the security will only hold up as long as an attacker cannot guess the way in.

In environments where massive attacks or common attack vectors are known, this is often much simpler than many people believe.

However, I think a large number of people do not classify requiring a username/password combo as requiring as a version of "Security through obscurity"

My question is this:

What (security) difference (if any) is there between the following two urls with respect to security (please note caveats listed below):

Prototypical URLs:

  • [encrypted scheme/protocol SSL]://[user]:[password]@[domain]
  • [encrypted scheme/protocol SSL]://[domain]/[user][password]

Examples:

Caveats:

  1. Assume that these urls are being accessed by a low-level HTTP client, NOT a web browser. (i.e. the client is not keeping a record of requests, and is trusted -- I know that low-level != "trusted", but I'd like to factor our browser caching as a difference in this question).
  2. I know that there are known ways to "predict" GUIDs that might have been generated if you have sufficient knowledge of the guid's source machine, and the time (and probably other factors). I do not know if you can extract this information from a sample guid. Assume that Guids are generally not predictable.
  3. Even though I've already attempted to address this with 1, let me be clear: Humans never directly interact with these URLs (or even see them without digging into a compiled application)

Is the second URL form an example of Security Through Obscurity? Or simply less secure because of the fewer protections afforded by the client?

Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179
Andrew Theken
  • 329
  • 2
  • 6

5 Answers5

10

I'll try to answer the question itself without lecturing you on what to use and what not to use.

Taking your assumptions into account (which are quite daring assumptions, IMO)

  • SSL is used.
  • No logging anywhere.
  • The GUIDs aren't easily predictable.
  • The password is strong.

Then no, this is not security by obscurity. This is security by, well.., security. Your security depends on the attacker's inability to guess/know the password, and not on the the attacker's inability to guess/know how your system works. Your password is, in some way, your key. As long as your security depends on your key, you're alright.

Now, I'm afraid you're attempting something like storing directories on your server with those GUIDs and passwords and then link to the resources inside those directories. In that case, absolutely not! Don't do it! Passwords aren't supposed to be treated that way.

Adi
  • 43,808
  • 16
  • 135
  • 167
  • I have a specific use case in mind, but it's fairly esoteric. It'd be better to think of it this way, I have N resources, each with a Guid ID. If you know the resource guid, you can read it. It's basically low-value data, and not personally identifiable (except that it's associated to a specific device - via another guid not in the uri). In a sense, you can think of the resource id as a password for that resource. Also, IN THIS SPECIFIC CASE, the client an iOS app. In this case, any data that could be compromised with knowledge of the resource URIs, already exists on the device. – Andrew Theken Jun 03 '13 at 19:56
10

Security through obscurity means violating Kerckhoffs's principle, which can be summarized this way: assume all cleverness is public and keep the randomness private.

This means that your security must not be hurt by making your protocol public. On the other hand, keeping a password private is the whole point of a password.

You should be able to quantify how much knowledge the attacker is missing. That's impossible with a protocol, you can't measure how hard it is for the attacker to figure it out. That's eminently possible for a password: it's the entropy that went into generating it.

A scheme whose security depends on the secrecy of a password is never secrecy by obscurity. The generation of the password can be security by obscurity (if the password is chosen to be clever instead of random), but the use of the password isn't.

The choice between your two proposals depends solely on what the client and server will do with the URL. Note that by client and server, I mean everything on either side of the SSL connection; if you have a server front-end that decodes the HTTPS request and forwards it to a back-end, they're both part of the server.

Including a secret inside an URL outside the password field (and sometimes even in the password field) is usually bad because the URL can end up in many logs, both on the client side (browser history) and on the server side. If the request comes from your application as opposed to through a browser, that's one side safe. You need to take a careful look at the server side, both the way it is now and the way it may evolve in the future. Are there any logs? What information do they include? How are the logs protected? Where are they backed up?

Regarding the use of GUIDs: while some Windows APIs provide “kinda-random-but-actually-predictable” GUIDs, there is little reason to use them. Stick to random (version 4) UUIDs, using a good random number generator with suitable entropy. If you don't have a suitable library function, generate 128 random bits, and if you need RFC-compliant UUIDs then apply the mask uuid[6] = (uuid[6] & 0x0f) | 0x40; uuid[8] = (uuid[8] & 0x3f ) | 0x80;.

Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179
4

Let's see if we can break this down:

  1. You're using SSL which is good. SSL encrypts all the data you send including the URL. However SSL only protects the data while it is in transit. Meaning on both the server and the client end the data may be readable.
  2. If you have a security token (username/password, randomly generated key, or whatever) and you transmit it securely (ie. SSL, see point 1) then for someone trying to intercept the data it will make no difference where in the encrypted data block it is stored. They can't see it.
  3. You need to fully understand how the server handles the (now decrypted) data it receives. As the other answers mentioned a typical http server will log the URLs it receives. This and anything else the server does with the URL becomes a source of potential data leakage.
  4. You also need to fully understand how the client (and any OS libraries it uses) works, to ensure that it does not leak your security token (no matter where you store it in your data). Whether or not the client is a browser is largely irrelevant to your question
  5. You can't really trust the client. If the client knows the security token, then assume the user does too. This isn't generally a problem with a regular user name and password but if you're using one key shared among several users you can't easily revoke access.

In short you need to know where (and in what state) the data is at all times. Both while in transit and while at rest. If you understand that you can then decide which risks you want to worry about or may need further mitigation.

Your basic premiss of passing a security token in the URL over HTTPS is not security through obscurity. However, it still may not be a great idea, and there are likely better ways of doing what you want to do.

Based on one of your comments it sounds like you're creating a URL such that knowing the URL to one piece of data doesn't make the url to other parts of the data guessable (any longish random key would work). Depending on what your overall goals are this may be suitable (I've worked with software that does this), but I would not consider this the same as a password.

matthew
  • 1,090
  • 1
  • 7
  • 10
1

The former format <user>:<password>@<host> is deprecated and is not supported by all major browsers, so don’t use it. However, browsers which do support it convert such a HTTP URI to a request with HTTP Basic Authentication.

So your question should rather be about HTTP Basic Authentication and URI parameters via HTTPS. And the main disadvantage of the latter is that the requested URL may pop up at several locations, i.e., the web server’s log files, the browser history, HTTP referrer, etc., which can result in a disclosure of the used credentials. So, again, don’t do that.

Instead, use HTTP Basic or Digest Authentication, or some other proven authentication scheme.

Community
  • 1
Gumbo
  • 2,003
  • 1
  • 13
  • 17
  • My question specifically says we should assume that we're not using a browser. All of the protections granted by a browser with respect to that URI form, I don't believe are related to the underlying question of whether one is intrinsically safer than the other if you're not using a browser. I'll edit the question so this is more clear. – Andrew Theken Jun 03 '13 at 17:55
  • @AndrewTheken How does the aspect of logging requested URLs be not relevant? – Gumbo Jun 03 '13 at 17:57
  • Because I'm using an OS provided http client, not a browser, AFAIK, the OS does not log these types of HTTP requests -- even if it does, this would be the same vulnerability in both cases. – Andrew Theken Jun 03 '13 at 18:02
  • 2
    @AndrewTheken The *server* normally logs any request in some kind of access log, including the requested URI path and query string. – Gumbo Jun 03 '13 at 18:03
  • I guess my point here is that if you exclude all of the built in protections that are related to *where* in the URI the u/p is located, is one intrinsically more obscure or safe than the other, it seems like no. I agree that including them in the "right" part of the request is a best practice, but it's not because the form itself is harder to guess. – Andrew Theken Jun 03 '13 at 18:06
0

The username / password URL scheme has a chance of encrypting those values for transmission whereas the regular get request does not. However you do show HTTPS scheme there so I don't see any problem.

One flaw is maybe a user would want to bookmark one of his URLs, which could be left unprotected and thus be grabbed by someone. The first scheme allows a bookmark without the username/password combo. Just a thought.

Your second scheme seems similar to submitting login credentials on a form using GET instead of POST. No one really does it. Is it less secure? Maybe, but there are no concrete reasons why that is so. People just prefer POST because its more "hidden" in the HTTP transaction.

A final thought, its good to follow standard practises. Security by obscurity is great against a broad attack but a focused attack you will be toast. Best practises have a chance of protecting you against outside factors not related to the HTTP protocol such as social engineering to capture usernames and passwords. Focus on security should not every be too narrow.

  • Yes, the question specifically says to assume we're not using a web browser, but rather some trusted low-level http client. –  Jun 03 '13 at 17:22