5 ms·

The lesson is don't send passwords over slack. If you have slack access can you easily get access to private/historical messages?

rbera 4y ago
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.
- lelandfe 4y ago
  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.
  - moeadham 4y ago
    They way things are going, 90 days is too long.
    - djmips 4y ago
      Without infinite retention, our company would lose untold searchable solutions to problems and other vital information.
      - deleted 4y ago
        [deleted]
      - dfcarney 4y ago
        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.
      - ryandrake 4y ago
        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?”
kenjackson 4y ago
I’ve never had someone send me a password before. What do they need to send passwords over slack for?
- ajmurmann 4y ago
  "Oh, I forgot my AWS password, can you reset it?" 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
  - vladvasiliu 4y ago
    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.
- naet 4y ago
  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.
  - somehnguy 4y ago
    Oof, that sounds bad. 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.
    - nightski 4y ago
      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.
staticassertion 4y ago
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. The defaults for Slack are pretty insane.
Buttons840 4y ago
> The lesson is don't send passwords over slack. 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.
- VPenkov 4y ago
  Is describing them as bad related to their ease of use or is it related to technical shortcomings? I use PGP very frequently and I'd like to know what's bad about it so I could maybe look for alternatives.
  - Buttons840 4y ago
    You're right and I'm sorry. I should have explained my snarky comment fully. I meant that they're difficult to use. I would love to be proven wrong or directed to some good resources for learning them.
    - chlorion 4y ago
      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!
      - Buttons840 4y ago
        How would I send my public key to someone?
bayindirh 4y ago
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".
- Tempest1981 4y ago
  How did the initial communication occur? Whiteboard? In person? Shared vault?
  - bayindirh 4y ago
    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.
tokza 4y ago
or use secrets sharing service like this https://github.com/jhaals/yopass https://github.com/jhaals/yopass

rbera 4y ago

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.

lelandfe 4y ago
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.
- moeadham 4y ago
  They way things are going, 90 days is too long.
  - djmips 4y ago
    Without infinite retention, our company would lose untold searchable solutions to problems and other vital information.
    - deleted 4y ago
      [deleted]
    - dfcarney 4y ago
      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.
    - ryandrake 4y ago
      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?”

kenjackson 4y ago

I’ve never had someone send me a password before. What do they need to send passwords over slack for?

ajmurmann 4y ago
"Oh, I forgot my AWS password, can you reset it?" 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
- vladvasiliu 4y ago
  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.
naet 4y ago
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.
- somehnguy 4y ago
  Oof, that sounds bad. 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.
  - nightski 4y ago
    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.

staticassertion 4y ago

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. The defaults for Slack are pretty insane.

Buttons840 4y ago

> The lesson is don't send passwords over slack. 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.

VPenkov 4y ago
Is describing them as bad related to their ease of use or is it related to technical shortcomings? I use PGP very frequently and I'd like to know what's bad about it so I could maybe look for alternatives.
- Buttons840 4y ago
  You're right and I'm sorry. I should have explained my snarky comment fully. I meant that they're difficult to use. I would love to be proven wrong or directed to some good resources for learning them.
  - chlorion 4y ago
    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!
    - Buttons840 4y ago
      How would I send my public key to someone?

bayindirh 4y ago

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".

Tempest1981 4y ago
How did the initial communication occur? Whiteboard? In person? Shared vault?
- bayindirh 4y ago
  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.

tokza 4y ago

or use secrets sharing service like this https://github.com/jhaals/yopass https://github.com/jhaals/yopass