Interesting that the title says "March 2015 Security Incident" but it turns out it was in February. Also interesting they don't say which days in February.
Slack was hacked
241–250 of 526 posts
Re: Slack was hacked
#242Earlier quoted context omitted.
I don't think IRC quite offers the feature set that Slack users would be expecting, does it?
I'm not talking about users who care about custom Emojis and animated gifs. That's why I said - let the mere mortals use it; we can do better!
Is this actually the sort of people that get attracted to HN?
Thinking of others as "mere mortals" and yourselves as gods?
Sad picture.
Re: Slack was hacked
#243Earlier 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.
It's also a great reason to use them, isn't it?
Your searchable chat history basically becomes the knowledge base of your company.
Re: Slack was hacked
#244It'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…
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 auditing, reviews, and pentests, but they have the capability to do so.
Re: Slack was hacked
#245Why do I have to install Google Authenticator some sort of other app for 2factor here? Why can't you send me a text like everyone else does? EDIT: Slack responded that they do not support SMS yet .
You can write your own TOTP application - its open source and works offline, you don't need Google Authenticator, there are dozens of applications available.
Re: Slack was hacked
#246Earlier quoted context omitted.
> 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. I agree. We might not like rolling out our own instances, but it prevents hackers from being able to grab ALL THE DATA in one fell swoop. It really amazes me that some EHR systems hav…
It's heartening to me. I've seen small practices with atrocious IT security. No WAY is self-hosted (for the thousands of small practices with maybe a couple of clueless help-desk types) even a billionth as secure as a professionally secured cloud service. Also, "cloud" for services like this means "your own private instance of the software running in a private VM in our datacenter" not "your own customer_id in a shar…
OTOH, if you're small, you are not as interesting a target as a huge cloud provider that hosts everyone. Which means, while small practice's security should be good, it doesn't actually have to be as good as the big cloud behemoth.
It's why your gmail account is more likely to get hacked than my piddly self hosted imap server. Google's network security is unarguably better than mine, but you are never going to social engineer your way into changing my password, which is actually doable with gmail (happened to my sister in law).
Re: Slack was hacked
#247Dear All - Your passwords should be considered compromised.
Hashing is merely a deterrent, it does not prevent cracking.
Re: Slack was hacked
#248Earlier quoted context omitted.
I hate to suggest that your observation is wrong, but 16 rounds should take orders of magnitude more time than 1ms. 16 rounds using Mindrot's Java implementation of BCrypt on my admittedly old 2009-vintage i7 consumes 6.3 seconds to hash a 10-character password.
That's because you're conflating "rounds" with "work factor". "Work factor" is actually 2^rounds, you're using 65536 rounds. Try 4.
Thank you for pointing that out. I suspect many of us in this thread are referring simply to the single parameter to BCrypt.gensalt as the "work factor" or "number of rounds" interchangeably. And you're right, the work factor is what is actually provided to gensalt.
Nevertheless, in all implementations I am aware of, the default for that parameter is 10. And earlier, you wrote:
> If they used ten rounds, it's dire, and just saying "bcrypt" doesn't say much unless you also specify the number of rounds.
tedunangst and I both assumed you were referring to the default 10 work factor of BCrypt and were calling it "rounds" as many of us are doing.
The obvious question that tedunangst is asking (and others in this thread) is whether a work factor of 10 is considered too low.
Re: Slack was hacked
#249Earlier quoted context omitted.
Yes? 16 rounds take 1ms on my (old) machine. In Python, no less.
10 is obviously the log rounds number. It's not even a power of two! Nor has any implementation of bcrypt even supported such a low number.
How is it "obvious" when the unit is rounds? Ten was an example, round to 16 if you like. The point is still the same, using few rounds is a risk.
Re: Slack was hacked
#250I 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…
Please do not do it: http://stackoverflow.com/questions/16891729/best-practices-s...
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)
If you store passwords instead as:
encrypt(bcrypt(password, salt), pepper)
The rest of it is more of a qualitative question -- 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?