19

Most (if not all) of us know that a Google Doc link looks something like this: https://docs.google.com/document/d/13P3p5bA3lslqEJT1BGeTL1L5ZrQq_fSov_56jT9vf0I/edit

There are becoming several tools (like Trello) that allow you to "attach" a document from your Google Drive. When you attach a document, you have to manually go in and add people to the document - or say that anyone with a link can edit, view, or comment.

From a security standpoint, how risky is just saying that everyone can edit? What is the likelihood that someone could brute force guess your Google Doc link, and thus gain access to your document?

My guess here is that there are a lot easier avenues (e.g. guessing someone's Trello PW, rubber hose decryption) to gain access to whatever information the attacker was looking for, mainly on the obvious fact that there are a lot of characters there, plus the assumption that Google probably keeps an eye out for that sort of sneaky behavior...

But let's say that you were able to brute force the links - what are the vulnerabilities with this approach?

  • That people steal your documents? – Lucas Kauffman Jan 21 '13 at 17:47
  • Apparently I worded that wrong >.< I guess what I'm really wanting to know is what the complexity of that attack would be, or if the attacker would be sitting around for a while - even with a "load" of machines guessing links. – Wayne Werner Jan 21 '13 at 17:53
  • Does anyone know? -- if it's an "open" document will Google index it for their search engine? – Safado Jan 21 '13 at 21:11
  • 1
    Be careful how you share secret links. Facebook carelessly published every URL sent over Facebook chat, including secret Google Docs links. They fixed it eventually, after initially denying it was a problem. See hackernoon.com/… – Colonel Panic Oct 14 '16 at 10:45
  • I'm not going to answer the question really but I want to point out something. when you share a link with someone, you cant prevent them from sharing it with others, you can't also track who is doing what on the sheet, and finally you can't revoke access, I guess what I'm trying to say, if this is a common practice in a company and someone leaves the company and you want to deny that person access, well, you can't also if someone in your company decided to share that link with the competition, very possible with no trace back to that person, hope that helps. – gmansour Apr 16 '18 at 17:33
17

Assuming the document ID distribution is uniform and unpredictable, here's the math:

  • 44 characters long
  • Uppercase, lowercase, digits and underscore =
    26 + 26 + 10 + 1 = 63 character alphabet

Therefore:
Total possible combinations: 6344
keyspace: 263 bits ⇐ 44 * log2(63)

And we know that brute-forcing a 263-bit key in any reasonable amount of time (lifetime of the universe) is well beyond what the laws of physics will allow, no matter how advanced and magical and "quantum" the computers may become.

This may seem a bit bold an assertion, but it comes from the fact that the sun simply doesn't put out enough energy in such a timeframe to count that high. See page 157 of Schneier's Applied Cryptography for the details, or look at this answer here where I summarized the math, or this answer where lynks quoted the entire section from Schneier's book.

Specifically, the sun's energy is only sufficient to count to 2187 per year, meaning it will take 276 years with our own sun, 275 years if we could harness 2 suns, etc. You might barely have enough power to count to 2256 if you were to power your computer with the supernova destruction of every star in the Milky Way Galaxy. So that's getting somewhere.

  • 3
    In this case you can't even run an offline search. You need to query google's servers that often, which makes is even more ridiculous. – CodesInChaos Jan 21 '13 at 21:16
  • @CodesInChaos as if building a Dyson sphere around the sun to power an ideal computer sitting in deep space isn't ridiculous enough... – tylerl Jan 21 '13 at 21:21
  • So a rubber hose is much more likely. I guess if I see someone building a Dyson sphere around the sun it's probably too late to worry about the guys with the rubber hose, though. – Wayne Werner Jan 21 '13 at 21:52
  • While I like your math, let me point out that you're overlooking the fact that the keyspace probably isn't a full 263 bits wide. Whatever generator they use probably has at least a few rules to limit out stuff like a key of 11111...111; also, while brute-forcing a single, specific document is expensive, what you have to deal with is the possibility -- still remote -- of them randomly querying that link. (This is of course nitpicking; your point is completely valid) – RonLugge Jan 28 '13 at 5:48
  • @RonLugge The effect of such rules may affect the numbers to several orders of magnitude, but it wouldn't affect the outcome. As for accidental stumbles; say each person on earth had 1 million documents on GA. That's what, 2^53 documents? So let's be generously inaccurate with our math and say that any guess has a 1 in 2^200 chance of accidentally stumbling on a real document. So if all he computers in the world do nothing but enumerate document links for the rest of eternity, the chances of a single hit are still indistinguishable from zero. – tylerl Jan 28 '13 at 6:25
6

While it still may take a very large time to bruteforce (close to infinity), it is not really smart to keep confidential documents protected that way. If you don't care who reads it then it doesn't matter. But I wouldn't put the specifications of your latest project on Google Docs.

You are also risking the fact that the links may leak, when authentication is needed you can still prevent people from accessing your file. If, however, authentication is not forced, anyone that can get its hands on the link, can view the document.

  • 4
    And not forgetting the link hanging around in someone's browser history – Andy Smith Jan 21 '13 at 18:16
  • 2
    Using a secret url is not security through obscurity if the url has sufficient entropy (And this one has around 256 bits). It's a viable form of authentication, even if there are certain associated risks. – CodesInChaos Jan 21 '13 at 19:39
  • 2
    It's not a valid form of authentication because the risk of someone leaking the url is higher than leaking their own credentials to log into the application. Authentication also requires proof of identity, while this does not provide that. – Lucas Kauffman Jan 21 '13 at 20:24
  • 1
    Plus I clearly stated that the guessing speed is very improbable, so please elaborate on why you insist to downvote my answer. – Lucas Kauffman Jan 21 '13 at 20:27
2

I'd be more likely to try and make sure all my users had google logins and had permissions on the document folder - there's shades of grey between "wide open" and "add each permission individually".

Apocryphally I have seen "patterns" in docs links - so I remain unconvinced about the level of security provided, though I would not like to try and break in myself!

Also, be aware of "link lying around" attacks - someone mentioned browsers remembering it, there's also caches, web proxy logs, url shorteners, search engines, email forwarding... al sorts of dubious ways the link could spread, likely to people who may find it "useful".

Worse, using the "all open" method, you don't know if someone's poking about, and if they do, applying more security after the fact will suck doublehard.

1

I put it through a password complexity tester at http://howsecureismypassword.net/ and the result was "It would take a desktop PC about 802 vigintillion years to crack your password". (That seems to be a pretty long time).

That, of course, assumes a random password, which isn't likely the case here. There is almost certainly an algorithm creating these document ID's and if the algorithm can be guessed, that certainly ups the odds that someone can guess the ID's.

Also, no "password strength" tool is perfect. That time is a guess by one system that likely makes assumptions that may or may not be valid. The point of posting it was just as a baseline "Not knowing anything else, how hard would it be to brute-force this?"

But in and of itself, guessing the ID of a particular ID associated with a particular account would be exceedingly difficult. An attacker would need to be logged in as someone that has access to a specific document, which lowers the risk considerably.

Assuming the permissions portion of Google Docs is solid: Only people that you have granted permissions to view the document actually can access it. From that, it is likely that a logged in user could only brute-force documents that they already have permissions to already.

The complexity of the ID isn't the only security tool, it's a layer of obscurity on top of the already-existing security. It may be security by obscurity in one sense, but it's not the sole factor. Security by obscurity is bad only when it's the only measure of defense. If it adds complexity onto the task there is no harm in it, and it can certainly slow an attacker down. It's just not safe to rely on it as your only defense.

  • I think that estimate is not really good. It probably assumes empy spaces as well, whilst this will probably have a fixed length. It would still take a tremendous amount of guesses though, I agree on that. – Lucas Kauffman Jan 21 '13 at 18:04
  • I don't disagree with that at all. I just used it as a rough estimate based on knowing nothing other than the string of cahracters. As the second paragraph goes on to say, there are other factors to consider. I may be wrong, but I still think that when you combine the complexity of the string and the fact that it has to be something that's accessible to the logged in user, the odds of a successful brute-force is incredibly small. Maybe not 802 vigintillion years small, but certainly not to the point that I'd be overly concerned. – David Stratton Jan 21 '13 at 18:08
  • @LucasKauffman The amount of guesses compares the the amount of guesses you need to break AES-256. i.e. it just does not happen. – CodesInChaos Jan 21 '13 at 19:42
0

Let me add something here as far as the "security level" is concerned. Because the reality of the question comes down to how "safe" am I or "is this secure". The answer is not very safe at all.

What we have to examine is what is the likely hood of this getting compromised. Now explaining this has already been attempted but bare with me. I'm going to try and give a different view.

Is the link encrypted.. kind of but not really. This is security through obscurity not encryption. So the hope is your link is never found out or guessed and that's it... nothing here is encrypted... nothing. Encryption is the act of converting data into something else/other than what it was originally whether scrambling or completely changing/substituting the information. It is definitely hard to just guess this URL no doubt about that, no doubt at all, but this URL is still just a URL and once hit it will return and provides access to your information.

Yeah but no one is every going to guess this in a million billion years... well you hope! The fact is you may never know if or when it does either. Brute force is suffisticated and hashes can be guessed very well it's not like they are going to guess Aaaaaaaaaaaaaaaaaaaa1, Aaaaaaaaaaaaaaaaaaaa2, etc. so many many bad options will be eliminated. they are going to determine what hash is being done and do mathematical legitimate values. They are then able to build a table of all possible values and federate that out to large botnets or tools like AWS lambda etc. where they can try millions of request quickly and it's legitimate traffic to google worldwide.

On top of that your traffic isn't safe much of where you go and what you do bleeds all over the place and others will to. So web analytics/plugins/malware/coffee shops/etc can contain bad code or contain attacks that take your URL and expose it to malicious groups.

The biggest issue being you never know who sees and accesses your files and if you have things in there you do not wish anyone to have access then remove the share link immediately.

I hope this sheds some light on shared links this problem exists for Dropbox or any other share link where credentials are not provided and files are not encrypted or protected at rest.

  • Thanks for taking the time to write a detailed response. I agree with you that obscurity is not encryption and that the long URL is not encryption. I also agree with you that it's a good idea to reduce exposure by removing the link when the job is done. Not so much on the other things. Bruteforcing a long URL is not easy esp., since there is time-cost (when you try each URL, you spend a lot of time waiting for the server to respond). Services like AWS Lambda make it only slightly better. The one threat you probably missed is that of link shorteners - much easier to bruteforce. – Sas3 Aug 23 '17 at 1:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.