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

401–410 of 526 posts

Re: Slack was hacked

#401

Post by ntucker »

simcop2387 wrote: post #391
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…

That's a really interesting idea. I was thinking it might have performance implications but I think that will only apply to the password validation. How do you make sure the mapping key doesn't cause collisions when you roll it to reset everyone's passwords?

That's a great point about rolling the mapping key. We would likely be dropping all the rows in the password hash table for such an extreme event anyway, though, since otherwise there's no way to garbage collect the orphaned ones.

Re: Slack was hacked

#402

Post by homakov »

zaroth wrote: post #365
yellowapple wrote: post #358

Earlier quoted context omitted.

Huh. Well now I know. Thanks! Amazing what you can do with improperly-implemented input sanitation :) This probably could've been prevented by disallowing non-number inputs, no?

"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

Re: Slack was hacked

#403

Post by mbrubeck »

FiloSottile wrote: post #210
stiff wrote: post #170

Earlier quoted context omitted.

Please do not do it: http://stackoverflow.com/questions/16891729/best-practices-s...

That sounds like fuzzy scare-mongering to me. 1) You should not invent your own algorithm. That's a given. That's why you use bcrypt/scrypt. 2) It's not abusing the algorithm, it's using a longer salt (in the concatenation case). 3) There's nothing wrong with nesting algorithms (just remember to use hex/base64 encodings, not binary). For example Facebook passes passwords through half a dozen algorithms. They call it…

> 2) It's not abusing the algorithm, it's using a longer salt (in the concatenation case).

But PBKDFs like bcrypt and scrypt are not designed to keep the salt parameter secret; in fact they assume the attacker knows the salt. And so if they happen to reveal the salt to the attacker, this is not considered a bug in the algorithm and won't have been flagged or fixed by cryptographers.

Re: Slack was hacked

#404

Post by mirashii »

ntucker wrote: post #337
FiloSottile wrote: post #130

I hate to be the negative guy, and they were hashing passwords better than 90% of the sites, but it would be SO easy to completely neutralize password leakage when the attacker only has access to the database. https://blog.filippo.io/salt-and-pepper/ tl;dr: Hardcode a second salt in your application code or in an environment variable. Then a database dump is not enough anymore to do any kind of bruteforce. It's simpl…

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.

Re: Slack was hacked

#405

Post by NeutronBoy »

smt88 wrote: post #133
mateuszf wrote: post #28

Earlier quoted context omitted.

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

If anyone from Slack is reading this, the encryption should be an option, even if it means disabling or substantially slowing the search feature.

If they encrypted it, Slack would have to hold the key, so that all users in an org can then read existing messages.

Re: Slack was hacked

#406

Post by halayli »

nvk wrote: post #19

Host your own IRC if you care about the privacy and security of your communication. There is no reason why you can't take 10min to setup a IRC with SSL on your own. Yes, Slack is awesome, lots of features, but it's not yours!

With this logic, don't use any SaaS service then.

Re: Slack was hacked

#407

Post by flurdy »

cpeterso wrote: post #252
MarkyC4 wrote: post #206

Earlier quoted context omitted.

The fact that the pepper can't be changed/rotated far outweighs any upsides

You can change your pepper by double-peppering your existing password database: scrypt(scrypt(scrypt(scrypt(password, salt), pepper2013), pepper2014), pepper2015) https://blog.filippo.io/salt-and-pepper/

Sounds like a maintenance nightmare. Need to ensure you keep your tongue straight when partitioning or restoring databases, migrating/splitting to new apps etc.

Re: Slack was hacked

#408

Post by mirashii »

BrainInAJar wrote: post #343
dragonwriter wrote: post #317

Earlier quoted context omitted.

That's not particularly weak as proof to the person who controls the DB that you have access to the phone, which is what the device factor of a 2FA scheme is intended to prove, since you have to have access to either the DB or the phone to get the key. Conversely, SMS's weakness is in the communication channel, which can be compromised without compromising the things for which the factor is intended as proof.

Phones get hacked too. If you ever access a site with your phone, it's not two factor auth. Malware can read your 2FA key and read your password as you type it in.

And thus why we have Yubikeys and other hardware tokens.

Re: Slack was hacked

#409

Post by homakov »

larsiusprime wrote: post #6

Slack encourages 2-factor authentication: > Download and install either the Google Authenticator or Duo Mobile apps on your phone or tablet. Hey Slack, I don't have a smartphone. What am I supposed to do?

You can use http://gauth.apps.gbraad.nl/ on another computer or on same machine (wouldn't protect if computer is stolen, otherwise the same)

Re: Slack was hacked

#410

Post by elchief »

_trb_ wrote: post #397
elchief wrote: post #50

Assuming (no evidence, it's just very common) that this was a SQL Injection, here are some ways to protect yourself: * Use http://en.wikipedia.org/wiki/Database_activity_monitoring . If you don't list users on your site and you get a query that would return more than one user record, it's a hacker * Add some http://en.wikipedia.org/wiki/Honeytoken s to your user table, and sound the alarm if they leave your db * Use…

The most important thing to stop sql injection is to validate your parameters on the server side.

Yes, but:

1. Not all SQL statements are parameterizable (dynamic identifiers vs literals)

2. Stopping SQL injection doesn't stop Insecure Direct Object References

3. Developers make mistakes

4. Plugins are a risk (example: http://www.zdnet.com/article/over-1-million-wordpress-websit...)

For parameterization to work you need to be perfect, always. My suggestions are for when someone else fucks up.

Post reply on HN