[the_duke]

Let's ignore the rather awkward self promotion, and the fact that 2FA would have prevented this specific incident.

This is the important part, which everyone should think about:

> What would have been way worse — immeasurably worse — is if our team had used Slack for anything other than what we did use it for, which was discussing outages of our own product. Had my cofounder and I discussed our company's cap table, or business partnerships, or compensation agreements, or ongoing legal matters over Slack; or had our team traded API keys, or security-sensitive matters; or had we controlled mission-critical infrastructure via Slack-powered "bots"; we'd be sweating bullets to this day that our important company secrets were out in the open, about to resurface at the worst possible time.

I see Slack being used for everything at a lot of companies.

There are a lot of interesting things in the chat history everywhere: SSH/API keys, logins and passwords, sensitive internal documents, chatops bots that would let one take control of the infrastructure, and worst of all - juicy office affair gossip.

Combine this with often lax user management (forgetting to disable old accounts, inviting people to channels they shouldn't be in, ...).

Most companies overlook this and don't even have a policy for what's OK to post on Slack, and what isn't. Not even to dream of any kind of enforcement.

I'ts a big security problem, even without Slack getting compromised, and should be on the radar for CTOs.

[FabHK]

> the fact that 2FA would have prevented it.

Is that so? The article states: "If the attackers inject server code, 2FA or U2F or any Web-based security practice does little."

[ryanmcdonough]

I don’t quite understand that bit, the attackers could at the time steal plaintext passwords - however how does that affect 2FA benefits several years after the attack?

It sounds like he’s mixing a couple of things up there unless anyone can explain otherwise?

[mikeash]

It won’t prevent an attacker from logging in as you at the moment, but it will prevent them from using stolen credentials later on.

[TrueDuality]

If they can inject server code, they can bypass 2FA entirely. They don't need your 2FA code they'll just skip that part of the authentication.

The same goes for passwords, but with passwords there is the potential of additional value on other sites that haven't been compromised so those are always worth collecting.

[mikeash]

This particular scenario involved injecting server code in 2015, then waiting until 2019 to use the credentials they collected. They would not be able to bypass 2FA here.

It’s true that 2FA wouldn’t protect you from having your account compromised immediately, but that’s not what happened.

[bpchaps]

At my last job, I wrote a little tool to download hipchat chat logs and scrape them for anything that looks like a password. There were tons!! I raised it to the CTO/CIO, and while they sounded interested in it, they never enacted any policies, etc, to prevent the sort of password sharing that anyone can apparently easily take advantage of.

In fact, the CIO asked me to send him a spreadsheet of when/where passwords were shared -- and then never did anything with it, despite the file essentially being a password map of the infrastructure. When I asked him if he deleted it, he told me he couldn't because the company's lawyers wouldn't allow him to. Lol.

It's insane out there.

[tnorthcutt]

What did you use for "looks like a password"?

[bpchaps]

I use a python library called 'passwordmeter' to check the password 'strength' of tokens. If the token's password strength is high, it's either going to be a password, a hash, a key, or perl (half joking). It's then just a matter of ignoring the false positives - about 95% - but that's not as time consuming as it sounds considering the reward.

The precursor to the hipchat scraper: https://github.com/red-bin/password_finder

[tnorthcutt]

Cool, thanks!

[bmurphy1976]

The correct answer is routine password rotation, but of course that's stupidly hard to do.

[eeeeeeeeeeeee]

I don’t agree with that. Regular password rotation increases the opportunity for phishing attacks because people become used to sleep walking through it. And users are generally just adding one or two characters to the password anyway.

Instead, that energy is better spent on requiring strong passwords and people using password managers and two-factor.

[pmh]

Password rotation in this context is for the infrastructure, not normal user accounts.

There are other options for securing/managing infrastructure access (e.g. PKI, Hashicorp Vault), but if you're using passwords, it's a good idea to rotate them if only to encourage good practices around automation.

[bmurphy1976]

I'm not referring to user accounts, I'm referring to password management for things such as database and/or internal APIs.

[harryh]

Slack has some options to delete all messages over N days old. Unless there is a really good reason not to, turning on this feature generally sounds like a good idea. At least you can drastically limit the length of the archive available to any attacker.

[AJ007]

I strongly suggest not transmitting secure information or files via Slack or any other medium that retains or broadcasts (push notifications, email alerts) data.

Given the massive and escalating fines over customer data hacks and leaks I suspect we will see laws requiring data retention going head to head with consumer privacy laws. Given that even Jeff Bezos can’t keep his communications secure, the outlook for infosec consultants is fantastic. If anti-encryption laws start appearing on top of all of this, it’s going to be an absolute bonanza.

[Ntrails]

That's a terrible feature in an instant messenger client for work use? I cannot recall the precise details of my conversations with smart people who know things I do not. I can recall that I had the conversation and remind myself what I learned before.

[manigandham]

Depends entirely on the conversation obviously, but perhaps important details should eventually be coalesced and moved to a more permanent document or project management system before the deletion deadline. It's a good discipline to have.

[moneytalks]

I don't think anyone would argue with the value side of the question. The tricky part is calculating the cost side. (The cost of not deleting old messages.)

Surely we can agree that the cost side is > 0.

I'd argue that the benefit side is generally at least a little lower than what we think it's going to be. And if the expiration limit is set to say, 1 year, the cost of deleting old messages goes down considerably.

[harryh]

As with many things in life, it's a tradeoff. Do you want to accept a higher risk of security incidents or make it easier to recall information from a long ago IM conversation?

There are rational reasons for an organization to do either.

[jacobr1]

Doesn't that have compliance implications? My understanding is that digital communications usually need to be stored for 3+ years in the case of a lawsuit and longer if you are in a regulated industry.

[sriku]

Do Keybase folks use Keybase for literally all their communications, document sharing? That's a bit hard to imagine. I'd wager that some of those important comms were on email and pretty much all the scary arguments about server/account hacking would apply to the involved email accounts too?

And a naive interpretation of the posting also raises the question of what secret deals, etc could Keybase be doing that would be disastrous if it were to come out later, that, as a Keybase user, I should be concerned about? A secret backdoor in the keys embedded for the NSA?

(Keybase user here)

[johnmarcus]

Ive been considering building a product that would help eradicate "lax user management" of Slack, and like platforms. It would basically keep an audit trail of managers approval for their specific team members they manage access to specific platforms and products. Basically, helping scale that one IT guy whom should somehow know every person at the company in detail.

If I succeeded in making the process easy & less time consuming than it is now, do you think it's a product you would pay for?

[xtracto]

> or had our team traded API keys, or security-sensitive matters; or had we controlled mission-critical infrastructure via Slack-powered "bots"

That's why I always strongly recommend having a https://privatebin.info/ . In fact, in every startup I have been, I setup an instance of that forcing "burn after reading" and as a policy all credentials and sensitive info goes there when sharing.