1

Background

Often developers and clients need to exchange passwords to be able to access some services. Of course the best option would be to never use someone else's credentials to log in, and instead create a different account for every user. And of course there's always the option of using a remote-desktop application to be able to work on a client's machine without having to share any passwords. But these options are not always viable. Plus, often clients don't have enough experience with security or even computers at all, so you can't really expect them to understand cryptography, use GPG, etc., or be willing to install and learn to use other software, or follow complex rules without some irritation (like having to send pieces of passwords over different channels, or spell out long passwords on the phone, etc.). This is such a common scenario that the vast majority of professionals I've worked with keep on sending or requesting passwords in plaintext via email (and of course they don't even delete those emails afterwards). Because it's easier.

So I thought of a method that is almost as simple as sending an email, and at the same time it should provide enough security compared to other methods available in the same scenarios.

The method

  1. Create an empty text document on Google Docs. Then, if you have any credentials to communicate, just write everything in this document. Otherwise leave the document empty.
  2. Share the document with the other party, who must have a Google account (but everybody has one today).
  3. The other party opens the document (they must be logged in to their Google account). If they have any credentials to communicate, they will write them in this shared document.
  4. When all the information has been exchanged, you (the owner of the document) just delete the shared document.

Pros: very easy even for the laziest people; all the info is encrypted during the transmission (thanks to HTTPS); the info is deleted as soon as possible; Google's security is supposed to be better than the average provider; seems more secure than email, SMS, or voice calls in general;

Cons: what are the cons? Am I missing anything? All the cons I can think of don't seem to fit the threat model. In other words, I'm afraid the weaknesses of this method cannot be mitigated in a scenario where some people aren't experienced enough or don't care enough about security. So passwords can be stolen if a machine is compromised, or if a Google account has a very weak password, or if a Google employee manages to access Google Docs data... but if we add such threats to our scenario, then we are going to have much bigger problems (and good luck finding a solution).

So the question is: does my method make sense? What are the real cons? Am I missing anything?

10
  • If their email is compromised, I'd guess their google account is, too. People often re-use passwords, or any mal-ware could steal both their email and google credentials. I suspect the extra steps don't significantly improve security. Cross-domain email might be plaintext and thus intercepted, but I'd be surprised if that is anywhere near as common as others just having their credentials.
    – Extrarius
    Nov 4 '20 at 16:39
  • 4
    Docs persist even when deleted, if that matters.
    – schroeder
    Nov 4 '20 at 16:44
  • @Extrarius, but remember that emails can be downloaded (Android, Outlook) so they can end up somewhere else. Google Docs, I suppose, just stay there in the browser.
    – reed
    Nov 4 '20 at 16:47
  • 1
    @reed The google docs android app has options to allow offline use, which isn't any different than an email app storing downloaded email on local storage. I'd also expect security-illiterate users to store copies of shared credentials in insecure locations, such as a text document on their desktop or in their browser's autocomplete database with no master password set.
    – Extrarius
    Nov 4 '20 at 17:21
  • 1
    @reed Are you concerned that with this solution, Google would have access to the passwords that you send this way?
    – mti2935
    Nov 4 '20 at 22:44
2

What you have proposed is analogous to texting a password (but with TLS). As long as the doc is a separate channel from the account in question, and there is nothing relating the password string to its account, then you have a similar threat model.

The doc can be downloaded, saved, undeleted. A compromised Google account exposes the password strings. But all that is similar to a texted password.

So, it would seem that the approach improves on email and text by ensuring deletion of the central doc, ensured TLS, and access logging. It does not appear that the process introduces any more threats than email or text.

1
  • 1
    Yes, basically it's like "texting with TLS", but instead of using a particular application (which would have to be installed and trusted), or coding my application (which again would have to rely on trusted servers, etc.), I just rely on browser + Google (which are already trusted by everyone in most threat models).
    – reed
    Nov 4 '20 at 16:56

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.