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

451–460 of 526 posts

Re: Slack was hacked

#451

Post by girvo »

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

Christ you weren't kidding about it being expensive. Amazons Cloud HSM is $5k upfront and $1.8/h thereafter, which is completely infeasible for the agencies I've worked at. A shame, I'd love to do the right thing there :(

Re: Slack was hacked

#452

Post by ircmaxell »

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…

Well, let's imagine an attack scenario.

As an attacker, I get SQL access to your DB (meaning no access to the encryption key). I then download the user names, and the hashes. I then attack the hashes offline. I recover only the weakest few percent (since you're using bcrypt). But since the weakest few are those most likely to be re-used (both by different users and by a single user across sites), they are going to be both more valuable to me and easier for the next steps:

Then, I take the highest frequency passwords and the user table, and I start validating them online in your system. Now if I do that too quickly, you'll notice and I'll be shut down. And if I do that all from the same IP, I'll be shut down.

But what if I had a botnet that I could distribute the load across. What if I kept my request rate small enough to stay under the radar of even a moderate scale system.

I would expect to start seeing meaningful results within days.

If you had 1000 users, then I could surmise that you don't have much traffic, and hence keep the request rate down to perhaps 100 per day. In 10 days I'd have at least a few u/p combinations that I know for a fact worked.

If you had 1000000 users, I could ramp it up quite a bit higher, to perhaps 1000 or 10000 per day.

And since they all came from separate IP addresses, it could be rather difficult for you to tell an attack was going on unless you were looking specifically for it.

Does that mean you should stop immediately? No. It's not that bad of a scheme. But be aware that it doesn't give you (or your users) the level of protection that it may look like on the surface.

Re: Slack was hacked

#453

Post by ssalazar »

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!

> security of your communication

Unless one is a security expert I highly doubt that a home-grown IRC system will be more secure than a professionally-run operation, other than simply being more obscure and not on a hacker's radar.

Re: Slack was hacked

#454

Post by MarkMc »

baby wrote: post #186
stiff wrote: post #170

Earlier quoted context omitted.

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

so the downsides are "it's not maintanable" and "don't roll your own crypto". I think they are negligible compared to the upsides.

I wouldn't say negligible, but rather not slam-dunk convincing

Re: Slack was hacked

#455

Post by aianus »

sergiotapia wrote: post #184
rdl wrote: post #29

I wonder how many people send sensitive credentials or other operational details through Slack. It'd definitely be a target (along with mail systems) if you want to attack better-protected customer systems.

I think that's the point of slack, being able to communicate sensitive information. Where would you relay something like an Amazon AWS Access Key?

PGP encrypted email.

Re: Slack was hacked

#456

Post by matdrewin »

So a database gets hacked, they add MFA and people are arguing about peppering passwords. What about the part on how the hackers got access to the database in the first place?

Passwords are not the only sensitive info that can be stored in a database and most of the time, that info isn't hashed.

Re: Slack was hacked

#457

Post by typedweb »

JimmaDaRustla wrote: post #256
typedweb wrote: post #235

Earlier quoted context omitted.

It's reversing the encryption, not the hash.

Where in the original example was encryption involved? The salt and pepper were only ever used in a hashing algorithm.

The pepper is the key to the encryption, not a hashing algorithm.

Re: Slack was hacked

#458

Post by iopq »

ufo wrote: post #445
mbrubeck wrote: post #384

Earlier quoted context omitted.

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"?

Because the salt is in the hash!

$2a$12$GhvMmNVjRW29ulnudl.LbuAnUtN/LRfe1JsBm1Xu6LE3059z5Tr8m

$2a means it's using bcrypt version 2a

$12 means 12 rounds

GhvMmNVjRW29ulnudl.Lbu is the salt

AnUtN/LRfe1JsBm1Xu6LE3059z5Tr8m is the checksum

Re: Slack was hacked

#459

Post by thedufer »

Someone1234 wrote: post #348
pc86 wrote: post #268

Earlier quoted context omitted.

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.

By that logic, every extra character you concat onto a salt is also "rolling your own crypto." For example if my salt was CrytoRandom(10), and you increase it to CrytoRandom(15) you've just "rolled your own crypto" according to you. If that is not the case then explain the difference between CryptoRandom(15) and CrytoRandom(10) + CryptoRandom(5) (longer salt Vs. salt+pepper). There's a lot of people spreading FUD ("i…

I'm no security expert, but there are some obvious problems with concatting salt + pepper. For example, most hash libraries include the salt in the output so that you only have to store a single string (also encoded in the output would be the hash algorithm and a few input parameters). So now you've likely revealed your pepper in the DB. Oops! So much for extra security.

But that's not all! Hash algorithms are written assuming the salt is random, and now I have millions of hash outputs in which the last X bytes of the salt are shared. Have you proven that this doesn't increase the attack surface? It certainly sounds like it might. This is exactly the type of side-channel attack that tends to break crypto, and you're giving it away for free.

Re: Slack was hacked

#460

Post by thedufer »

scrollaway wrote: post #140
elchief wrote: post #79

Earlier quoted context omitted.

It's the most common vulnerability. https://www.owasp.org/index.php/Top_10_2013-A1-Injection

It's the most common vulnerability on the web . It's certainly not the most common vulnerability in projects built under popular non-php frameworks. Under that model, it's harder to create a situation where a SQL injection is possible than not. Edit: Slack's in PHP, I thought it was in RoR for some reason. Oops.

Additionally, Slack has had SQLi attacks found against it in the past, which is proof that they aren't defending against it systematically.
Post reply on HN