I saw someone's interesting practice to store sensitive information.

He is saving all his thousand logins (including banks and email) in a access-restricted Google spread sheet, stored on his Google drive.

The link to the document is shortened using some URL-shortener and he uses that simple-to-remember link to open the document every time he needs a specific password or an account number.

His argument is that the practice is secure enough because:

  1. The document is on his personal Google drive protected by Google, as for the external attacks. So the location is more secure than e.g. his PC.

  2. The access to document needs google login, which is 2-way secured. P.S. (I mean 2-step verification of google)

  3. The URL to that document is not known to anyone else except himself, his browser, and the shortener service, all of whom cannot access the document without login details. Rest of the world doesn't know the location/URL.

  4. He opens the document only on his PC, laptop, and mobile.

The information in such a document is everything that someone needs to impersonate him and I don't think this method is so foolproof.

Can some one justify technically, how secure this practice is? Can you suggest an alternative as easy as typing a URL everytime he needs to recall a password?

P.S. I am impresed at first sight, with these two professional utilities (password managers) dedicated for this purpose, came to know from the answers below: KeePass and Lastpass (any others?)

While both seem to be cost-free, first is preferable to me for being open-source -- I am going to give it a try.

Mentioning efficient alternatives (esp. as easy as a short-URL above) like this will be the most important take-away from this post. For me, in spite of having heard about password managers many times, I never really focused on them.

  • 10
    By "2-way secured", do you mean he has two-factor authentication configured?
    – user81469
    Commented Nov 14, 2016 at 9:09
  • 37
    ... that's a homebrewn password manager, with the catch that the passwords are not encrypted, just hard to access. For example: a malicious Google employee would be able to impersonate him without problem... If he used a proper password manager this would not happen.
    – Bakuriu
    Commented Nov 14, 2016 at 19:04
  • 14
    @Bakuriu If he used LastPass a malicious LastPass employee could push out an update which would send him the passwords probably more easily than a malicious Google employee could access user data at this point (years and years ago Google had once a problem with employees having access to user data, and from what I heard about it they cracked down on it incredibly hard). In the end the truth is simply that you always have to trust certain software and developers, the question is just how much trust you need to put in them. Commented Nov 15, 2016 at 13:41
  • 28
    What can possibly be wrong with storing all your passwords in the cache of every browser you use? Commented Nov 15, 2016 at 17:24
  • 7
    Don't trust Google. If Google deletes the spreadsheet or deletes his account, that is lost. Since he needs to use his computer to view the file, hacking into his computer will also give a hacker access to it. A real spreadsheet under his pillow is better. Since he needs to remember a passphrase, he can let the world see the file encrypted with that passphrase if it's secure enough.
    – v7d8dpo4
    Commented Nov 15, 2016 at 17:31

12 Answers 12


A threat to beware of is updates to google drive/google docs. For example they add a feature to auto-cache frequently-used files and all of a sudden it's all on the phone in plaintext. In fact it might already be there. Or the user installs the google drive app with default options for an unrelated reason. The big web-app firms are concerned with convenience and features, less so about security in ths sense (2FA is one thing, but once the data is in your hand it's your problem).

  • 3
    Or the user installs some third-party app that requests access to Google Drive (mobile apps often do this) and now that app developer (and any malicious attackers) have unfettered access to the entire contents of the drive. :-(
    – Simon East
    Commented Apr 19, 2018 at 21:56

When thinking about security, you must be able to say:

  • what threat you want to address
  • what attacker you want to be protected from

and then review the possible weaknesses.

A restricted access file on a well configured Google drive is correctly protected from all attacks from the guy next door. As you say that the Google account is 2 ways secured (what do you mean exactly?) a guy that cannot guess how to login cannot access the file... provided you are fully confident in Google!

And here come the weaknesses...

  • as the file has only restricted access, any Google employee with admin privileges can read it - do you know how many of them exist?
  • Google is a firm well-known for technical excellence, so the risk that it is hacked is reasonably low. But what if a fired employee decides to make public files from Google drives as a revenge, simply because it would be bad for Google's reputation?
  • because of the Patriot Act, US law inforcement agencies can access any data from US companies, and Google is one. Whether it is or not a problem is up to you.

For that reason, I would never store passwords in a non securely encrypted file. Google drive is certainly a correct repository, but I would rather use a Keypass file there - can be synchronized from any device - than a mere spreadsheet.

  • 21
    I would also add that Google is an US company, subject to US laws, and can be required to divulgue information to law enforcement agencies. This can be significant in some cases.
    – Najkin
    Commented Nov 14, 2016 at 10:23
  • @Riokmij: I cannot imagine that the US government could try to use my bank account... Anyway, my bank would give all my banking informations (except for the password itself) in case of legal inquiry. But I agree with you, it can matter in some use cases. I've edited my post with that. Commented Nov 14, 2016 at 10:35
  • 2
    I would add to the weaknesses: its weak to (1) someone standing over your shoulder and reading your screen and (2) someone using your computer while you are logged on and in the bathroom. If you use a proper password manager you are not as vulnerable to either. Commented Nov 14, 2016 at 16:27
  • 8
    @Abdul I use keepass with a strong password but keep the file in my Dropbox. The password for that is less good but still reasonable. So if Dropbox have to give up my files they're still under independent encryption. I don't have to fully trust any single company that way, but more importantly I have the benefit of offline access.
    – Chris H
    Commented Nov 14, 2016 at 19:50
  • 1
    @jpaugh: I could not find how to tell it in english. What I mean is that Google is know as a company with good technical skill, or good technical reputation. I am more confident in Google than in Facebook to use the proper technical tools to secure the data entrusted to them, and with a correct configuration. Do you know how I could say it better? Commented Nov 14, 2016 at 22:08
  1. The document is on his personal Google drive protected by Google, as for the external attacks. So the location is more secure than e.g. his PC.
  2. The access to document needs google login, which is 2-way secured.

That is fine if you trust Google, including the many Google employees with admin privileges, you believe Google can't be hacked, AND the government requiring your data is not one of your concerns. I would say it's hard to say it is more secure than a PC, if you put any effort on protecting the PC.

  1. The URL to that document is not known to anyone else except himself, his browser, and the shortener service, all of whom cannot access the document without login details. Rest of the world doesn't know the location/URL.
  2. He opens the document only on his PC, laptop, and mobile.

That's security by obscurity, and is not good advice at all. One should not consider this kind of thing as adding any security. This data leaks in so many ways, like browser history and maybe even on proxies.

Let me add one more thing. If he by any chance allows an app to have access to his Google drive using Google API, he may expose this file. I've seen many apps that require full access to Google Drive API to work.

Having that all said, I don't see why one would prefer trusting Google spreadsheet for this, instead of specialized security storage cloud providers, as Lastpass, that are focused on protecting this kind of data and add so many extra security measures (that to not mention that are MUCH more usable).

  • 8
    Very important point about the Google Drive API! IIUC any "app password" you make as well will provide full access.
    – Ben
    Commented Nov 15, 2016 at 13:23
  • 3
    Important point: If you open the spreadsheet on your PC, your solution can't be more secure than your PC. If I install a keylogger, I get all account data. Even if you just want to prevent anyone from accessing the file when the PC is turned off: The spreadsheet might still be in the cache on the harddisk. No solution can be more secure than the PC you open it with, only less secure!
    – Josef
    Commented Nov 16, 2016 at 12:28

This isn't as bad a practice as you would think. I'm gonna tackle this in a real world sense and leave out some of the more technical things.

First, when I measure security I usually try to go "Better or Worse" like when your at the eye doctor. Trying to be totally secure is a joke, while at the same time you shouldn't ignore security.

So his method beats - sticky notes, a common (shared) password, a file on his hard drive, a sheet of paper with all the passwords written on it, an unencrypted file on a service like dropbox (that creates real files).

His method is less secure then a cloud based password manager, a local file based password manager. (That's as far as I am going to go with the more secure because that's as far as a normal PC user is likely to go.)

So he's not doing to bad. He is more secure then probably 90% of the users on the internet. More importantly, he is aware of the need to be secure and has taken some steps.

As for "vectors of attack" there are really only a few realistic ones. Someone with physical access to his machines (a Game over any way), some one hacking his google account. Yes there are others, but even the best password managers have to encrypt things in a way that they can be decrypted. So some one going postal at Google and accessing "his" spreadsheet and stealing his ID, is about the same as someone going postal at LastPass and reversing hashing on some of the files and using that.

However if someone were to hack his Google account, it's all over, but again that can be true for any cloud based or hosted password manager.

The last vector is the most important. Because he is using a service that is not meant to store sensitive data, there is no way for a browser or computer to tell that the data is sensitive. So, as others have stated, the document, or parts of it may be cached on phones or computers in plan text. Truly I think this is the largest risk he faces.

So, is he secure enough to hold nuke launch codes, probably not, is he secure enough to hold his data, he is already above average. If he were my fried I would advise him to look at LastPass or Keepass as an alternative. Lastpass in particular should be a very easy switch for him.


I am not trying to advocate this as a way of storing information, I am simply stating that, his method is better then some, and worse then some, and it's up to the user to decide how much security they need. I would be more then ecstatic if I could get my grandmother to use this method.

  • 3
    If he opens that file in his browser, it will be cached. If he has enabled some Google Docs offline features, it will even be intentionally stored on his harddisk. This makes this solution at best as secure as storing it in plaintext on every device he uses to open that file. Because it also enables other attack vectors, it makes the whole setup less secure than storing it in plaintext on the PC. Additionally, it gives a false sense of security.
    – Josef
    Commented Nov 16, 2016 at 12:32
  • One more point: he arrived to that method on its own, meaning that he finds the method convenient enough, which is important. Also, if attacker gets access to that gmail account, chances are she can reset those passwords anyway. Commented Nov 18, 2016 at 12:13

Can you suggest an alternative as easy as typing a URL everytime he needs to recall a password?

You could greatly increase the security of this by adding one slight tweak:

Instead of using a Google Sheet, store the passwords in a document file that can be opened by all of his devices, encrypt that document with strong encryption using a different strong password than the one used for the Google account to access the file, and then upload the file to Google Drive.

For example, a MS Excel 2007 (or newer) file can be encrypted with 128 bit AES.

With this approach you get all the security benefits and conveniences that Google provides, but you also get the added benefit that even if your Google account is compromised (or accessed by a Google employee), no one on earth other than you can open the file without knowing the password.

The downside is you have to type in a password each time to open the file, but if you're really concerned about security, this a pro rather than a con.

Update: I've recently started using a new password manager, and I decided to store it on my Google Drive so all my devices can access it (and Drive auto-versions it for you in case you ever need to revert to an older version). This is basically the same principle as the encrypted excel document, with the only difference being that the manager uses AES 256 instead of AES 128, and there is a dedicated mobile app as well as desktop software, making it much easier to use than an excel document. It also prevents shoulder surfing by allowing you to copy passwords without displaying them. I would strongly urge anyone doing the encrypted excel document to consider switching to a dedicated manager. It's so much cleaner and more efficient to use.

  • 13
    Why not directly use a password manager? They can associate an URL, login and password, and have many goodies that a text file or spreadsheet will never have... Commented Nov 14, 2016 at 16:43
  • 2
    I'm not saying you shouldn't use a pw manager. I was just pointing out a way to tweak the existing method to make it more secure.
    – TTT
    Commented Nov 14, 2016 at 17:49
  • 2
    The downside of this method is that you need an encryption-supporting excel-compatible application on every device. How good is encryption support in spreadsheets for mobile?
    – Chris H
    Commented Nov 15, 2016 at 9:03
  • @ChrisH - I haven't tried it myself, but my understanding is that an encrypted MS excel document can be opened on most mobile devices (with the proper app).
    – TTT
    Commented Nov 15, 2016 at 14:56
  • 1
    @TTT not being interested in such things I can't be sure, but I'm less confident than you after googling.
    – Chris H
    Commented Nov 15, 2016 at 15:38

Here is something to consider that the other answerers did not:

If the file is accessible in any way then ALL of the passwords are compromised.

A password manager worth its salt would expose only one password for each use.

"But how can you crack it? It has ______ security features!" you ask.

Session Vulnerability

Google docs are "locked" up until the point at which the user is authenticated. Then they are wide open for the duration of the session.

So any malware/malsite that can gain access his spreadsheet using the current session can get into it.

Google docs make heavy use of HTML localStorage/cookies/other storage to do their magic, which provides another avenue of attack/compromise.

Bottom Line

Don't roll your own security.

I'll say it again: don't roll your own security.

In order to be effective, security has to work ~100% of the time. Unless you have extensive security domain knowledge (like, it is your job), then you're suffering from Dunning-Kruger and will not be successful.


Leaving the security of Google Docs out of the equation, your friend doesn't give their browser the slightest hint that they are accessing sensitive information. As a result, they should expect their passwords to be saved in random files inside the browser's cache directory, and in the swap file if they happen to use one.

Your friend is better off storing his passwords in plain text on their computers: at least they won't have the false sense of security that way. Of course, a recommended solution is to use a password manager.


It is insecure against a malicious URL shortener

Though I would not be too worried about this in practice, it would be possible for the URL shortening service to build a trap for him.

  1. Redirect him to a page that looks like the page where he would normally log in
  2. Take his username and password
  3. Use this username and password on the actual site

This trap is not flawless, but with some tricks (e.g. only redirecting to the false site for a short period of time) I believe this could work.

  • 1
    Additionally if the URL shortener does not use HTTPS, there will be many ways a MITM-attack against the connection to the URL shortener could be performed. And since the URL shortener is mainly useful in scenarios where you need to manually enter the URL, it means the user has to remember to type https:// at the start of the URL - every time. Of course the URL could be bookmarked, but in that case it is pointless to use a URL shortener.
    – kasperd
    Commented Nov 19, 2016 at 17:28
  • He is not using url shortener for his target website aka bank.example.com. He is using url shortener to shorten his url for google sheet long url docs.google.com/xyz/etfyxjfjxdjdjdirifjfififcucjxjddif/viewform to sho.rt/myPass
    – DavChana
    Commented Nov 3, 2018 at 15:20

All the other answers are good and address the issues of security fairly well, I just wanted to add a few points in addition to the other answers.

First, regarding the security of the scheme, I have a problem with the use of a URL shortener. Someone already brought up the problem of a malicious URL shortener, but even without malicious intent, shortened URLs are not necessarily private because they are short enough that the URL search space is subject to exhaustive search. And actually even unshortened URLs have leaked in the past. Since you cannot assume any additional security from the obscure URL, the security of the system depends fully on the correct sharing settings on the document, and on the correct operation of the permissions system.

I haven't heard of any problems at Google specifically, but other prominent cloud providers have accidentally allowed public access in the past. So, mistakes do happen. And that's assuming the sharing settings are set correctly in the first place. It's easy to accidentally set up a file to not require a login to view, especially if you share the file among family or between accounts. A locally-encrypted file or database, as used by most modern password managers, would stop either of these permissions problems from actually revealing login credentials; the attacker would just get an encrypted blob of data.

My final point is only tangentially related to security. You asked, "Can you suggest an alternative as easy as typing a URL," but in reality typing a URL (and maybe logging into Drive) EVERY TIME you need to log into another website would be very tedious. The login process is as follows using the spreadsheet method:

  1. Open your bank website
  2. In another tab, type in the memorized obscure URL for the spreadsheet.
  3. Log into Google Drive
  4. Search for the bank login
  5. Copy the bank login
  6. Switch back to the bank website
  7. Paste the bank login

Compare to a good password manager:

  1. Unlock your password manager
  2. Open your bank website
  3. Click the browser notification or enter the keyboard shortcut to auto-fill your login

There is a big usability gain from using a password manager instead of a spreadsheet. This relates to security because:

Security at the expense of usability comes at the expense of security.

In this case, your friend may be tempted to start memorizing a few of the most commonly used passwords to make entering them faster, which will likely lead to simplified passwords or even password re-use.


An angle that hasn't received enough attention, are Google Apps. A number of apps require access to your Google Drive to function properly. That includes access to the files already on there.

This makes sense, since a lot of those apps can add and edit files on there (draw.io comes to mind as one), but that access isn't restricted to just those files. A malicious app could read that unencrypted password file.


I'd like to add an addendum for folks considering this strategy not for individual passwords, but for a bank of passwords for a group of people. Specifically, I'm interested in grassroots and community organizing groups, who might value clarity of process for gaining access.

These environments are often characterized by:

  • leadership with lots of [healthy] flux
  • unpaid,
  • lots of people with little time to contribute, and very few people with lots of time,
  • hard to accrue institutional knowledge in individuals

So for a google doc/spreadsheet full of passwords, it can be really nice that:

  • the doc is available via a simple link that is access-controlled,
  • the list of folks with access is auditable via the doc's "who has access" config,
  • everyone understands the tool, and already has an account,
  • the file has a shareable public url (eg. lastpass requires login and navigation to a webapp page without a universal url)
  • that shareable public url has a clear way to request access (this is ALSO a risk, and an attack vector against non-sophisticated users)
  • any member with edit access can also give access to new members (this is also a risk)

And now for the main risks:

  • if the url is widely known, eg. sho.rt/grassroot-org-passwords, then someone could create a new email that impersonates someone whom they know to be involved in the organization. Any one of those with current access could lack skepticism to do due diligence, and invite that attacker. This is a huge risk.
    • there does not appear to be a way to disable the "request access" button on the link. The only defense is to train all those with access NOT to respond to those request emails, or to perform due diligence in some standard way. (confirm the email address with them via another comms channel)
  • it's hard to audit all the different third-party apps that members might have given Google Drive access. When it's a password doc for and individual, then they can check the apps that might have access. But for this, you need to rely on each person doing that work. There is currently no way to check per-document what apps have access, nor which person gave that access. (paid G Suite admin access presumably allows for this audit)

I think it's important to distinguish important passwords from unimportant ones. You really don't need to protect your StackOverflow password with a very high level of security, no-one has much incentive to steal it and impersonate you unless you are some kind of high-risk target. But I wouldn't trust Google with my banking details.

Have you considered the alternative of keeping your passwords on a printed sheet of paper?

My personal solution is to keep password reminders in a place that has only a modest level of security. The password reminder has enough information so that I can recall the password, but not enough for other people to reconstruct it. One way of doing this is to systematically use passwords consisting of a "public" part (say six letters) which you can safely write down, and which is different for every site where you register, followed by a "private" part (say four digits), where the private part is the same for all your passwords, and is never written down or disclosed to anyone.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .