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

261–270 of 526 posts

Re: Slack was hacked

#261

Post by jedberg »

rudolf0 wrote: post #244
jedberg wrote: post #138

Earlier quoted context omitted.

I think this just goes to show exactly why these systems will become more commonplace. There are only so many security experts to go around. Having all the very best concentrated on a smaller set of services seems like it makes more sense than trying to get a security expert for every service.

You have to look at it from a regulatory and compliance standpoint. While I agree from a technical standpoint that the average company's data is probably going to be safer at Slack than in some internal system, the accountability risk is just too high. You can't prove your cloud provider is using security best practices, while you theoretically can prove (or disprove) the same internally. Few companies do proper audi…

> You can't prove your cloud provider is using security best practices

But you don't have to. They do. Look at Amazon. They publish their security audit each year, and now every company that uses them doesn't have to do their own audit. They can point their auditor at Amazon's report and say "see our datacenter passes".

Also, do you do a security review on your power company, or do you assume they've done it?

Re: Slack was hacked

#263

Post by __david__ »

modeless wrote: post #195
cheshire137 wrote: post #151

Looks like they require Google Authenticator or Duo Mobile app to do two-factor auth. I'm not interested. Why can't they be like Github and just send me a text message? I don't want a dependency on some other company's product to make Slack more secure.

I hate to break it to you but SMS is some other company's product. Google Authenticator is not a cloud service; it's simply an implementation of the TOTP RFC and there are others available if you hate Google so much that you don't trust a purely local app written by them.

An open source one at that!

https://github.com/google/google-authenticator/

Re: Slack was hacked

#264

Post by specialk »

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…

Hey thanks for the long response. I totally get the premise of peppering I think my problem is with this sentiment "A properly implemented, simple pepper can only help password security and can't hurt it".

From all the advice I've read security and crypto they don't work like that. The assumption is the other way around. A properly implemented, simple pepper can only hurt password security until proven otherwise by rigours testing and analysis.

Time and time again we read stories of a tiny implementation detail that created a sly and subtle vulnerability that simehow leaks information about original plain text by interrogating the cipher text.

bcyrpt with a large work factor and a per user salt is a PROVEN method to prevent attackers learning the plain text. Until I see evidence from a trusted cryptanalyst I'm not going to roll my own by adding in pepper they didn't plan on being there.

EDIT: sorry let me make my point a little clearer. In the event that the hacker can access the filesystem or memory -- whereever you store your pepper -- could the hacker use the pepper and an implementation detail in the peppering technique to learn information about the plaintext or the salt? This question is what needs to be answered by qualified cryptanalysts before developers start using peppers wide-spread in my opinion.

Re: Slack was hacked

#266

Post by [deleted] »

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/

[deleted]

Re: Slack was hacked

#268

Post by pc86 »

scott_karana wrote: post #146
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…

I don't see that as a negative suggestion: that's a fantastic idea, and for all we know, a Slack employee will read your post, and make their hashing even better. :-)

By not implementing the suggestion, presumably.

This is rolling your own crypto, which is universally bad. To paraphrase Bruce Schneier, anyone can write a crypto algorithm they themselves can't break. Peppering a password hash destroys any future maintainability.

Re: Slack was hacked

#269

Post by JimmaDaRustla »

randunel wrote: post #153
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…

I generally disagree with hardcoded salts, you should assume everything is compromised in a successful attack. But I'm actually commenting here because I don't see how you can retroactively apply the second salt to a hashed string. Could you please elaborate or share a link? Later edit: I'm referring to your example in your link: salt = urandom(16) pepper = "oFMLjbFr2Bb3XR)aKKst@kBF}tHD9q" # or, getenv('PEPPER') hash…

Your question depends on your definition of retroactively.

I think the article's context is if you don't currently use a pepper, you can easily add one and update all of your password hashes in the database.

Re: Slack was hacked

#270

Post by jturolla »

racontour wrote: post #166

My team logs with our Google accounts. It's not addressed in the disclosure, but should we be deauthorising Slack. Have our tokens been breached?

Possibly no because the token is app-specific and it's not likely that the slack key was compromised, but I also agree that they should have disclosed that.
Post reply on HN