PeopleDAO “exploited” by Google Docs edit • Hacker News Board

Re: PeopleDAO “exploited” by Google Docs edit

#81

Post by matt_langston » Mon, Mar 13, 2023, 9:58 AM UTC

UncleMeat wrote: post #13

Hilarious. DAO stands for "decentralized autonomous organization." This thing appears to collect transactions via a centralized google form and then complete those transactions if 5 of 9 people vote to perform them. Neither decentralized nor autonomous. You go through all this effort to establish something fancy using whatever hot defi thing exists but situate it on top of a google form and a spreadsheet just owned b…

PeopleDAO is not a DAO. Calling an organization a DAO does not make it a DAO. An actual DAO cannot hold title to property, meaning it is impossible to steal anything from a DAO.

PeopleDAO held title to property (in the form of Ethereum tokens that were allegedly stolen), making it a club of sorts, but not a DAO.

Re: PeopleDAO “exploited” by Google Docs edit

#82

Post by BobbyJo » Mon, Mar 13, 2023, 12:52 PM UTC

shkkmo wrote: post #55

BobbyJo wrote: post #25

Earlier quoted context omitted.

> 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'…

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/{secureTo…

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.

Re: PeopleDAO “exploited” by Google Docs edit

#83

Post by shkkmo » Mon, Mar 13, 2023, 8:17 PM UTC

BobbyJo wrote: post #82

shkkmo wrote: post #55

Earlier quoted context omitted.

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/{secureTo…

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…

> 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.

Re: PeopleDAO “exploited” by Google Docs edit

#84

Post by NoZebra120vClip » Mon, Mar 13, 2023, 10:28 PM UTC

shkkmo wrote: post #83

BobbyJo wrote: post #82

Earlier quoted context omitted.

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…

> 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 determi…

> 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 is, when you boil it down, world-writable, no excuses, no ifs-ands-or-buts.

Re: PeopleDAO “exploited” by Google Docs edit

#85

Post by BobbyJo » Tue, Mar 14, 2023, 1:16 PM UTC

shkkmo wrote: post #83

BobbyJo wrote: post #82

Earlier quoted context omitted.

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…

> 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 determi…

> passwords and authorizing-links can have identical functional forms

No they can't. Passwords are specifically intended not to be shared. Links are specifically intended to be shared.

A shared secret is far less secure than one that is not shared, whether the cryptographic backing is the same or not.

Re: PeopleDAO “exploited” by Google Docs edit

#86

Post by shkkmo » Tue, Mar 14, 2023, 2:11 PM UTC

NoZebra120vClip wrote: post #84

shkkmo wrote: post #83

Earlier quoted context omitted.

> 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 determi…

> 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 c…

> Arguably, Unix pathnames are more discoverable than arbitrary Docs links. But the idea is the same, isn't it?

The discoverability is a pretty key difference. If google had a feature that allowed you to enumerate all edit links in their system, then those links would effectively br world writeable.

> 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).

If that was true, the link would just use a document ID, the use of a cryptographic hash does imply some intention that these files won't simply be world writeable and that access is intended to be controlled by sharing of the link.

In the specific case, the people using the feature failed to do either. They didn't treat the file as world writeable and they didn't treat the link like a secret. If they had done either, that would have helped.

Re: PeopleDAO “exploited” by Google Docs edit

#87

Post by shkkmo » Tue, Mar 14, 2023, 2:31 PM UTC

BobbyJo wrote: post #85

shkkmo wrote: post #83

Earlier quoted context omitted.

> 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 determi…

> passwords and authorizing-links can have identical functional forms No they can't. Passwords are specifically intended not to be shared. Links are specifically intended to be shared. A shared secret is far less secure than one that is not shared, whether the cryptographic backing is the same or not.

Passwords are as equally sharable as links, there is no functional difference in form there.

In practice, passwords, api keys and other secrets are frequently shared. Many of them, such as some api keys, are clearly intended to be shared between multiple people.

You are correct that sharing these secrets, and the method of sharing can create security vulnerabilities. There is the frequent issue of people accidentally commiting api keys to publix repositories. There are also plenty of stories of people at a company sharing a password to a single account sometimes because the service doesn't provide support for multiple users.

> Links are specifically intended to be shared.

There are many urls that are not intended to be shared because they are viewable by a single account and theoretically a single user.

To make this clear, urls are frequently used in a very similar way to passwords. Oer example that makes this exceedingly obvious is password reset links.

A separate discussion is when it is a good practice to put secrets in URLs. API best practices discourage this and for good reason. That doesn't mean that urls can't be secrets, just that doing that can create additional risks due the expectations the users and systems have about risks.

These risks are why password reset links are usually time limited and restricted to a single use.