Password over the internet

[gilweb]

You have a password you need to send someone securely, It's long and ugly and not suited for telephone and they don't live close for an in-person exchange. The person on the other end is not particularly internet or computer savvy and not well known to you. I've looked at https://1ty.me/ but wondered what other options there are. What would y'all do?

 

[PHolder]

Depends on what the password is protecting and why you're sharing it.

I wanted to share a file with Steve, so I used a service for sharing files, encrypted the file with a password, and sent the password in email.

Pastebin has password protected one time use pastes...

 

[AlanD]

Assuming that the password is protecting data that you are also going to send, the best option is to send each using different methods. For example, email the file of data, and send the password by SMS. That way, if either method gets compromised, the other should be safe.

 

[Dave]

I really like https://privnote.com. Read once. Content is encrypted on the client. Generated url contains the decryption key, Really simple.

Example: https://privnote.com/3cbt4Fmc#Kxgdcbkfi

 

[gilweb]

I should have mentioned that it's not really a file share, just a short piece of text (although that could be in a file).

The particular case here is me working with a vendor of ours that is setting up an FTPS account and needs to send me the password. I don't want to give them my phone info for SMS (which is normally how we do it: SMS or MS Teams message or Signal message with the password and the rest in email).

We ended up using https://1ty.me/, but I'll try https://privnote.com too. They seem to operate in an identical way. I can only hope, though, that the services are doing what they say an not storing my unencrypted text. I like these because they are simple and (apparently) effective.

 

[Dave]

I should have mentioned that it's not really a file share, just a short piece of text (although that could be in a file).

The particular case here is me working with a vendor of ours that is setting up an FTPS account and needs to send me the password. I don't want to give them my phone info for SMS (which is normally how we do it: SMS or MS Teams message or Signal message with the password and the rest in email).

We ended up using https://1ty.me/, but I'll try https://privnote.com too. They seem to operate in an identical way. I can only hope, though, that the services are doing what they say an not storing my unencrypted text. I like these because they are simple and (apparently) effective.

You could, of course, verify that by hitting F12 in Chrome to open the debugger before saving and retrieving a test message and looking at the Network tab to examine the exact contents of what was sent to be stored.

> They seem to operate in an identical way
WOW!! Surprisingly... absolutely not! Not even close!

I just checked the network traffic (as described above) for https://1ty.me. It is vastly different and, in my opinion, inferior to https://privnote.com. With https://1ty.me/, when the (we can only hope) encrypted content is fetched, the content was returned in plain text without the client having to provide any key! Granted it was transferred over HTTPS, but, that still means the server did the decrypting. Which means they can decrypt your content. Assuming it was actually ever encrypted.

In stark contrast, https://privnote.com encrypts the content on the client using a locally generated key that is never sent to the server. As you may know, any URL that contains a # actually has two distinct parts. The part before the # is the normal URL that is used to fetch a page from a server. The part after the # is client-specific and is never sent to the server. Most frequently that part is used to position the browser at some tagged location on a retrieved page and/or highlight some matched content on the page.

Where Privnote stands well apart from 1ty.me is that the generated URL used to read the contents contains two parts. In the example above: https://privnote.com/3cbt4Fmc#Kxgdcbkfi, the part before the #, https://privnote.com/3cbt4Fmc, is the URL used to fetch an encrypted blob (ID: #3cbt4Fmc) from the Privnote server. The part after the #, "Kxgdcbkfi", which never left the client during encryption, storage, retrieval, or decrypting, is the unique key required to decode that specific content. So, when you give someone the two-part URL for a Privnote, you are giving them both the URL to retrieve the encrypted content AND the key needed to decode it once it has been retrieved. The (very nice) gentleman who created Privnote does not ever have the ability to view your encrypted content. And the content never exists in unencrypted form outside of your client browser.

 

[crahen]

Use the Send feature in Bitwarden, it can generate a single use, expiring URL you can share.

 

[PHolder]

It should be said that setting an unchangeable password is the root cause of your problem. Ideally a new password is generated and communicated to the end user through some automation, and then the first time the new user logs in s/he is expected to pick their own permanent password. This limits the window of abuse to the time during which the password is generated but not yet changed. And it also becomes pretty obvious if someone else logged in first and was forced to change the password before the intended new user.

 

[Dave]

Assuming that the password is protecting data that you are also going to send, the best option is to send each using different methods. For example, email the file of data, and send the password by SMS. That way, if either method gets compromised, the other should be safe.

Good thought. The two parts of Privnote could be sent via separate channels.

 

[Dave]

It should be said that setting an unchangeable password is the root cause of your problem. Ideally a new password is generated and communicated to the end user through some automation, and then the first time the new user logs in s/he is expected to pick their own permanent password. This limits the window of abuse to the time during which the password is generated but not yet changed. And it also becomes pretty obvious if someone else logged in first and was forced to change the password before the intended new user.

In working with IT within my company, I have changed a password while on the phone to one that COULD be verbally communicated and had them change it immediately. The RIGHT solution is, of course, SQRL!!!

 

[ScruffyDan]

why not signal? or whatsapp? Both are easy to install and are quite secure while the data is in transit

 

[MichaelRSorg]

Signal means exposing your phone number. Whatsapp is owned by a spy agency (not technically, but in reality). And both mean installing more software.
I would vote for a free account from ProtonMail. Messages between PM users are fully encrypted and no new software has to be installed.

 

[ScruffyDan]

Signal means exposing your phone number. Whatsapp is owned by a spy agency (not technically, but in reality). And both mean installing more software.
I would vote for a free account from ProtonMail. Messages between PM users are fully encrypted and no new software has to be installed.

If you don't feel comfortable exposing your number then that would rule out both signal and whatsapp. But if you are sharing passwords, then sharing phone numbers is likely also ok. (though I can imagine scenarios where this is not the case).
And it is worth pointing out that while Facebook is far from a trustworthy company I don't think anyone has made a credible case that WhatsApp messages aren't very well secured while in transit (it does use the Signal protocol). That being said the metadata is fair game for Facebook to do with as they please.

I have actually used Signal to send passwords to non-technical users, and it works well enough. As an added bonus Signal's disappearing messages lower the risk the password being leaked if the endpoints get compromised after the fact.

 

[gilweb]

The deep dive be @Dave (Nice!) seem to lean towards https://privnote.com as a credible solution given the situation - long password, not a "trusted" recipient and not wanting to "connect" using some other messaging platform.

I actually find it interesting that 1ty.me implemented it server-side like it did. I should send a link to Steve's podcast.

 

[JimWilliamson]

Having the user reset the password is my recommendation - as was mentioned above.

If not doing the above, two options on my mind:
A) Send most of the password via some easy channel (eMail) and send the remaining / missing part (say, the first or last five characters) via voice phone call.
B) Depending how computer comfortable the end person is (an issue you mention), work with them to have them connect you to their device (many remote access services have free or trial options). Once connected, you could then tend the transmit (or formal password reset) yourself / with them (many remote connections offer copy-paste between the connected systems).

 

[JulioHM]

Mailvelope has easy to use browser plugins for managing GPG keys.
It even integrates well with several webmail clients, like GMail.