Looks like the hack was made exactly how it was done for EA using stolen Slack cookie: https://www.vice.com/en/article/7kvkqb/how-ea-games-was-hack...
There was a huge leak for Diablo 4 two weeks ago as well.
There was a huge leak for Diablo 4 two weeks ago as well.
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.
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?”
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
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.
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.
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....
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.
The defaults for Slack are pretty insane.
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.
I use PGP very frequently and I'd like to know what's bad about it so I could maybe look for alternatives.
I meant that they're difficult to use. I would love to be proven wrong or directed to some good resources for learning them.
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!
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.
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".
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.