4

I'm constantly exchanging credentials with my clients for things like database servers, cloud accounts, etc. Neither I nor my clients, have time to implement a sophisticated method for secure transmission.

So far we've been relying on 2 main methods, each with its own risks:

  1. Slack/Discord/WhatsApp chat: I understand that this method is not ideal, although WhatsApp is end-to-end encrypted. The other I'm not sure. I have the sense that the risk of someone accessing those chats and exploiting those credentials is low
  2. OneTimeSecret site: the site https://onetimesecret.com is supposed to be secure and the secrets get burned after being read. But I'm not sure how reliable this site is. For all I know they might be storing all my secrets in a public txt file shared on the web

I know both options have their limitations, but I'm having a hard time weighing the risk and deciding which one is best. Also is there a better alternative to these two methods?

3
  • Your title says "best easy" but your question is about risk. What's your primary concern?
    – schroeder
    Jul 5 at 14:36
  • I want to find the best trade-off between easy and secure. If I go for something too complex it'll annoy my clients and I don't want that, but I want it to be as secure as possible. The credentials are things like db servers, cloud accounts, etc. Most of the time, they don't change them after they receive them Jul 5 at 14:41
  • 2
    The best method is to do what you are doing, but encourage them to change the password once they log in because it could be considered to be compromised.
    – schroeder
    Jul 5 at 15:08

3 Answers 3

3

The password manager Bitwarden has a "Send" feature that allows the sender to create a "Send" record that has text secrets to be shared. The sender then sends a generated URL to the receiver. There are options to protect it with a password, to limit the number of views, to limit the time, etc. Creating such an account and using this feature is free. Like other methods, you can send the link in one encrypted channel, and pass the password in another channel.

I am a user, and am not an employee.

1
  • 1
    Most modern password managers have a way to share passwords with individuals. I would highly recommend this turn-key solutions instead of building your own.
    – dandaman12
    Jul 11 at 22:51
2

If you already have a web server, you could host your own pastebin (or onetimesecret.com-like) instance. Then the issue of trust will go away. These sites are not doing anything special that is hard to replicate.

There are scripts you can use for this.

Needs to be served over https of course, using a trusted certificate (Let's encrypt will do).

1
  • That's what we are doing: we've set up a docker with Yopass (images are readily available, or you can review the code & build it yourself if you want to be extra careful) and exposed it to the outside world with a let's encrypt certificate. Given the infrastructure we already have at hand it was a 10 minute job. Jul 7 at 8:21
2

Use two channels. Send a .ZIP attachment of credentials.txt which is password encrypted, and speak the password interactively or even in voice mail. You're forcing a prospective attacker to compromise diverse channels.

As long as you're doing that, produce a dozen high-entropy credentials and send them along for the ride. Then a week later you can spin up a new docker image and explain that "the linux password is 2nd entry, and the postgres password is 3rd entry" in your pre-arranged list of credentials.


Do not use these commands to produces a crypted archive:

$ sudo apt install zip
...
$ lsb_release -d -c
Description:    Ubuntu 22.04.2 LTS
Codename:       jammy
$
$ zip
Copyright (c) 1990-2008 Info-ZIP - Type 'zip "-L"' for software license.
Zip 3.0 (July 5th 2008). ...
$
$ zip -Psayfriendandenter foo.zip foo.txt
...
$
$ 7z l -slt foo.zip | grep '^Method'
Method = ZipCrypto Deflate

as the ZipCrypto option offers laughably poor "security". It feeds a 96-bit key to several rounds of crc32, which of course is a linear function.

This is rooted in the NSA / NIST / Commerce wars on crypto of the '90s, when even a D-H negotiation was trouble. Due to correlations the nominally 96-bit keyspace can be bruted with just 2 ** 56 complexity. And given just thirteen bytes or a kilobyte of known plaintext, it takes work of 2 ** 38 or 2 ** 29 to recover the key.

Prefer these commands:

$ sudo apt install p7zip-full
...
$
$ 7z -psayfriendandenter -mem=AES256 a foo.zip foo.txt
...
$ 7z l -slt foo.zip | grep '^Method'
Method = AES-256 Deflate
$
$ file foo.zip 
foo.zip: Zip archive data, at least v5.1 to extract, compression method=AES Encrypted

Extract the file with

$ 7z x foo.zip

and enter the passphrase. Note that using the wrong extract software will yield no joy:

$ unzip foo.zip
Archive:  foo.zip
   skipping: foo.txt                 need PK compat. v5.1 (can do v4.6)
5
  • I like the idea of using multiple channels, but I don't believe zip encryption is very strong. Perhaps a keepass database instead?
    – jrw32982
    Jul 10 at 17:46
  • I don’t exactly understand your remark. P7 zip uses AES symmetric encryption. If you send a 43 character key that’s base-64 encoded, that is enough entropy for maximum AES security. If you choose to use a shorter password, that’s fine, you are free to set the security parameter to whatever suits your needs.
    – J_H
    Jul 11 at 1:07
  • From the zip manpage: "And where security is truly important, use strong encryption such as Pretty Good Privacy instead of the relatively weak standard encryption provided by zipfile utilities."
    – jrw32982
    Jul 12 at 12:36
  • @jrw32982 what version / sourcecode URL of zip are you using? Does it somehow manage to not support AES and PBKDF2? Please post $ 7z l -slt *.zip output to reveal which algorithm is being used. Clearly a low entropy passphrase, even with AES, won't be secure against dictionary attacks, so users should choose an appropriate security parameter, avoiding passwords like "123". The -P manpage advice is mostly about attackers on the same system using ps axuww to view command line arguments and obtain a password that way. GPG is very good at promptly zeroing key material.
    – J_H
    Jul 12 at 19:25
  • I'm referring to /usr/bin/zip (version 3.0 from the info-zip package), not 7z. I don't think they're talking about using ps specifically in that quote. From FAQ: "note that the original encryption scheme used in all versions of Zip (as well as PKWARE's older products) is quite weak". You can read more about it there. I'm inclined to take their advice.
    – jrw32982
    Jul 13 at 20:32

You must log in to answer this question.

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