Slack was hacked • Hacker News Board

Re: Slack was hacked

#441

Post by polyfractal » Sat, Mar 28, 2015, 12:52 AM UTC

newobj wrote: post #423

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.

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.

It would remove a lot of nice search features, however. If you just index tokens without positional information, you have a much harder time performing phrase matching. If you include positional information, you can probably crack the encryption because some tokens are statistically more likely to appear next to each other than others.

If you index shingles (phrase chunks) instead, you lose out on sloppy phrases...you can only match exact phrases. I imagine you can perform a similar statistical attack too.

Hell, just getting the term dictionary would probably allow you to reverse engineer the tokens, since written language follows a very predictable power law.

Hashing also removes the ability to highlight search results, which significantly degrades search functionality for an end user.

Basically, yes, you can do search with encrypted tokens...but it will be a very poor search experience.

Re: Slack was hacked

#442

Post by chatmasta » Sat, Mar 28, 2015, 1:08 AM UTC

rubyn00bie wrote: post #434

chatmasta wrote: post #369

If I were Slack, I would pretend to get hacked. Slack critics often point to its centralized architecture as a weak point, because rational corporations should not entrust security of their internal communications to a third party. Particuarly when that third party aggregates communications of its many clients, it becomes a target of hacking. Why hack a single corporation when you can hack Slack and get all their cli…

Note: My comments and thoughts are geared specifically to Slack or a very similar entity (tech start up, which sells a service). I strongly disagree with this idea: "Now that Slack has captured the low-hanging-fruit of the market, it needs to pick the high-hanging-fruit. The most profitable clients for slack will be the largest, conservative, enterprise clients who will join the Slack platform and then never leave. T…

This is why humans invented contracts. No two businesses enter into a $1 million deal together without a contract to describe the expectations of the partnership. For this reason, no service provider should be "surprised" by the level of commitment required to fulfill its end of an enterprise deal, because all the expectations should be in the original contract (literally, the service level agreement). There are no surprises.

Also, (pedantic) in your example, $1m a year is beyond sufficient to cover the costs of two engineers and some support staff. Besides, realisically the biggest support issues will be problems with availability, which presumably will be network wide and not limited to one client. I highly doubt slack needs to hire dedicated engineers for each new enterprise client. Instead they can reallocate existing engineers when needed, and grow their total labor capacity as it becomes constrained.

Re: Slack was hacked

#443

Post by freehunter » Sat, Mar 28, 2015, 1:18 AM UTC

sounds wrote: post #371

sbov wrote: post #315

Earlier quoted context omitted.

I have a friend who works security, previously for the government, and now for Visa. In his opinion: if you haven't been hacked, you just aren't an interesting enough target for the right people. I don't know how common this line of thought is in security. But if it is common, then if you're a small company, aren't you better off not hosting my stuff at these large companies, because it's putting information you coll…

I think a more correct assessment would be: If you think you haven't been hacked, you probably have (or you are so small that you may have only been probed by bots). If you haven't actually been hacked yet, it is only a matter of time. Ideally you start designing security layers now, before you are compromised.

As the famous quote goes: there's two types of companies - those who have been hacked and those who will be. Actually, there is a third kind: those that will back hacked again.

Re: Slack was hacked

#444

Post by scintill76 » Sat, Mar 28, 2015, 1:21 AM UTC

scintill76 wrote: post #165

johannh wrote: post #91

Earlier quoted context omitted.

https://en.wikipedia.org/wiki/Egg_of_Columbus

Neat story, but I don't see the analogy. OP says he/she doesn't see any innovation, not "this innovation is obvious". At least tell us an egg or two that Slack cleverly stands on end.

Now it occurs to me I may have been making a distinction (about the nature of innovation) where there arguably isn't one. Still, I think it's fair to ask exactly what Slack is doing right. If there is a real innovation, someone should be able to tell us (there've been some good responses); otherwise it's just lucky network effects or a fad.

Re: Slack was hacked

#445

Post by ufo » Sat, Mar 28, 2015, 1:44 AM UTC

mbrubeck wrote: post #384

worklogin wrote: post #309

Earlier quoted context omitted.

The question is not irrelevant. It's blindingly obvious that salt+pepper protects against DB-only attacks. Injection that does a DB dump, or vulnerabilities in the DB server that don't exist in the app. So yes, S+P protection won't save you if the app server is completely compromised, but it does protect you in case DB only is. And the ability to S+P seems pretty simple to implement and document. Why is everyone pani…

I've already seen one person in this thread taking "S+P" literally, and suggesting `bcrypt(cost, salt + pepper, password)`, which has a very obvious and critical problem. Other "peppering" schemes in the comments here also have significant weaknesses. So yes, even a simple idea like this is easy to botch in implementation -- even if the implementation is just a one-line change!

What is the problem? Does bcrypt truncate "salt+pepper"?

Re: Slack was hacked

#446

Post by _wp3r » Sat, Mar 28, 2015, 1:45 AM UTC

varikin wrote: post #160

joshstrange wrote: post #142

Earlier quoted context omitted.

> There is no reason why you can't take 10min to setup a IRC with SSL on your own For the VAST majority of people this would not take just 10 min. Not only would I first need to research the different IRC servers out there but I'd have to get a server to install it on (which is not the fastest processes where I work). Then I need to get an SSL cert (which is like pulling teeth here) unless I want to use self-signed a…

And then you have you setup something like ZNC so people can catch up to history while offline.

Thanks for the ZNC ref.

Re: Slack was hacked

#447

Post by homakov » Sat, Mar 28, 2015, 1:55 AM UTC

tracker1 wrote: post #422

homakov wrote: post #411

Earlier quoted context omitted.

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.

No, if your computer is infected (=monitoring software) there's no difference because token is transaction-agnostic. 2fa won't help

Re: Slack was hacked

#448

Post by zaroth » Sat, Mar 28, 2015, 1:58 AM UTC

cryptbe wrote: post #380

zaroth wrote: post #323

Earlier quoted context omitted.

The best summary I've read recently on peppering was posted to the PHC list by Thomas Pornin last week. It's worth quoting in its entirety; Adding an additional secret key can be added generically, in (at least) four ways, to any password hashing function: 1. Store: salt + HMAC_K(PHS(pass, salt)) 2. Store: salt + PHS(HMAC_K(pass), salt) 3. Store: salt + AES_K(PHS(pass, salt)) 4. Store: salt + PHS(AES_K(pass), salt) I…

> 3. For some historical reasons, many people feel the need to change keys regularly. This is rather misguided: key rotation makes sense in an army or spy network where there are many keys, and partial compromissions are the normal and expected situation, so a spy network must, by necessity, be in permanent self-cleansing recovery mode; when there is a single key and the normal situation is that the key is NOT compro…

Given a salted hash is being encrypted, who needs a nonce? The salt's already taken care of that, right?

Also, if you have 4 billion hashes stored, and you rotate the key, and you still have 4 billion hashes stored... What's changed? You would need a key ring or derivative keys I guess but I think this is actually a case where ECB does the job.

But I guess we've now proven the point that even a pepper is non-trivial.

Re: Slack was hacked

#449

Post by jessaustin » Sat, Mar 28, 2015, 2:13 AM UTC

CameronBanga wrote: post #344

Sami_Lehtinen wrote: post #260

Earlier quoted context omitted.

I still wonder what value does password leak have. I changed my password, my old password was: DV1wn3yHk6W-8m9lZNo_ now you all know it, so what? I don't care, I believe you don't care either. On the other hand, if they were after valuable data, they had access to database and the got what they wanted. So the password is much less valuable than the other stuff they might have wanted. Like chat logs which might contai…

Because I'm sure everyone uses a long, complex, and unique password on Slack. So nothing to worry about, everyone.

If Slack data isn't important, then it would have been fine to use one's default low-value password, right? So now some attacker has thousands of copies of the word "dragon".

Re: Slack was hacked

#450

Post by ircmaxell » Sat, Mar 28, 2015, 2:17 AM UTC

rudolf0 wrote: post #255

specialk wrote: post #182

Earlier quoted context omitted.

Is there any significant evidence that peppering passwords helps? I've seen arguments for and against peppering out on the big bad internet. Everyone has opinions but there are few people's opinions about crypto that I actually trust. The best article I've seen against this technique is by ircmaxell [0]. Nicely summed up in this sentence "It is far better to use standard, proven algorithms then to create your own to…

A properly implemented, simple pepper can only help password security and can't hurt it. Obviously you first must be using a good, slow algorithm (bcrypt, scrypt, or PBKDF2 with high work factor), but a pepper will only help you. (Let's assume the pepper is an AES key which all hashes are encrypted with.) Yes, many times a dedicated attacker who has read access to your database will also have read access to your sour…

> A properly implemented, simple pepper can only help password security and can't hurt it.

Well, yes. But what is the definition of "properly"? There are definitely constructions of "pepper" that look simple, but drastically hurt overall security:

    bcrypt(hmac(password, key), salt)

If hmac returns raw bytes, you're in real trouble: http://blog.ircmaxell.com/2015/03/security-issue-combining-b...

It's sort of like the difference between birth control and counting based contraceptive methods (Standard Days Method). Executed perfectly, they are equally as effective. But with a slight error, one stays roughly as effective (losing maybe 5 to 10% effectiveness overall) while the other drops drastically (down to 10 to 20% effectiveness).

Considering using encryption is as effective as using a pepper, and it's less prone to weakening the core password hash, I suggest using encryption instead of peppers.