6 ms·

> granting any permission at all to "Anyone who has this link" is, in the end, security through obscurity. That's like saying passwords are "security through o

> granting any permission at all to "Anyone who has this link" is, in the end, security through obscurity. That's like saying passwords are "security through obscurity" because they're also "obscure" random strings, just like URLs. To try and make my point more clear: Basic auth password url: https://username:randomSecurePassword@webpage.com https://username:randomSecurePassword@webpage.com Google docs edit url: https://docs.google.com/randomLongString/edit https://docs.google.com/randomLongString/edit How are those two things different, other than one is a password which might be short and insecure, and the other has plenty of entropy? Will you also argue that all shared secrets are security by obscurity?

BobbyJo 4y ago
> How are those two things different How they're used? I mean, we can argue that pizzas are wheels because they're circles, but, until you throw one on a car and get where you're going, no one will take it seriously. URLs get shared, passed around, posted in chats, etc. Passwords don't, or at least everyone knows they're doing something wrong if they do. In the case of the this doc, if it was privately shared, I don't think anyone would have mistakenly posted their Google password the same way.
- shkkmo 4y ago
  Then it sounds like both passwords and gdoc authorization links depend on security through obscurity, but people are less aware of that fact for the links. There is a point here that the difference between access level grants is not clear enough and the urls should have a clearer demarcation of the level granted, (e.g. sheets.google.com/danger-allows-editing/{secureToken} or sheets.google.com/allows-viewing/{secureToken}.)
  - BobbyJo 4y ago
    If you're going to classify passwords as security through obscurity, then how would you accomplish security through any other means? All forms of digital security require information asymmetry (IE someone holding information not known to others). The only other security I can think of is physical, and most of that is designed around information asymmetry as well (key cards, door codes). STO to me generally indicates there is some backward engineering process, or some vital related knowledge, that can break it, which is specifically not the case here. Secrets are specifically designed to have common forms and functions, you only keep the value itself, or values they were derived from, secret. Obscurity and secrecy have slightly different meanings.
    - shkkmo 4y ago
      > If you're going to classify passwords as security through obscurity Sorry if this wasn't clear. I was trying to adopt your apparent definition to point out that, passwords and authorizing-links can have identical functional forms. Both depend on maintaining the secrecy of a specific piece on non-design / non-implementation knowledge. To make this clearer, let's say that your document's authorization link is determined by hashing the document id. If you don't use a salt, then the security of the system depends on the obscurity of your choice of hashing function. If you do use a salt, then your security also depends on the secrecy (and strength) of the salt value. Since the issue in this case wasn't people reverse engineering the means of generating links to uncover it, the issue was not a dependence on obscurity of design and implementation. The issue was that the users of the system were not aware or forgot that authorization links were a secret or confusion about what level of secrecy was needed for a specific link. This is why I specifically called out a possible design change to the authorization links that would reduce the likelihood of similar human error. Edit: In general, "security through obscurity" is both a nebulous term and one that often doesn't mean use of obscurity of design/implementation a portion of the security stance, but rather an over-reliance on obscurity of design/implementation without other security measures, such as the use and careful management of strong secrets such as passwords/keys. This potential confusion makes me view the "security through obscurity" term as more of a buzzword than a specific security criticism.
      - NoZebra120vClip 4y ago
        > Both depend on maintaining the secrecy of a specific piece on non-design / non-implementation knowledge. I would say that Google Workspaces' implementation of "Anyone with the Link" authorization was never intended to depend on secrecy (or obscurity or what have-you). I would say that we'd need to consider a more expansive and open, permissive model than that. "Anyone who has the link can edit this" should not be considered as "hide this URL from anyone you don't want editing it" but rather "This is a world-writable document. Discovery merely depends on getting the link right." Imagine if this were a massively multiuser Unix system and not the WWW. Your admin creates for you an obscure, long pathname ending in a long base64 filename. It is mode 6777. "Anyone with the pathname" can edit it! Now is the pathname like a password, or is it just a pathname sitting there in the system? Arguably, Unix pathnames are more discoverable than arbitrary Docs links. But the idea is the same, isn't it? A Google Doc/Sheet/Slide/Drive whose permission is "Anyone with the link" may <X> is, when you boil it down, world-writable, no excuses, no ifs-ands-or-buts.
throwaway290 4y ago
This is about Google docs. In Google docs access control means not just knowing password and username combo, it also means having the device to receive a time limited 2FA code etc. Plus the ability to revoke access. Very much not just obscurity.
- NoZebra120vClip 4y ago
  Hi, let me introduce you to "Anyone with the link can edit".
IanCal 4y ago
If people are sharing the links including the basic auth embedded, not much. However it splits the problem into two halves. One part deals with auth, one part deals with the identity of the resource. So you can have different auth, or change the auth, without changing the URL. In practice, the most important difference between those is about what gets copied when someone shares a link. If the only possible option is to share it with the authentication embedded, you're kind of screwed. I don't think browsers expose the basic auth when you copy and paste from your url bar though.

BobbyJo 4y ago

> How are those two things different How they're used? I mean, we can argue that pizzas are wheels because they're circles, but, until you throw one on a car and get where you're going, no one will take it seriously. URLs get shared, passed around, posted in chats, etc. Passwords don't, or at least everyone knows they're doing something wrong if they do. In the case of the this doc, if it was privately shared, I don't think anyone would have mistakenly posted their Google password the same way.

shkkmo 4y ago
Then it sounds like both passwords and gdoc authorization links depend on security through obscurity, but people are less aware of that fact for the links. There is a point here that the difference between access level grants is not clear enough and the urls should have a clearer demarcation of the level granted, (e.g. sheets.google.com/danger-allows-editing/{secureToken} or sheets.google.com/allows-viewing/{secureToken}.)
- BobbyJo 4y ago
  If you're going to classify passwords as security through obscurity, then how would you accomplish security through any other means? All forms of digital security require information asymmetry (IE someone holding information not known to others). The only other security I can think of is physical, and most of that is designed around information asymmetry as well (key cards, door codes). STO to me generally indicates there is some backward engineering process, or some vital related knowledge, that can break it, which is specifically not the case here. Secrets are specifically designed to have common forms and functions, you only keep the value itself, or values they were derived from, secret. Obscurity and secrecy have slightly different meanings.
  - shkkmo 4y ago
    > If you're going to classify passwords as security through obscurity Sorry if this wasn't clear. I was trying to adopt your apparent definition to point out that, passwords and authorizing-links can have identical functional forms. Both depend on maintaining the secrecy of a specific piece on non-design / non-implementation knowledge. To make this clearer, let's say that your document's authorization link is determined by hashing the document id. If you don't use a salt, then the security of the system depends on the obscurity of your choice of hashing function. If you do use a salt, then your security also depends on the secrecy (and strength) of the salt value. Since the issue in this case wasn't people reverse engineering the means of generating links to uncover it, the issue was not a dependence on obscurity of design and implementation. The issue was that the users of the system were not aware or forgot that authorization links were a secret or confusion about what level of secrecy was needed for a specific link. This is why I specifically called out a possible design change to the authorization links that would reduce the likelihood of similar human error. Edit: In general, "security through obscurity" is both a nebulous term and one that often doesn't mean use of obscurity of design/implementation a portion of the security stance, but rather an over-reliance on obscurity of design/implementation without other security measures, such as the use and careful management of strong secrets such as passwords/keys. This potential confusion makes me view the "security through obscurity" term as more of a buzzword than a specific security criticism.
    - NoZebra120vClip 4y ago
      > Both depend on maintaining the secrecy of a specific piece on non-design / non-implementation knowledge. I would say that Google Workspaces' implementation of "Anyone with the Link" authorization was never intended to depend on secrecy (or obscurity or what have-you). I would say that we'd need to consider a more expansive and open, permissive model than that. "Anyone who has the link can edit this" should not be considered as "hide this URL from anyone you don't want editing it" but rather "This is a world-writable document. Discovery merely depends on getting the link right." Imagine if this were a massively multiuser Unix system and not the WWW. Your admin creates for you an obscure, long pathname ending in a long base64 filename. It is mode 6777. "Anyone with the pathname" can edit it! Now is the pathname like a password, or is it just a pathname sitting there in the system? Arguably, Unix pathnames are more discoverable than arbitrary Docs links. But the idea is the same, isn't it? A Google Doc/Sheet/Slide/Drive whose permission is "Anyone with the link" may <X> is, when you boil it down, world-writable, no excuses, no ifs-ands-or-buts.

throwaway290 4y ago

This is about Google docs. In Google docs access control means not just knowing password and username combo, it also means having the device to receive a time limited 2FA code etc. Plus the ability to revoke access. Very much not just obscurity.

NoZebra120vClip 4y ago
Hi, let me introduce you to "Anyone with the link can edit".

IanCal 4y ago

If people are sharing the links including the basic auth embedded, not much. However it splits the problem into two halves. One part deals with auth, one part deals with the identity of the resource. So you can have different auth, or change the auth, without changing the URL. In practice, the most important difference between those is about what gets copied when someone shares a link. If the only possible option is to share it with the authentication embedded, you're kind of screwed. I don't think browsers expose the basic auth when you copy and paste from your url bar though.