19 ms·
Slack was hacked
- rudolf0 12y agoIt'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.
- kendallpark 12y ago> 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 have gone the cloud route.
- superuser2 12y agoIt'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 shared database."
- rudolf0 12y agoIf you're small, cloud may be better, but if you're large it often isn't.
- patcon 12y agoLarge does not mean you have better security, as I understand. (see Sony)
- rudolf0 12y agoYes, but you at least have the money and resources available to have better security. If you choose to squander those resources and not dedicate a large enough budget to your security department, that's your fault. Small companies typically can't afford competent and professional security analysts, engineers, penetration testers, and auditors.
- dasil003 12y agoIt's true that large will have more resources to do security right, but also they become a bigger target. If a small company self-hosts, they are less likely to be targeted than if they are a customer of a big cloud service where hackers might incidentally steal their data because it's there with thousands of other accounts. I guess what I'm saying is that regardless of who you are, there is no easily discernible best practice playbook, just a sea of tradeoffs generally made by people with a woefully inadequate grasp of the risks involved. Heck, even the best security people are at a disadvantage in the asymmetrical battle of infosec.
- __david__ 12y agoOTOH, 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).
- takeda 12y agoAlso, it is far easier to harden one or two hosts than entire farm of different devices.
- kendallpark 12y agoIf you had a vulnerability in an EHR that was run locally at many different hospitals a hacker would still have to target every single hospital that uses it and wade their way through a bunch of different custom configurations. It's not as juicy a target as a cloud-based system where a single vulnerability can get ALL the data of ALL the hospitals EVER in one location. (Like the Anthem hack.) I agree that most locally run systems are more vulnerable than the professional cloud based services. But cloud services are more exposed to attack and are a more profitable target for hackers due to their size. I think you have to assume that you're going to be hacked if you're a big enough target. You don't know what you don't know about your vulnerabilities. The better question is how you're going to design your data and platform to minimize the damage a major hack can do.
- omgitstom 12y agobcrypt is only strong if their cost / work-factor is set correctly
- StavrosK 12y agoExactly this. If they used ten rounds, it's dire, and just saying "bcrypt" doesn't say much unless you also specify the number of rounds.
- VBprogrammer 12y agoIt says a lot more than your passwords are safely stored behind unsalted MD5 :)
- tedunangst 12y ago10 rounds of bcrypt is "dire"?
- StavrosK 12y agoYes? 16 rounds take 1ms on my (old) machine. In Python, no less.
- bhauer 12y agoI 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.
- StavrosK 12y agoThat's because you're conflating "rounds" with "work factor". "Work factor" is actually 2^rounds, you're using 65536 rounds. Try 4.
- 12y ago
- jedberg 12y agoI 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.
- patcon 12y agoI agree, but can't deny self-hosted means your security lapses see less fanfare, which has value to the biggest and most lumberingest risk-adverse organizations
- riffraff 12y agonot to mention: you can host a chat server in your company network, somewhat protected from random people on the internet, and your ops people should already be securing that from external intrusions anyway.
- acdha 12y agoI'm mixed on this. It's undeniably true if everyone is in the same building but in my experience this is rarely actually true as people need to work from home, use mobile devices, other offices open, partnerships or acquisitions happen, etc. That tends to lead to people requesting holes in firewalls or using VPNs as a sort of aftermarket spray-on security measure, which inevitably makes things much worse because now you have exposed services[1] which were setup and operated by people whose threat-model was “Sheltered internal service accessed by trusted staff”. It's much better to start with the assumption that your services are exposed to the internet and secure them accordingly. 1. VPNs are almost always terrible for security because people tend to get them for one need (i.e. email, one line of business app, etc.) but when their computer gets compromised the attacker now has access to the superset of everything which every VPN user has ever needed to access and in all likelihood a bunch of other things which were never intended to be exposed but were never adequately firewalled internally.
- rudolf0 12y ago
- count 12y agoIf you haven't been paying attention, the US Govt (including the DoD) is moving out in the commercial cloud space in a big way.
- bitsweet 12y ago> No financial or payment information was accessed or compromised in this attack. This wouldn't be my first concern. It would be all of the confidential communication that happens within slack.
- jxm262 12y agoAgreed. The content of the chat's would be potentially much more important in my mind.
- hazelnut 12y agoWhich leads to the question if slack encrypts the chat data in the database.
- mateuszf 12y agoThat would make implementing search quite hard so I'd say - it's pretty likely they don't encrypt it.
- smt88 12y agoIf anyone from Slack is reading this, the encryption should be an option, even if it means disabling or substantially slowing the search feature.
- NeutronBoy 12y agoIf they encrypted it, Slack would have to hold the key, so that all users in an org can then read existing messages.
- smt88 12y agoNo, it could be a private key shared among users.
- newobj 12y ago
- deleted 12y ago[deleted]
- larsiusprime 12y agoSlack encourages 2-factor authentication: > Download and install either the Google Authenticator or Duo Mobile apps on your phone or tablet. Hey Slack, I don't have a smartphone. What am I supposed to do?
- ocdtrekkie 12y agoSlack is from the startup culture. Do not expect any support for people who are not "up with the times" and crud.
- caractacus 12y agoIf security is that important to you, buy one. A cheap Android tablet isn't exactly going to break the bank, is it?
- larsiusprime 12y agoThere are plenty of security reasons not to buy a smartphone.
- jakobegger 12y agoGet an OTP app for your laptop. It's an open standard.
- jmtulloss 12y agoThese usually fall back to regular text messages.
- nevir 12y agohttps://www.authy.com/ https://www.authy.com/ https://chrome.google.com/webstore/detail/authenticator/bhghoamapcdpbohphigoooaddinpkbai https://chrome.google.com/webstore/detail/authenticator/bhgh... https://code.google.com/p/winauth/ https://code.google.com/p/winauth/ and others, I'm sure
- vilda 12y agoBuy some small and cheap one, no SIM card needed.
- ocdtrekkie 12y agoLiterally was arguing with someone like two days ago that using Slack for sensitive data was a bad idea, guaranteed to blow up in your face sooner or later. Nothing sweeter than "I told you so".
- eswat 12y agoWe haven’t seen anything blow up yet other than Slack itself. While it sucks that the user table was compromised, I think the actual affect on businesses is more benign than they’d like to believe (ie: sensitive chatlogs that could be used for blackmailing).
- tracker1 12y agogiven the use of bcrypt for password salt/hashing, I'd say any attacks from here may be targetted to specific users, or those with really weak passwords (top 10k password list) run through wouldn't take too long on a distributed cluster per user. How much that opens up, and how that corresponds or overlaps with slacks password requirements will vary.
- Dirlewanger 12y agoLast year someone found a Slack security hole and was able to see all the companies using it and the room names, some of them pertaining to products under development. People are suckers for still using this company's products.
- deleted 12y ago[deleted]
- ForHackernews 12y agoFTFA: > 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.
- jscottmiller 12y agoThe article indicates that bcrypt was used. > 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.
- artursapek 12y agoFor hashing passwords, not for encrypting all communication.
- jmtulloss 12y agoThey go into details about this in the post. It's bcrypt with a salt.
- sarciszewski 12y agoI shudder to imagine anyone bothering to build bcrypt WITHOUT a salt. In general, salt is implied in bcrypt.
- eranation 12y ago> 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. I'm happy to hear they didn't just use MD5 with no salt as this would be the same as storing it in plane text... bcrypt + random salt sounds to me like the best practice nowadays, is it still holding? or are there some advanced in GPU cluster costs on EC2 that make even bcrypt hackable. I think I heard something that it has a way to "adapt" to advances in computing, is that by simply adding more iterations based on the current CPU speed or something? how does that work?
- chrisfosterelli 12y agoWell, 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 hashes, which limits how often this is done.
- tracker1 12y agoNote: 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.
- sdevlin 12y agoWhat 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.
- nvk 12y agoHost 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!
- sarciszewski 12y agoNot 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.
- petercooper 12y agoSetting up an ircd is not a bad idea. Then we just need to find the ircd and client that does what Slack does. (Which is totally possible, but I'm not sure it exists?)
- tracker1 12y agoSlack also has webhooks/bots that interact with other services for notifications... pingdom, github, etc... which can be done with bots, but it gets more complicated. Not to mention search archives, file upload preservation and other display niceties.
- nvk 12y agoI don't personally use it, but this might help your https://hubot.github.com/ https://hubot.github.com/
- asenchi 12y agoCareful, that has basically zero in the way of authorization/authentication. Putting business logic in there on a standard deploy is asking for trouble, especially if malicious accounts have access.
- 12y ago
- rdl 12y agoI 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.
- sergiotapia 12y agoI think that's the point of slack, being able to communicate sensitive information. Where would you relay something like an Amazon AWS Access Key?
- eridius 12y ago> 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?
- NobleLie 12y agoCoincidentally, 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 have to re-hash the entire dictionary anew for every salt. A determined attacker who has compromised the server will have to mount an entire new dictionary attack against every user's salted hash, rather than being able to quickly scan the list for known hashes." [0] [0]: http://www.developerfusion.com/article/4679/you-want-salt-with-that/3/ http://www.developerfusion.com/article/4679/you-want-salt-wi...
- eridius 12y agoYeah, 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 have a specific target in mind.
- azinman2 12y agoAnd given th usernames and emails are out there, it reveals (a) all the companies using slack, (b) potentially very high value targets. I wonder who they had specifically emailed. My guess is those people aren't using slack anymore.
- 12y ago
- glesica 12y ago"As part of our investigation we detected suspicious activity affecting a very small number of Slack accounts. We have notified the individual users and team owners who we believe were impacted and are sharing details with their security teams." Assuming the password hashes can't be reasonably reversed, what would have caused suspicious activity on some user accounts? Is this a situation where certain users may have been targeted specifically, meaning that only a couple hashes needed to be reversed, making the task feasible?
- deleted 12y ago[deleted]
- sarciszewski 12y agoThis sounds like a half-assed hack if they were able to limit the damage. 2/10 try harder next time, skiddos.
- rattray 12y agoHow 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?
- data-cat 12y agoThat's a really good question and one that probably has a different answer for every breach. In this case it's also probably a question that only Slack could answer for you. In regards to the second half of your question, being that they only recently went public about it, I suspect that they most likely did discover it after the fact.
- legohead 12y agoAt a place I worked at we discovered it in a couple ways. One was a routine scan done by our host provider, looking for malicious files meant to do things like create a web-shell. After they found the malicious files they had logs to determine the time frame of the attack(s). And in another instance the hacker emailed us asking for ransom.
- tracker1 12y agoLogging every API request through every layer into ElasticSearch/Logstash or something similar for starters.
- loumf 12y agologs -- perhaps they hired a security firm to do periodic audits.
- rmc 12y agoI recommend "The Cuckoo's Egg". It's a great book about traking down a hacker and explains one of the ways it was done.
- unreal37 12y agoStep 1) Discover a hole in your code, Step 2) go back to logs and see if anyone ever used that hole, Step 3) panic.
- elchief 12y agoAssuming (no evidence, it's just very common) that this was a SQL Injection, here are some ways to protect yourself: * Use http://en.wikipedia.org/wiki/Database_activity_monitoring http://en.wikipedia.org/wiki/Database_activity_monitoring. If you don't list users on your site and you get a query that would return more than one user record, it's a hacker * Add some http://en.wikipedia.org/wiki/Honeytoken http://en.wikipedia.org/wiki/Honeytoken s to your user table, and sound the alarm if they leave your db * Use Row-Level Security * Database server runs on own box in own network zone * Send logs via write-only account to machine in different network zone. Monitor logs automatically, and have alerts. * Pepper your passwords (HMAC them with a key in an HSM on the web server (then bcrypt). Don't store key in db). https://blog.mozilla.org/webdev/2012/06/08/lets-talk-about-password-storage/ https://blog.mozilla.org/webdev/2012/06/08/lets-talk-about-p... * Use a WAF that looks for SQL injections * [Use real database authentication, per user. Not one username for everyone connecting to db. Yes, this is bad for connection pooling]
- tracker1 12y agoI think it depends on the structure of the system... If you separate authentication from profile information, then you can run each on separate systems. They were already using bcrypt, which is a fairly strong salted hashing system. As to restricting access, having all access to the database restricted to API servers that provide the limitations you mention, you get a similar level of control, without the complexity of managing per-user database logins. With per-user database logins, you are then subject to whatever system the dbms uses. If you are using systems with looser less fine grained controls, you can be even more limited.
- azinman2 12y agoWhy would you assume that? There are plenty of ways to hack into stuff without sql injections.
- elchief 12y agoIt's the most common vulnerability. https://www.owasp.org/index.php/Top_10_2013-A1-Injection https://www.owasp.org/index.php/Top_10_2013-A1-Injection
- 3princip 12y agoLot's of hype (IMO) around Slack, but lot's of money thrown at them so I kept thinking that I'm missing something! Just being skeptical as usual. The other day an invitation arrives to use Slack. Great! Let's see it, this killer feature or killer combination of features. What have these smart people come up with that hasn't been done countless times in the same space to make them so successful? It's literally nothing. I can't believe that's the product. Anyway, on top of a completely underwhelming experience comes this news. I can't see why a company would use them, to be honest. But then I haven't built a billion dollar company, so not many people will be asking me for an opinion.
- tracker1 12y agoYou could do something similar with an IRC server and bots with webhooks... Just the same, they did do this, and offer a web based interface that people are more comfortable with (no need for an irc client), and does more than IRC clients do. IT's not that anyone else couldn't do this, it's that they've done it relatively well.
- chralieboy 12y agoAbsolutely. It's just so much better than any IRC client. People looked at the iPhone and said "but all of this technology already existed!" That isn't the point. It had never been put together in a user-friendly way. Slack hasn't invented anything new, but the entire product is a delight to use.
- programmarchy 12y agoI think a key differentiation with Slack is their design, and that they provide clients for both mobile, web and desktop. I can't think of another product that has done this well.
- aidos 12y agoI would say that their ux is actually really good. I'd go so far as to say they have one of the best on boarding experiences I've ever seen. But that's just my opinion.
- 12y ago
- zuck9 12y agoI would be more interested in how the hacker got access to their DB and nothing else. Maybe the DB is remotely accessible (unlikely) or there is SQLi vuln. in Slack.
- globaloptima 12y agoOut 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?
- globaloptima 12y agoI'll answer my own question, given the attacker wouldn't know how the salt was used unless they had access to the code, it doesn't matter.
- mbrubeck 12y agoSalts 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 https://en.wikipedia.org/wiki/Rainbow_table
- drinchev 12y agoYeah it's Usually the same table, but salt is used to prevent hackers using already generated hash map of popular passwords to diff with your password hash directly without computing.
- why-el 12y agoI am slightly confused. How can they have use their "hash map of popular passwords" to diff against your table if they do not have the "pepper" used originally for bcrypting the passwords?
- swhipple 12y agoPre-computed mappings of popular passwords (rainbow tables) aren't really used nowadays due to parallelization being more cost effective, but the idea in both cases is that you want collisions with known values: the popular password hashes in the case of the rainbow table, or the computed values in parallel enumeration. If the password hashes each have a stored unique salt (bcrypt will), you have to compute the hash per salt per password that you test. Instead of computing the hash for "password" (+ stored work factor for bcrypt) to be X, and checking all database entries for X, they instead have to calculate each hash per entry. For a table of 1000 users, it would take around 1000 times as much work to determine the users with "password" as their password. If you just wanted to target a single user though, the salt doesn't really matter for enumeration (though if you were using rainbow tables, you likely wouldn't have those specific hashes computed).
- curiously 12y agois 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
- mastermojo 12y agoskype doesn't have admin/team lead functions that companies typically might want. my skype mobile app crashes all the time. also inline gifs are cool.
- curiously 12y agocould be a bad phone. my skype mobile app used to crash all the time but I switched to a faster Android phone and its smooth.
- minitech 12y agoSkype is really bad for text chat. - It is closed-source, obfuscated, and untrustworthy overall (https://www.eff.org/secure-messaging-scorecard 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-mail, which Slack does). Worse, if you go offline, they won’t get it until you’re both on at the same time! - Files shared on Skype don’t last. You have to use an external service. - 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.)
- zkhalique 12y ago- It is closed-source, obfuscated, and untrustworthy overall (https://www.eff.org/secure-messaging-scorecard 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?
- mirashii 12y agoSurprisingly, they didn't force a password reset on all accounts. Even though the passwords are hashed and salted, targeting a couple users and checking for weak passwords can now be done offline, with no rate-limiting or network calls necessary. In breaches like these, it should still be mandatory to issue service wide password resets. Anything less is unacceptable.
- kannonboy 12y agoI 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?
- mirashii 12y agoThere 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.
- tempestn 12y agoI'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.
- mirashii 12y agoA 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.
- automathematics 12y agoThey added team-wide password/security stuff.... but it's paid users only. Lame.
- scott_karana 12y agoAgreed. Proper security shouldn't be an optional, paid "feature". I feel like it should be mandatory for all tiers of a product, whether they're free or not.
- imc 12y agoOnly owners can see it, not admins apparently. https://twitter.com/SlackHQ/status/581544119677374464 https://twitter.com/SlackHQ/status/581544119677374464
- Klinky 12y agoWas 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.
- BrainInAJar 12y agoI actually am coming to the conclusion that 2FA is dangerous. It's recommended any time there's any kind of breach as if it were some kind of panacea for security, when in most cases the cause of a security breach is a database intrusion. 2FA keys are stored unencrypted so if the db is breached they're already cleartext (no boil the oceans bcrypt collision needed) and the extra layer of security theatre from 2FA only encourages bad practices like password reuse & easy passwords.
- jest3r- 12y ago2FA can prevent future password phishing attempts when your users table is compromised. It's a bit of a redirect in terms of what happened with Slack though and not worth mentioning after the fact.
- mmatants 12y agoAgreed: 2FA protects against password leaks on other sites from being applied to the system in question. In this case it would have been more reassuring to hear them disclose what was the attack vector (e.g. social engineering, email trojans, etc) and explain how they will reduce the chance of a similar compromise in the future.
- deleted 12y ago[deleted]
- FiloSottile 12y agoI 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/ 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 simple, free and you can retroactively apply it. EDIT: I addressed some of the points raised in this thread here https://blog.filippo.io/salt-and-pepper/#editedtoaddanoteonrotation https://blog.filippo.io/salt-and-pepper/#editedtoaddanoteonr...
- scott_karana 12y agoI don't see that as a negative suggestion: that's a fantastic idea, and for all we know, a Slack employee will read your post, and make their hashing even better. :-)
- pc86 12y agoBy 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.
- scott_karana 12y agoIn a general sense, concatenating a pepper with your salt is NOT reinventing anything at all. (You can rephrase that as "Store pieces of your salt in separate places" which doesn't change or violate any traditional, rigorously tested application of salt in cryptography) There are issues with using it as implemented in some posts here, with nested bcrypts, to be sure, but I think the concept is still fairly sound, though there are certainly implementation pros and cons. ---- As for maintainability: I'm also familiar with crypt(3)-style password hashes, where a prefix uniquely specifies the algorithm (and subvariant) used.[1] Why wouldn't this be fitting here? You can then easily detect, and deal with, passwords that have been tagged with "previous" peppers, such as forcing returning users to change password if a previous pepper was compromised, etc. 1 https://www.freebsd.org/cgi/man.cgi?query=crypt%283%29 https://www.freebsd.org/cgi/man.cgi?query=crypt%283%29 or http://man7.org/linux/man-pages/man3/crypt.3.html http://man7.org/linux/man-pages/man3/crypt.3.html, for some reason I can't find a link to a more comprehensive list at the moment
- dmazin 12y agoWhy 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.
- deleted 12y ago[deleted]
- deleted 12y ago[deleted]
- dragonwriter 12y agoBecause SMS is not even remotely a secure communication channel, and the point of two factors is proof of possession of two different classes of things (that you have some device and that you know some secret), and using an insecure channel to send a message weakens the proof of the have half of that, in much the same way as using a weak or published password weakens the know half. Ideally, you want as strong as practical proofs of each half within the constraints set by UX considerations.
- BrainInAJar 12y ago> Because SMS is not even remotely a secure communication channel Neither is 2FA, it's a key stored completely unencrypted in both your phone and the the host's db.
- dragonwriter 12y agoThat's not particularly weak as proof to the person who controls the DB that you have access to the phone, which is what the device factor of a 2FA scheme is intended to prove, since you have to have access to either the DB or the phone to get the key. Conversely, SMS's weakness is in the communication channel, which can be compromised without compromising the things for which the factor is intended as proof.
- 12y ago
- thspimpolds 12y agoWait a second, you got hacked 27 DAYS ago (at least), you know they got data, and you are NOW telling people? Dong, Dong, Dong, that is the death bell of a startup
- MichaelGG 12y agoIt could be a bad idea to let intruders know you're on to them if you haven't determined the extent of the intrusion.
- tomjen3 12y agoSadly the universe isn't fair. Nobody gives a shit about security, but yeah it should be illegal to sit on the information more than 48 hours. If you can't determine the complete and full extend of the damage before that you need to be out of business.
- kolev 12y agoCan we go back to IRC now, please! Slack is not only distracting, proprietary, but it is also pretty expensive. Let the mere mortals use it, but we should stay away!
- matthewmacleod 12y agoI don't think IRC quite offers the feature set that Slack users would be expecting, does it?
- kolev 12y agoI'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!
- raphael_l 12y agoIs this actually the sort of people that get attracted to HN? Thinking of others as "mere mortals" and yourselves as gods? Sad picture.
- kolev 12y agoI was joking. Sometimes emojis help as we're missing a whole communication channel in here (body language).
- tomjen3 12y agoProbably not in that condescending way, but it is useful to keep in mind that people are fundamentally different from you. The trouble is when you think they are inferior beings (their tech skills on the other hand are inferior, no reason to not state that plainly). For what it is worth I have coded Erlang at work and am quite partial to cat pictures, myself.
- kolev 12y agoWell, let's talk about the reality now. By definition, most people are mediocre, not very smart, not very healthy, not very pretty, etc. Most! That's whom Slack targets - most.
- getdavidhiggins 12y agoRemember 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.
- tomjen3 12y agoThe 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.
- zrail 12y agoUS 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 http://en.m.wikipedia.org/wiki/Common_Access_Card
- tomjen3 12y agoUnfortunately the only reason they can do that is that they are the government.
- paimpozhil 12y agoIf someone was able to get access to the user table I would believe it is trivial for them to download the chatlogs/ mine other information from database. May be slack wants us to believe only a small part of the data is hacked , I dont know . We have been using Slack for many projects over last year and it helps improve productivity
- sergiotapia 12y agoSo they didn't get the password, ok. But they still have my name, my email, my skype. This completely sucks.
- balabaster 12y agoYeah, when they call, can you tell them I have a whole flock of ducks that need cleaning? :P
- cheshire137 12y agoLooks like they require Google Authenticator or Duo Mobile app to do two-factor auth. I'm not interested. Why can't they be like Github and just send me a text message? I don't want a dependency on some other company's product to make Slack more secure.
- jtokoph 12y agoThose are only two examples of apps that support TOTP[0]. TOTP is a standard with many implementing apps, including free and open source that will accomplish the same thing. The two apps listed on the website are just well known examples. [0] http://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm http://en.wikipedia.org/wiki/Time-based_One-time_Password_Al...
- modeless 12y agoI hate to break it to you but SMS is some other company's product. Google Authenticator is not a cloud service; it's simply an implementation of the TOTP RFC and there are others available if you hate Google so much that you don't trust a purely local app written by them.
- __david__ 12y agoAn open source one at that! https://github.com/google/google-authenticator/ https://github.com/google/google-authenticator/
- agentdrtran 12y agoSMS is far more insecure than Google Authenticator. Also, you can use other apps like authy if you don't want to use Google Authenticator for whatever reason.
- M4v3R 12y agoGoogle Authenticator relies on an open algorithm for one time passwords. It has been implemented by many apps, and it's so simple you can do it yourself. So it doesn't require you to rely on other company's product.
- 12y ago
- racontour 12y agoMy team logs with our Google accounts. It's not addressed in the disclosure, but should we be deauthorising Slack. Have our tokens been breached?
- jturolla 12y agoPossibly no because the token is app-specific and it's not likely that the slack key was compromised, but I also agree that they should have disclosed that.
- balabaster 12y agoCan anyone from Slack elaborate as to where this hack originated if known?
- dutchbrit 12y agoHow many rounds of hashing did they use?
- elchief 12y agoPHP default is 10 if that helps
- zobzu 12y agoppl gotta stop thinking encryption in a db saves you from compromise. Its being very naive or ignorant. It only reduces your exposure to data leak very lightly - in some circumstances, which are generally not even likely (like make a dump and post it publicly) Its like 'but it says AES on the box so its secure right?' and shouldn't be a thing among developers anymore. Obviously the database data has to be decrypted for the app to use it, and generally, you hack the app, not the db.
- deleted 12y ago[deleted]
- vsync 12y agoInteresting 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.
- Zolmeister0 12y agoDear All - Your passwords should be considered compromised. Hashing is merely a deterrent, it does not prevent cracking.
- elchief 12y ago6500 bcrypt(5) hashes/second with custom FPGA: http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=7032529&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D7032529 http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=703252...
- Zolmeister0 12y agoI didn't say it would be easy. But dictionary and password list-based attacks are expected to be quite effective anyways. http://www.openwall.com/presentations/Passwords13-Energy-Efficient-Cracking/ http://www.openwall.com/presentations/Passwords13-Energy-Eff...
- alexdowad 12y agoThat's exactly what I thought the moment I read the post. The fact that Slack used bcrypt is good, and if they used a high number of iterations that's better, but neither will help you if your password happens to be on the crackers' list of 10,000 most common passwords.
- deleted 12y ago[deleted]
- mead5432 12y agoCan we please reference to this event as the "Shlacking"?
- martin_ 12y agoSlack has now sent me 6 e-mails about this, to the same address :( They have different names associated in each one (i.e. some have my last name, some have an alias, etc), but all to the same target e-mail address.
- oxfordbiochron 12y agoThis is where all users should be using BioChronometrics http://Oxford-Biochron.com http://Oxford-Biochron.com to passively authenticate the user base. Applications such as Slack and Yammer have corporate info that competitors or corporate espionage people would want.
- tn13 12y agoI dont really care. Never shared any critical information on slack any ways.
- tomjen3 12y agoWhy the fuck am I reading this on hacker news and not from a notification in slack?
- jivid 12y ago> If you have not been explicitly informed by us in a separate communication that we detected suspicious activity involving your Slack account, we are very confident that there was no unauthorized access to any of your team data (such as messages or files)
- tempestn 12y agoThey sent you an email.
- hoodoof 12y agoIt would be good to know exactly how this sort of thing happens so others can try to prevent it in their own systems.
- vram22 12y agoGot the email from them about the issue, as a Slack user. Also got 2 other duplicate emails from them (which went into the same Gmail conversation, since same subject), that were empty. Seen this a few times for other services, not sure why it happens.
- vram22 12y agoGot the email from them about the issue, as a Slack user. Also got 2 other duplicate emails from them (which went into the same Gmail conversation, since same subject), that were empty. Seen this a few times for other services, not sure why it happens.
- homakov 12y agoIf you have a reset_token you still can log in, even when passwords are hashed. Likely reset tokens were stored in the same table
- deleted 12y ago[deleted]
- colordrops 12y agoWe've been waiting for over a year for Slack to create a self-hosted version that we can deploy to our intranet specifically because we can't expose ourself to things like this. They've kept insisting that it's around the corner but it doesn't seem to be happening. Hopefully this will spur them to prioritize self-hosted Slack.
- deleted 12y ago[deleted]
- gkya 12y agoWhat the flippin' heck is Slack? I received an email today telling me of this event. Then I had to recover my team and my password, then deactivate my account, and I have never seen this website until I saw that email. Looking at my team, it seems to be created by the guys at <pyistanbul.org>, or someone using that website as a base for accounts. That one has a people page and there are links to various places. Now, someone has created an account in my name using my main e-mail address and I have not been e-mail-notified for a confirmation of account, or at least not have been notified that an account is created. Apparently either these lot cannot write proper emails that can pass through spam filters or they expressly allow this sort of malicious account creation. Not surprising that they got hacked.
- _trb_ 12y agoI am an application security professional, and I created this account in order to make this post after reading many of the comments on this thread. Many of the comments have great suggestions. However, very few talk about the most important part of creating mitigations and designing key management/crypto. What is the security target? Before throwing new designs at a problem, the attackers and attack vectors must be defined. If you don't know who you are guarding against and what they will do (and what data they will steal), then how can you possibly say what is a good mitigation?? One might argue that the threat is obvious, but I'll guarantee you that there are dozens of threats here. List them. Prioritize them. Then mitigate them. It is helpful to fully understand the problem/solution space before jumping in with pepper's, salt's, extra databases, and solutions.
- chatmasta 12y agoIf I were Slack, I would pretend to get hacked. Slack critics often point to its centralized architecture as a weak point, because rational corporations should not entrust security of their internal communications to a third party. Particuarly when that third party aggregates communications of its many clients, it becomes a target of hacking. Why hack a single corporation when you can hack Slack and get all their clients at once? This is a valid criticism. Slack can do all it can to mitigate security risk. But at the end of the day, there is always at least one vulnerability, somewhere. As Slack matures as a company, it needs an answer to this criticism. Because security is so naturally unpredictable, it would be disingenuous for Slack to respond with anything resembling "our security is perfect." Because, of course, as we see time and time again, no security is perfect. Now that Slack has captured the low-hanging-fruit of the market, it needs to pick the high-hanging-fruit. The most profitable clients for slack will be the largest, conservative, enterprise clients who will join the Slack platform and then never leave. The long term survivability prospects of Slack depend on capturing these large enterprise customers. Strategically, Slack needs to find a response to the criticism that its security is prohibitively weak, so that it can convince these large enterprises to join its platform. Perhaps, the best response to security criticism is that "we got hacked, but our internal policies mitigated any cascading effects and customer data remains safe." [0] [1] So would it be in Slack's best interest to stage a hack on itself? Or to report a hack occurred when it really didn't? It seems feasible that by setting precedent for its reaction to a hack, Slack has a chance to demonstrate the competence of its security team. Now investors can point to this incident as one handled well by the security team. In a world where, unfortunately, corporations will always get hacked, Slack was able to survive with some dignity. [0] or, as safe as it can possibly be according to computer science. [1] debatable.
- rubyn00bie 12y agoNote: My comments and thoughts are geared specifically to Slack or a very similar entity (tech start up, which sells a service). I strongly disagree with this idea: "Now that Slack has captured the low-hanging-fruit of the market, it needs to pick the high-hanging-fruit. The most profitable clients for slack will be the largest, conservative, enterprise clients who will join the Slack platform and then never leave. The long term survivability prospects of Slack depend on capturing these large enterprise customers." I think this is a large misconception held by people. Often times, and I say this from experience, enterprise customers will demand a large amount of support/coddling because of the gross amount they're paying. That "$1 million" a year contract sounds less and less good when you realize it requires constant attention of two, now dedicated, engineers, two support reps, sales person, and on occasion an executive... Compare that to 1,000 individual customers/subscribers who require next to no special attention, or dedicated engineers. Large, conservative, enterprise customers distort profit margins, and should be avoided. Think about this: some enterprise customers are so large they may hire a person (or persons) to _only_ deal with your product. Now you've got a team of cogs (people) at your enterprise client, working, to take up your time and cost you money. What's worse is that in most corporate cultures, partners/suppliers/providers are not looked at as "family" but as disposable. There's no vested interest in your success or failure. So there is little to no concern over how your smaller company may be abused by a larger one.
- cryptosatire 12y agoOriginal email sent to Slack users: https://gist.github.com/anonymous/a26e3279dd57be3363b3 https://gist.github.com/anonymous/a26e3279dd57be3363b3 What the email might sound like if Slack was being completely forthright: --- Dear User, We are writing to inform you that our servers have been broken into and that the personal information of our 500,000 users (including you) has been stolen. This information was likely swiped by either the bad guys (thieves) and will be sold on the darknet, or by the bad guys (NSA) and will be used in their efforts to build a global surveillance state.[1] We have since tried to block this unauthorized access and made additional (but nebulous) changes to our technical infrastructure in an attempt to prevent future PR headaches. No specific action is required of you - nor is there anything you can do to reverse your lost privacy. However, our PR department is extremely worried that this news might damage our 2.76 billion dollar valuation.[2] Since we have been working on a sexy (but completely unrelated) security feature for a while, we decided to release it early. We intentionally conflated the fact that our servers got hacked with a new user-space security feature in an effort to obfuscate how badly we screwed up. The breach happened in February but it has taken us till the end of March to get this new feature usable.[3] (If you are asking yourself why we would release a half-baked security feature, just remember, we are the company that just accidentally released personal information belonging to you and half a million other people.) We are hoping that by making just the the paragraph about this new feature BOLD many users might miss what really happened. We also hope that by "strongly recommending" that you enable this feature, the blame for this security blunder is shifted to our customers, as if this could somehow be prevented by enabling this feature. Additional misdirection is available in our help center. [1] https://www.eff.org/nsa-spying https://www.eff.org/nsa-spying [2] http://blogs.wsj.com/digits/2015/03/26/slacks-valuation-more-than-doubles-to-2-8-billion-in-five-months/ http://blogs.wsj.com/digits/2015/03/26/slacks-valuation-more... [3] http://slackhq.com/post/114696167740/march-2015-security-incident-and-launch-of-2fa http://slackhq.com/post/114696167740/march-2015-security-inc...
- pikachu_is_cool 12y agoSlack is for plebs who can't idle.
- scottmcdot 12y ago"So yeah, we got hacked..." - Landing Page
- EGreg 12y agoFor those that store the user tables in the same db as everything else, what is the big deal about protecting passwords in particular? The attacker already has much more. If it is because of password re-use then that is what should be prevented.
- deleted 12y ago[deleted]
- cjbarber 12y agoDid you read the blog post? The first paragraph concludes with: > We have also released two factor authentication and we strongly encourage all users to enable this security feature. Also, the title of the post is: > March 2015 Security Incident and the Launch of Two Factor Authentication They are not pending 2FA anymore.
- hsshah 12y agoI just enabled it with Google Authenticator. And tried using on my phone. Didn't seem to work. May be they are getting DDoS right now due to the announcement.
- deleted 12y ago[deleted]
- meritt 12y agoWhy is everyone worried about what hashing algorithm was used and not if their company's private chat logs are about to become public knowledge?
- amckenna 12y agoBecause obtaining a hash of a password does not mean the attacker can access the accounts and the chat logs. If the passwords were not hashed or hashed in a weak manner then that means the attacker could figure out the account passwords, then gain access to the accounts, which would be bad.
- meritt 12y agoI completely understand the risks associated with user passwords and hashing algorithms. But you know what? That shit gets leaked all the time. It's not uncommon and unfortunately, users are accustomed to it by now. It's relatively easy to fix. You know what's a big deal? Having your company's internal private communications suddenly public or sold to the highest bidder. That's the sort of thing that doesn't have a "reset password" simple fix.
- kstop 12y agoOne thing that bugged me about this today was that after I changed my password on desktop, my mobile session wasn't invalidated. Apparently it's an option for mass password resets, but it really should be mandatory.
- matdrewin 12y agoSo 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.
- alfredxing 12y agoSlack is growing their security team, if you want to help them improve the security of the product: https://slack.com/jobs/dfd75111/security-engineer https://slack.com/jobs/dfd75111/security-engineer
- homakov 12y agoThis is why you need to hash reset tokens too http://sakurity.com/blog/2015/03/27/slack_or_reset_token_hashing.html http://sakurity.com/blog/2015/03/27/slack_or_reset_token_has...
- grey-area 12y agoIn 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?
- homakov 12y agoWhy wait and not use it right away? If you have read access now you can exploit now.
- grey-area 12y agoOh 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.
- homakov 12y agoIt would. They didn't do it probably because they didn't try this trick. But they could i think.
- homakov 12y agoBTW actually new version of devise hashes tokens.
- vayarajesh 12y agoWhat 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..
- opragel 12y agoHope 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 https://github.com/opragel/install_latest_slack_osx_app
- rcarmo 12y agoWell, I can't even reset my password. I suspect that's because my registered e-mail address uses the "foo+bar@gmail.com" format (which I use for easier filtering), and something on Slack doesn't like sending those (no e-mail on my inbox, spam folder or filter matches)
- benshanjiang 12y agouc3dp