Slack was hacked • Hacker News Board

Re: Slack was hacked

#471

Post by Dylan16807 » Sat, Mar 28, 2015, 5:08 AM UTC

eropple wrote: post #468

karl_gluck wrote: post #462

Earlier quoted context omitted.

No, his reasoning probably isn't. But without putting words in his mouth, there is this quasi-religious "thou shalt not talk about cryptography" attitude among programmers like crypto is literally voodoo magic. The appeal to experience is an incredibly frustrating part of this. It's like people are willfully ignorant and forcing those of us who may not be experts but also want to have an intelligent discussion to pre…

It's not "thou shalt not talk about cryptography." It's "cite your sources."

If you're pointing out a gaping flaw, you don't need a source. If you're suggesting a standard security measure, you don't need a source.

To insist on something novel, yes you want a source.

Re: Slack was hacked

#472

Post by Dylan16807 » Sat, Mar 28, 2015, 5:19 AM UTC

minitech wrote: post #318

FiloSottile wrote: post #197

Earlier quoted context omitted.

In incident response you assume the worst, but in system design you try to minimize impact of common attacks like SQL injection. There's nothing wrong with nesting algorithms (see the Facebook hash onion), so you can use the following scheme: bcrypt(bcrypt(password, salt), pepper) And do a pass on all your database entries like bcrypt(old_hash, pepper)

> There's nothing wrong with nesting algorithms This is really vague. What kind of algorithm? With itself, or just anything inside anything else? Passing the raw output of any common cryptographic hash (SHA-x) to bcrypt, for example, completely destroys its security, as bcrypt input is null-terminated. (What happens when you nest DES in A*, anyway?)

Obviously you have to use type safety. You can't cast a binary string to a null-terminated string, you have to convert. That's a problem unrelated to hashing.

I would avoid using any particular symmetric algorithm twice. Otherwise if you have an example of algorithm chaining that can weaken security beyond the weakest link, I would love to see it. (Not that I think nesting is a great idea.)

Re: Slack was hacked

#473

Post by ntucker » Sat, Mar 28, 2015, 5:37 AM UTC

ircmaxell wrote: post #452

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…

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…

So after a breach, you have our (currently) 2 million hashes, and let's say you recover only the weakest few percent of the passwords, which is 60000 known good passwords. Instead of owning 60000 accounts now, you have 60000 passwords, each of which is going to require on average one million attempts before you guess the correct username. Is this not self-evidently better?

Re: Slack was hacked

#474

Post by lawnchair_larry » Sat, Mar 28, 2015, 6:09 AM UTC

rattray wrote: post #45

How does one discover that they were hacked? The post states that the breach occurred during February, and this is the end of March... did it just take them a long time to react and write a post about it, or did they likely discover after the fact? If so, how?

Usually, if the attacker doesn't dump your info or otherwise blatantly advertise themselves, the FBI tells you.

Re: Slack was hacked

#475

Post by homakov » Sat, Mar 28, 2015, 6:37 AM UTC

This is why you need to hash reset tokens too

http://sakurity.com/blog/2015/03/27/slack_or_reset_token_has...

Re: Slack was hacked

#476

Post by vayarajesh » Sat, Mar 28, 2015, 6:45 AM UTC

What tangible things were hacked? apart from password was the communication history, files share etc were hacked too? We sometimes share code blocks and zip files etc..

Re: Slack was hacked

#477

Post by tempestn » Sat, Mar 28, 2015, 6:46 AM UTC

mirashii wrote: post #437

kannonboy wrote: post #428

Earlier quoted context omitted.

I was curious about this too. I don't use Slack, do they enforce a password complexity and use a bcrypt work factor high enough to justify not requiring a reset?

There isn't a work factor high enough or password complexity high enough that it doesn't justify a reset, in my opinion. People will use bad passwords, and we can't really stop that. Allowing offline attacks against them will never be okay.

I'm definitely not an expert, but my understanding is that a per-user salt, which Slack was using, protects against brute-forcing bad passwords. So assuming a reasonable work factor, it really should be computationally unfeasible to retrieve these passwords. That said, I'll change mine, because why not.

Re: Slack was hacked

#478

Post by grey-area » Sat, Mar 28, 2015, 6:49 AM UTC

homakov wrote: post #475

This is why you need to hash reset tokens too http://sakurity.com/blog/2015/03/27/slack_or_reset_token_has...

In devise at least reset tokens expire, so they'd need to have been set in the last day to be useful, which narrows that attack considerably doesn't it?

Re: Slack was hacked

#479

Post by homakov » Sat, Mar 28, 2015, 7:19 AM UTC

grey-area wrote: post #478

homakov wrote: post #475

This is why you need to hash reset tokens too http://sakurity.com/blog/2015/03/27/slack_or_reset_token_has...

In devise at least reset tokens expire, so they'd need to have been set in the last day to be useful, which narrows that attack considerably doesn't it?

Why wait and not use it right away? If you have read access now you can exploit now.

Re: Slack was hacked

#480

Post by homakov » Sat, Mar 28, 2015, 7:19 AM UTC

grey-area wrote: post #478

homakov wrote: post #475

This is why you need to hash reset tokens too http://sakurity.com/blog/2015/03/27/slack_or_reset_token_has...

In devise at least reset tokens expire, so they'd need to have been set in the last day to be useful, which narrows that attack considerably doesn't it?

BTW actually new version of devise hashes tokens.