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

481–490 of 526 posts

Re: Slack was hacked

#481

Post by rnovak »

worklogin wrote: post #310
EugeneOZ wrote: post #300

Earlier quoted context omitted.

Recommendations related to Security, should start from words "I'm {name}, known expert in IT Security, my works can be found here: {url}". Otherwise such advices should be ignored.

Could not disagree more. Perhaps one should use their own reasoning and the ability to peer-review in conjunction with 'appeal to experience' rather than shut out discussion.

I might get down-voted for this, but I'm going to clarify my position a little.

I'm not advocating for shutting-down anyone's discussion. What I, and probably others, are advocating for, is only putting in trust in proven crypto.

The parent comment to all of this basically has the form: "Wow, you could totally solve your password hashing (that isn't broken) by using this scheme I came up with. No one else has looked at it, but boy, it looks difficult to crack to me."

There's a complete difference between that comment, and many of the others: "how about if we do X", and I believe the second is completely valid for discussion; As LONG as you include relevant experts in that discussion.

Joe and Bob talking about encryption isn't very useful unless Joe &| Bob are trained in cryptography and have experience in applying that crypto in the real world.

Down-vote all you want, but that's my view-point at least.

Re: Slack was hacked

#482

Post by zkhalique »

minitech wrote: post #312
curiously wrote: post #92

is there anything that slack does you can't do with skype? I find lot of these new startups are just creative ways of reinventing the wheel and convincing you need it to appear cool & hip....kind of like fashion for high schoolers

Skype is really bad for text chat. - It is closed-source, obfuscated, and untrustworthy overall ( https://www.eff.org/secure-messaging-scorecard ). - The supported (Windows and Mac) versions have obnoxious ads, and the Linux version is buggy and 32-bit-only. - Since it’s P2P-ish (which makes sense for audio and video calls), you can’t send a message to someone who’s offline and expect them to be notified (say, via e-…

- It is closed-source, obfuscated, and untrustworthy overall (https://www.eff.org/secure-messaging-scorecard).

and Streak is open source?

- The supported (Windows and Mac) versions have obnoxious ads, and the Linux version is buggy and 32-bit-only.

I have the Mac version of Skype, where are the ads?

- Since it’s P2P-ish (which makes sense for audio and video calls), you can’t send a message to someone who’s offline and expect them to be notified (say, via e-mail, which Slack does). Worse, if you go offline, they won’t get it until you’re both on at the same time!

This part is true, it's pretty limited.

- Files shared on Skype don’t last. You have to use an external service.

Skype is more P2P

- There is no permanent archive; logs are client-side and easy to lose. (You can get messages that are a few days old from peers, but there’s a limit – I don’t know exactly where.)

Skype is for encrypted P2P communication.

Why not just use IRC?

Re: Slack was hacked

#483

Post by grey-area »

homakov wrote: post #479
grey-area wrote: post #478

Earlier quoted context omitted.

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.

Oh I see - you mean they have read access, then trigger password reset, then use the token straight away? That does mean they'd be firing off emails which would alert users though.

Re: Slack was hacked

#484

Post by homakov »

grey-area wrote: post #483
homakov wrote: post #479

Earlier quoted context omitted.

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

Oh I see - you mean they have read access, then trigger password reset, then use the token straight away? That does mean they'd be firing off emails which would alert users though.

It would. They didn't do it probably because they didn't try this trick. But they could i think.

Re: Slack was hacked

#485

Post by mirashii »

tempestn wrote: post #477
mirashii wrote: post #437

Earlier quoted context omitted.

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.

A per-user salt doesn't prevent brute forcing bad passwords. The purpose of a per-user salt is to prevent brute forcing all of the passwords simultaneously. Without it, you could just hash a password once and check against all the passwords. With the salt, you have to hash each guess for each user. It certainly increases the work, but with bad passwords, its likely you'll always crack a few in a large dump.

If you have a strong password, a high work factor should prevent brute-forcing it. But really, if it's computationally infeasible to crack a bad password, its also probably computationally infeasible to log in.

In cases like these, even if the risk of password recovery is minimal, a reset should still be forced because the attacks are offline and only become easier as time goes on. Forcing a rotation discourages people from continuing to work on cracking passwords for the next n years until they finally get an interesting account.

Re: Slack was hacked

#486

Post by opragel »

Hope the Slack team will properly implement SSO two-factor authentication policy - right now none of the Slack apps request re-authentication after thirty days once an account is signed into via SSO. Sign in once on OS X, Windows, iOS, Android and no further authentication needed. Looking at Google Apps SSO specifically but am assuming it affects other authentication providers.

Might as well plug my tiny Slack auto-install/update script for the OS X app while I'm here - hope someone else finds it helpful:

https://github.com/opragel/install_latest_slack_osx_app

Re: Slack was hacked

#487

Post by zrail »

tomjen3 wrote: post #322
getdavidhiggins wrote: post #141

Remember kids, it's 2FA before the fact, not after. 2FA is not a magic bullet though, and neither is salting. Salting makes it _expensive_, but not impossible for pass recovery. Always aim for impossible. You want to be able to throw away the key during an incident.

The only impossible system I know of would be one that uses client side certificates, but I would be surprised if anybody those in a successful business.

US Government systems typically use client certificates as a component of access control in the form of the Common Access Card[1]. Not that that's a business, or even a success from the point of view of the users, but it's one of the largest deployments of client side certs out there.

[1]: http://en.m.wikipedia.org/wiki/Common_Access_Card

Re: Slack was hacked

#488

Post by kijin »

ntucker wrote: post #400
kybernetikos wrote: post #398

Earlier quoted context omitted.

> you won't know what usernames they go with But if you've got a list of all usernames (probably a relatively small number) and access to a running system, isn't it easy to just try each password against each user until you find a match? The common practice of limiting logins from a single username wouldn't help with that either.

Yes, but we currently have 2.1 million users, so that's still no small burden. And don't forget that's only after you brute forced the passwords.

So you basically increased the cracker's workload by six orders of magnitude, which is equivalent to increasing bcrypt's work factor by 20. Cool!

Re: Slack was hacked

#489

Post by ionwake »

worklogin wrote: post #316
JimmaDaRustla wrote: post #230

Earlier quoted context omitted.

Excuse my ignorance, but you probably shouldn't be able to reverse an irreversible hash.

The point of hashing passwords is that the true password is not revealable. The point of salting password hashes is to prevent identical cleartext passwords from being stored as identical hashes in the database. Salts are often stored in the database, as well. The point of peppering keeps a database dump from being at all useful for recovering passwords. It make sure that a component of the process of cleartext -> DB…

Thanks for the informative post

Re: Slack was hacked

#490

Post by e12e »

ntucker wrote: post #473
ircmaxell wrote: post #452

Earlier quoted context omitted.

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?

You forget the cases where username=password (or username+CelverP3rmutation)=password).
Post reply on HN