I was going to make a suggestion about PGP or GPG or whatever, but those tools are so bad you can't expect software engineers to know how to use them... (not sarcasm)
Snark aside. What I mean here is that GPG is difficult to use and I would guess 90% of programmers don't know how to use it.
It's really not so bad. You use --genkey to generate a key, --import to import a key, --encrypt and --decrypt do what they say on the tin, --sign to sign messages, --recv-key can download a key from a keyserver and --verify to verify signatures. That's pretty much 99% of what I do with gpg! It behaves like a standard command line utility and can read from stdin and output to stdout if you need it to.
I hear that gpg is very difficult to use quite a lot but I have not had that experience at all. The flags are pretty self explanatory and the magpage(s) are very detailed!
There are also decent GUI interfaces that are extremely simple to operate! I would recommend "kleopatra" for most people! Emacs also works if you are into that!
I'm not sure if you are asking how to export your public key or how to distribute it, so I guess I can mention both.
You can export your public key using the --export flag, by default it exports all public keys in the keyring, so you can pass a keyid to only export a specific key. If you need the exported key to be in text form (not just a binary file) you can pass the --armor flag as well. The --armor flag encodes the binary data with base64 or something which allows you to operate on it like you would any other text (copy/paste, send over email, etc).
As for distributing the key, it depends! Lots of people put their public key on their GitHub profile or somewhere on their website (if they have a website). Since we are on HN you could put it in the "about" field on your HN profile. If none of these work you can send it over telegram, signal or whatever your favorite messaging method is.
For most people and situations the TOFU (trust of first use) method of distribution works fine. If you have stronger security requirements or are more paranoid you can establish a more secure channel or try to meet with the other parties in person.
GPG works fine for me too, and is fairly straightforward (except for email encryption, since my recipients often don’t want encryption, and there is also lack of good email clients supporting encryption).
It depends on your company’s retention policy for historical messages. Otherwise, you’re basically signed in as that user, so you can see whatever they see… which can be a lot depending on the company’s transparency.
I’m aware of many companies who have moved to a 90 day message retention policy in Slack. I thought it was a cost saving measure. But I’m beginning to see the wisdom in it.
It’s a deep hole for a company to dig itself out of, not to mention changing the habits of people to explicitly document things elsewhere.
It would be neat if Slack reported stats on searches so that, for example, a company could better understand what key conversations should be moved into proper documents…but this is likely against Slack’s interests.
Sorry to be Captain Obvious but the solution for that is to update the official, permanently stored reference docs when a question is asked on slack, not keep the only source of tribal knowledge on a ephemeral chat app.
IMO Slack and chat apps are way overused in development teams. They’re there for questions like “when are we meeting for that team event tonight?” And “Hey, can you review this code before I submit?” And NOT “Can you describe, in massive detail, all the arguments that get passed to our FooBar function?”
In a previous project I worked on, we used to nickname the passwords used throughout the system. The password re-use was virtually non-existent, but sometimes we forgot which system required which one (we were installing and erasing a lot of servers for testing stuff).
So, someone would ask a password to a system, we'd answer "ridiculously long one", or "the one X came up with", "variation 5".
When one of the security guys overheard what we did, and asked the details, we told what we do. The answer was "oh, that's neat!, go on".
Long living passwords shared via paper, and lived on people (like on their wallet, and never laid in the open), the other short lived ones are just remembered, but not mentally tied to anywhere.
It was a fast-paced project, so the project dynamics made the method work. If the systems and passwords were more stable, it might not have worked this well.
I'm a contract worker and often times a company first onboards me to slack, then sends me a bunch of login information in plain text after opening an internal ticket to add me to various systems.
My current company has an internal ‘secret sharing’ tool kind of like Pastebin (but encrypted, one time open links, etc) for one off sharing of things like that. For all other creds we use Vault heavily.
PII, passwords, things like that are NEVER to go over Teams or email.
If these are temp passwords that get changed on first login and expire maybe it's not so bad. If it is a normal password though yes that is pretty bad.
Fortunately, AWS from my example makes you set a new one after this. I'm sure there are other company-administered services with similar dynamics where the pwd change isn't required or the admin won't check that box because try are bad at their job
Even Windows has this, but there are a bunch of corner cases where it doesn't work.
The integrated RADIUS server can be configured to allow passwords that need changing (so that you can actually connect to AD and change it if you're away). But many other services, like AD-backed VPNs and such, will choke on a password that must be changed.
Start by not having a password manager that is universally adopted across the corporation.
Then maybe you've got a planned change that requires a manual operation on the production database, and you don't have the password already because it's rotated daily.
Maybe you need the agent license key for the monitoring system, so you can add it to the secrets file for the new host you're setting up.
Maybe someone created a new service and, and asked you to generate a new oauth2 client secret for it, and you need to send it to them.
Maybe it's corporate policy that every laptop must have an encrypted disk, and you've mailed a new remote worker a laptop and now need to send them the disk password by a different channel.
Maybe you occasionally need to work with some decrepit system that doesn't support single-sign-on - like a server's IPMI or some obscure bit of network equipment.
Of course there are better options than slack (which doesn't even have an off-the-record mode) but if slack is what everyone uses? Well....
Once a message is deleted there is no way to recover it, to my knowledge. But message retention in Slack is infinite. Further, sessions are infinite, at least last I set it up.
I think we set something like 1 year of retention for "public" channels, 9 months for private, and then certain channels can lower it beyond that. Same for files. And we have our tokens expire once a month.
I was going to make a suggestion about PGP or GPG or whatever, but those tools are so bad you can't expect software engineers to know how to use them... (not sarcasm)
Snark aside. What I mean here is that GPG is difficult to use and I would guess 90% of programmers don't know how to use it.