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

Slack was hacked

slackhq.com

Post reply on HN
Print view View original

421–430 of 526 posts

Re: Slack was hacked

#421

Post by docbrain »

eridius wrote: post #297
JackC wrote: post #250

Earlier quoted context omitted.

ircmaxell makes a good point in that comment -- not that the concept of a pepper doesn't work, but that a two-way encryption function is a better choice than a hash function for applying the pepper. Your pepper will be a long, random key that is known to your app server but not your database server. If you store passwords as: bcrypt(bcrypt(password, salt), pepper) then you spend a lot of cycles bcrypting your long, r…

> what's the risk that someone gains access to your DB but not your app server, vs. the risk that in implementing the pepper, you somehow screw up and store something easily crackable? The question is irrelevant anyway, because if someone gets access to your app server, they get the secret in both cases (pepper and encryption). So the first risk there is present in both cases, which just makes this a static "what's t…

You never know. Some developers might not be smart enough to use an SSL connection from their app server to their DB server. The influx of newb devs out there is growing and security is usually not high on the learning list or the new devs priority list. If so, hackers could possibly get access to the DB without even needing the app server in the first place. Get your certs folks!

Re: Slack was hacked

#422

Post by tracker1 »

homakov wrote: post #411
tracker1 wrote: post #101

Earlier quoted context omitted.

To you last point... it's funny the number of companies that are using virtual 2fa clients on their laptops for VPN connections because they wanted to save money on hardware tokens. kind of negates the second half of 2fa.

It doesn't. The only case when it's worse is when your laptop is stolen and you don't know about that - very unlikely for corporate laptops

Or, monitoring software on your computer, the origin of which now has access to the computer, your password, and the token generator.

Re: Slack was hacked

#423

Post by newobj »

mateuszf wrote: post #28
hazelnut wrote: post #11

Earlier quoted context omitted.

Which leads to the question if slack encrypts the chat data in the database.

That would make implementing search quite hard so I'd say - it's pretty likely they don't encrypt it.

That's not right. There is no need to store text body in order to index it. Furthermore, you can implement an index of token hashes, rather than an index of tokens.

Re: Slack was hacked

#424

Post by ntucker »

mirashii wrote: post #404
ntucker wrote: post #337

Earlier quoted context omitted.

We have an approach to this which doesn't modify the password hashing at all, so it can't possibly reduce the strength: we store users and password hashes (currently bcrypt * ) in two separate tables, and the key used to look up a given user's password hash is an encrypted version of their user id. The encryption key for doing this transformation is loaded dynamically at app startup and has some extra security precau…

Is there some reason that you don't just hash the whole column or table though? It does everything you described, except also makes even the bcrypted passwords available in the event of a db dump. It just seems like a half-measure where a whole-measure is just as easy to implement.

Hmm, interesting suggestion. We wouldn't want to encrypt the entire row since we want to be able to query on specific columns (version in particular). My only excuse otherwise is that the goal was "disassociate the hashes from the users" not "encrypt the hashes." :) You're right that we could have done more, although whether that makes meeting the original goal a "half measure" depends on your perspective. :)

Re: Slack was hacked

#425

Post by zaroth »

homakov wrote: post #402
zaroth wrote: post #365

Earlier quoted context omitted.

"In fact the root of the problem was default Sinatra dependency 'rack-protection'". They were doing the input sanitation, but it wasn't the very first thing in the processing pipeline, since "best practice" was to pipe everything through 'rack-protection' first. Homokov was first to state, this was really a black-swan type bug which 99.9% of the time makes it into production. Apparently, they were doing the "right th…

The parent meant "This probably could've been prevented by disallowing non-number inputs" in SDK libraries. Yes, if SDK would cast everything to digits it wouldn't be possible. It is also quite obvious security-in-depth for a 2FA API. Now they do it. *HomAkov

:-( Sorry, typo. And HN won't let me edit now, grrr!

Re: Slack was hacked

#426

Post by jsmeaton »

jacquesm wrote: post #204
buttsex wrote: post #201

Earlier quoted context omitted.

They archive chat messages so that you can search through them later.

That alone would be a great reason not to use them.

https://slack.zendesk.com/hc/en-us/articles/203457187-Settin...

It's configurable for paid accounts, and can be set as low as one day. However, one of the best features of slack (and products like slack) is message history and search. Otherwise, IRC isn't all that different (WRT messaging).

Re: Slack was hacked

#427

Post by Zombieball »

Someone1234 wrote: post #327
rnovak wrote: post #299

Earlier quoted context omitted.

Once you use Encryption, it's no longer pepper, it's encryption with weak key storage (hard-coded). At that point, genuinely, why not just follow best practices and store the key securely (e.g. using an HSM)?

Because nobody knows how to do that and it is likely extremely expensive by every metric. And, no, I am not being facetious by saying nobody knows how to do that. I am being quite literal. Have you ever done that? Do you know how? Do you even know what you would google to figure out how? I'm yet to see my favorite library of course's documentation on a HSM. How do you do that in e.g. PHP with MySQL? MVC with MS SQL?…

I think AWS provides both key management services as well as cloud hsm.

I have not used either myself, but I would imagine the documentation is quite good.

Re: Slack was hacked

#428

Post by kannonboy »

mirashii wrote: post #104

Surprisingly, they didn't force a password reset on all accounts. Even though the passwords are hashed and salted, targeting a couple users and checking for weak passwords can now be done offline, with no rate-limiting or network calls necessary. In breaches like these, it should still be mandatory to issue service wide password resets. Anything less is unacceptable.

I was curious about this too. I don't use Slack, do they enforce a password complexity and use a bcrypt work factor high enough to justify not requiring a reset?

Re: Slack was hacked

#429

Post by count »

rudolf0 wrote: post #2

It's refreshing to 1) see a breach notification including the actual password hashing algorithm, 2) see they're using a strong one like bcrypt (presumably with a reasonable cost factor). Regardless, this is an example of why cloud communication (and ticketing and database off-loading [see MongoHQ] and...) systems probably won't ever become commonplace in most of the government space and the finance and health sectors…

If you haven't been paying attention, the US Govt (including the DoD) is moving out in the commercial cloud space in a big way.

Re: Slack was hacked

#430

Post by ncza »

LaurentVB wrote: post #243
jacquesm wrote: post #204

Earlier quoted context omitted.

That alone would be a great reason not to use them.

It's also a great reason to use them, isn't it? Your searchable chat history basically becomes the knowledge base of your company.

To me, that is something that you should keep internal, on internal systems with vetted free software.
Post reply on HN