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

111–120 of 526 posts

Re: Slack was hacked

#111

Post by tracker1 »

emerongi wrote: post #52
eridius wrote: post #31

> Slack’s hashing function is bcrypt with a randomly generated salt per-password which makes it computationally infeasible that your password could be recreated from the hashed form. Is this true even when the attacker is specifically focusing on a single account, or is it only computationally infeasible to recover passwords for accounts in general?

It's feasible if you use a commonly used password or if the attacker knows specific information about you or your password. Otherwise, it is pretty much impossible. // this is about focusing on a single account. Nobody would ever bother with trying to crack the whole DB.

Not only that, but along with the email you may have higher value targets that you will spend more time checking or trying to brute force.

Even if it's a gmail user, if you get them, and they use the same password on their mail, poof, you're in.

What gets me is that banks of all places have the worst password abilities (for their web logins)... case insensitive, only letters and numbers.

Re: Slack was hacked

#112

Post by mbrubeck »

globaloptima wrote: post #89

Out of interest, where where the per-user salts stored I wonder? Where would people normally store this if not next to the hashed password in the same table?

Salts aren't meant to be secret; they are generally stored next to the hashes (and used in a known, standard way). The purpose of the salt is to raise the cost of brute-force attacks, by forcing attackers to brute-force each password separately.

https://en.wikipedia.org/wiki/Rainbow_table

Re: Slack was hacked

#113

Post by Xylakant »

eridius wrote: post #61
NobleLie wrote: post #48

Earlier quoted context omitted.

Coincidentally, I was just looking into your question; this should answer your concern. "Since every user has their own unique random salt, two users who happen to have the same password get different salted hashes. [If] the dictionary attack is foiled, the attacker cannot compute the hashes of every word in a dictionary once and then check every hash in the table for matches anymore. Rather, the attacker is going to…

Yeah, salts mean you can't use rainbow tables. But you can still attack a single user. The question is what "computationally infeasible" actually means. How much computing power would it take to crack a single user's password? How about if it's a weak one? A strong one? If the answer is "it would take $1000 worth of Amazon EC2 computing to crack a single weak password", well, that's certainly feasible to do if you ha…

The answer depends on the tuning parameters used for the bcrypt hashing (cost/work factor) and the length of the user password. Obviously a 1-character password will fall even with a high workfactor and a dictionary word will probably fall as well. This paper http://www.emsec.rub.de/media/crypto/veroeffentlichungen/201... tags some numbers on breaking passwords with a low cost factor. Assuming a cost factor if 5 (12 would be more "real" world) and an 8 character password with an alphabet of 62 chars (uppercase, lowecase, 10 digits) the estimated cost to break a password within a month is in the millions with dedicated hardware designed for brcypt breaking (Fig 5). With a work factor of 12, an 8 character password will not break on EC2.

Re: Slack was hacked

#115

Post by jfroma »

sarciszewski wrote: post #42
programmarchy wrote: post #36

Earlier quoted context omitted.

Agree with you in one sense of being responsible for your own security, but by this logic I should keep all my money under the mattress instead of the bank, no?

I know you're being facetious, but the answer is possibly yes, depending on your threat model. If you have great physical security at your home and don't trust the banks (e.g. their fee schedules), it might be a safer decision. For most people, it's not.

Or if you experimented an economic measure that froze your account like this one [1].

They froze all accounts and they even threatened the population with opening the safe deposit boxes.

[1]: http://en.wikipedia.org/wiki/Corralito

Re: Slack was hacked

#116

Post by schrodinger »

laumars wrote: post #83
ipedrazas wrote: post #53

Earlier quoted context omitted.

Exactly!!! Encrypting user data should be a common practice like hashing passwords.

Why? Encrypting e-mail addresses would break password reset features and phone numbers are generally public anyway (yes you can go X-directory, but the real issue here is why these services require a valid phone number to begin with)

Why would encrypting email addresses break password reset? You can encrypt the database at rest such that the application has a private key that can decode it. That way both the application and the database server need to be breached to obtain anything usable.

Re: Slack was hacked

#117

Post by sdevlin »

tracker1 wrote: post #90
chrisfosterelli wrote: post #26

Earlier quoted context omitted.

Well, bcrypt + random salt is great but it still can't protect you from bad passwords. It's vulnerable to a dictionary or bruteforce attack the same way everything else is. You _can_ increase the difficulty of bcrypt, which essentially increases the iterations (as you mentioned). Most bcrypt libraries default this value, but the programmer can override it. The downside is that this requires you to update all of your…

Note: if your hashing algorithm is too compute intensive, you have to take other measures to prevent your login system from being a DDOS vector... for example, with SCrypt's recommended defaults for passwords, the .Net library takes almost half a second of time on a modern CPU... if you get more than a few dozen requests per second, per system you can be brought to a crawl without other mitigation in place.

What makes it slow? Is it implemented in C#?

I would avoid slow implementations of password hashing algorithms. You want the overall operation to be slow due to the computations you're performing, but you want the implementations of those operations to be fast. Because the attacker's implementations of those operations will be fast.

Re: Slack was hacked

#118

Post by therealidiot »

nvk wrote: post #87
blfr wrote: post #74

Earlier quoted context omitted.

It will take you more than 10 minutes to just choose the ircd to use. Not to mention configuration and maintenance. I looked through the ircds available in Debian repositories the other day and they didn't look very fresh. So you might also have to package them from source and make sure that stays up to date. Hosting your own services has some appealing security qualities (like being able to put them in your VPN) but…

Saved you the search; ngircd

Seconding ngircd

Hassle-free configuration

Re: Slack was hacked

#119

Post by acdha »

sarciszewski wrote: post #27
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!

Not sure why this is being downvoted. Setting up IRC on a .onion isn't even difficult. Setting it up with SSL is only a touch harder.

It's presumably being downvoted because it's just lazy propaganda, not a serious answer.

It'd take more than 10 minutes simply to setup a server which ircd would run.

Then, of course, you'd need the time to setup all of the other services which Slack provides (i.e. durable file storage, integration with your applications and other services, etc.) and pick or develop clients for all of the platforms people use.

Then you have to actually support all of this: that's basic stuff like redundant servers and backups, account management, and the ostensible purpose for doing all of this: staffing your own security team at or better than Slack's level.

None of that can't be done and if you already have a good ops team it might even be worth doing. It's just way more than a 10 minute job even if you cut a bunch of corners.

Re: Slack was hacked

#120

Post by Klinky »

Was an admin account compromised in a situation where 2FA could have prevented the unauthorized access? If that's not what happened, then 2FA seems a bit hand wavy if it's not directly related to this security incident.
Post reply on HN