Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Slack Security Incident

keybase.io

Post reply on HN
Print view View original

101–110 of 110 posts

Re: Slack Security Incident

#101

Post by jacobr1 »

harryh wrote: post #54
the_duke wrote: post #20

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, o…

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.

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.

Re: Slack Security Incident

#102

Post by tnorthcutt »

bpchaps wrote: post #86
the_duke wrote: post #20

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, o…

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 w…

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

Re: Slack Security Incident

#104

Post by bpchaps »

tnorthcutt wrote: post #102
bpchaps wrote: post #86

Earlier quoted context omitted.

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 w…

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

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

Re: Slack Security Incident

#105

Post by tnorthcutt »

bpchaps wrote: post #104
tnorthcutt wrote: post #102

Earlier quoted context omitted.

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

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_…

Cool, thanks!

Re: Slack Security Incident

#106

Post by FabHK »

ashelmire wrote: post #53
FabHK wrote: post #39

Earlier quoted context omitted.

> It's usually more performant and is less of a security risk. Source, particularly for the "less of a security risk"? (It might well be now, I'm not an expert, but a few years ago I'd have thought "no way").

Which do you think is more potentially damaging? 1) Using a website which has had its server code compromised (slack). 2) Installing and using an application which has had its code compromised (maybe also slack). The installed application is going to have more access and potential to damage your system and to compromise your data. There's not really anything more to it. One's in a browser sandbox and limited by brows…

Makes sense, thanks. I think my mental threat model was different:

you're talking about dodgy (potentially compromised) software: better run in the browser sandbox (albeit imperfect) than natively.

I was thinking of sensitive software (eg secret chats) I want to protect from attack: better run natively than in the (imperfect) browser sandbox.

In the context of this discussion (Slack), your threat model probably makes more sense.

Re: Slack Security Incident

#107

Post by lorenzsell »

I’m a little confused here. Isn’t Keybase a slack replacement product? Why is the CEO of Keybase using Slack for any company communication instead of his own service? Am I missing something obvious here?

Re: Slack Security Incident

#108

Post by oconnor663 »

lorenzsell wrote: post #107

I’m a little confused here. Isn’t Keybase a slack replacement product? Why is the CEO of Keybase using Slack for any company communication instead of his own service? Am I missing something obvious here?

It's described in the article:

> what we did use it for, which was discussing outages of our own product

You can't use Keybase to communicate about why Keybase is down :)

Re: Slack Security Incident

#109

Post by bmurphy1976 »

eeeeeeeeeeeee wrote: post #95
bmurphy1976 wrote: post #91

Earlier quoted context omitted.

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

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.

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

Re: Slack Security Incident

#110

Post by tialaramex »

bluk wrote: post #24

The post says "If the attackers inject server code, 2FA or U2F or any Web-based security practice does little." Understandably if the attacker was actively scraping passwords with 2FAs and was using the credentials immediately, that would be an issue. However, for the issue mentioned in the post, wouldn't 2FA have saved him? Supposedly, the compromised credential is from 2015.

U2F saves you, most of the other options potentially make it worse.

If the bad guys are dumb and just were there to passively steal passwords then almost anything works. But if the bad guys are paying attention and stealing authentication secrets then it breaks down like this:

Passwords: Stolen if used while bad guys could watch

TOTP/MOTP/ similar software one time codes: Seed gets stolen by bad guys, they can generate the same codes as you now.

SecurID/ similar key fob type one time codes: Seed gets stolen by bad guys, they can generate the same codes as you now.

SMS: Now bad guys know your phone number. In a targeted attack they will "jack" the number and cause even more havoc, but you might be safe against script kiddies

U2F (or WebAuthn): The server doesn't know any secrets. It knows a cookie (meaningless gibberish except to one FIDO device) and a public key (public). Stealing these is futile and cannot be used to impersonate the user.

TOTP and SecurID surprise people because they forget that although the credential transmitted is just a one-time code, the _server_ (which bad guys broke into here) needs to know the same seed as the user does to get the same codes.

Post reply on HN