8 ms·

> 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 commun

> 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 ago
Agreed. The content of the chat's would be potentially much more important in my mind.
- hazelnut 12y ago
  Which leads to the question if slack encrypts the chat data in the database.
  - mateuszf 12y ago
    That would make implementing search quite hard so I'd say - it's pretty likely they don't encrypt it.
    - smt88 12y ago
      If 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 ago
        If they encrypted it, Slack would have to hold the key, so that all users in an org can then read existing messages.
        smt88 12y ago
        No, it could be a private key shared among users.
    - newobj 12y ago
      That's not right. There is no need to store text body in order to index it. Furthermore, you can implement an index of token hashes, rather than an index of tokens.
      - polyfractal 12y ago
        It would remove a lot of nice search features, however. If you just index tokens without positional information, you have a much harder time performing phrase matching. If you include positional information, you can probably crack the encryption because some tokens are statistically more likely to appear next to each other than others. If you index shingles (phrase chunks) instead, you lose out on sloppy phrases...you can only match exact phrases. I imagine you can perform a similar statistical attack too. Hell, just getting the term dictionary would probably allow you to reverse engineer the tokens, since written language follows a very predictable power law. Hashing also removes the ability to highlight search results, which significantly degrades search functionality for an end user. Basically, yes, you can do search with encrypted tokens...but it will be a very poor search experience.
    - skatenerd 12y ago
      This reminds me of the plot of Silicon Valley
    - sukilot 12y ago
      If they dont encrypt storage they are highly negligent. Index and search are done in RAM,which is slightly harder to steal than disk data.
  - jacquesm 12y ago
    Is there a good reason to keep chat data longer than it takes to deliver it to the recipient?
    - buttsex 12y ago
      They archive chat messages so that you can search through them later.
      - jacquesm 12y ago
        That alone would be a great reason not to use them.
        LaurentVB 12y ago
        It's also a great reason to use them, isn't it? Your searchable chat history basically becomes the knowledge base of your company.
        gaadd33 12y ago
        And a great target for discovery in any sort of lawsuit.
        brandon272 12y ago
        As is email.
        ncza 12y ago
        To me, that is something that you should keep internal, on internal systems with vetted free software.
        deleted 12y ago
        [deleted]
        brackin 12y ago
        It's why I love Slack. If I remember a conversation about something two months ago I go to the room, search and find exactly what I needed.
- higherpurpose 12y ago
  Maybe it's time for Slack to adopt the Axolotl ratchet, too.
  - smerritt 12y ago
    I'd love for them to do that, but there's a couple of problems that they'd have to overcome first. First: Slackbot. This is a Slack-run bot that's in every channel; team owners can customize it to do various things, like scan messages for keywords and give out canned responses. Even if Slack adopted some variant of encrypted chat, each message would still need to be readable by Slackbot, so Slack would still have the means to collect every message. Second: channel history. When I join a channel, I can see the messages in that channel from before I joined. This means that Slack (the server) must be able to give me those historical messages. In an encrypted group chat, the messages are encrypted only with the keys of the participants at that time, which means newcomers can't read them. I'm sure there are other features in conflict with end-to-end encryption, too; these are just off the top of my head.
    - icebraining 12y ago
      The first could be solved by having the activation part of the bot run on the clients themselves, and only send those messages in a readable way to the server. As for the second, the server could ask one of the clients to re-encrypt the channel history with the newcomer's key. It would only fail if nobody was online the moment you joined the channel (and you still could get it later).
ihodes 12y ago
The post notes that the breached database is the user table, which would not contain chat history. I agree that making this abundantly clear makes sense.
- benatkin 12y ago
  This makes it sound like other data was compromised for some specific users. Since they didn't go into how they know it was only for only these users, I'm not very confident about this. > 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. Unless you have been contacted by us directly about a password reset or been advised of suspicious activity in your team’s account, all the information you need is in this blog post.
  - octo_t 12y ago
    I would suspect things like "being used from a completely new country" or something similar. Could be those are the accounts with weak passwords that the attacker tried the top 10,000 passwords against.
  - ablankst 12y ago
    This is actually an interesting point. A compromised user table could conceivably be used for all sorts of nefarious purposes. If the attackers "having access" to the information in that table includes the ability to modify that table, then it is pretty much open season on Slack. For example, an attacker could replace a target user's password-hash with a hash that the attacker knows the plaintext of. Depending on the implementation of the random salt, the attacker may have to replace the salt as well. Then, the attacker logs in as the user, downloads the desired chat history, logs out, and sets the password hash to the original. Not enough information was really given in the blog post, but by the sounds of it, some teams experienced more targeted attacks.
- SideburnsOfDoom 12y ago
  If you get the user table, you can log in. If you can log in as (some) users. If you can do that, you can see (some) chat history. edit you can log in if and when you crack some of the hashes.
fillskills 12y ago
My concern are the usernames, emails and phone numbers that were probably not encrypted
- bitsweet 12y ago
  ultimately passwords can be changed; internal chat messages regarding personal and confidential data can not be taken back.
  - toomuchtodo 12y ago
    User metadata can be used for social engineering, and people are typically the weakest link.
- ipedrazas 12y ago
  Exactly!!! Encrypting user data should be a common practice like hashing passwords.
  - laumars 12y ago
    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)
    - schrodinger 12y ago
      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.
      - lucian1900 12y ago
        Or just the application. Generally, it's much easier to convince apps to give you the data instead.
serve_yay 12y ago
It's still worth mentioning, even if it's not your "first concern".
justinv 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)." Under their FAQ on the post. It could be inferred that there was some unauthorized access to certain users' communication logs?
deleted 12y ago
[deleted]

> 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 ago

Agreed. The content of the chat's would be potentially much more important in my mind.

hazelnut 12y ago
Which leads to the question if slack encrypts the chat data in the database.
- mateuszf 12y ago
  That would make implementing search quite hard so I'd say - it's pretty likely they don't encrypt it.
  - smt88 12y ago
    If 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 ago
      If they encrypted it, Slack would have to hold the key, so that all users in an org can then read existing messages.
      - smt88 12y ago
        No, it could be a private key shared among users.
  - newobj 12y ago
    That's not right. There is no need to store text body in order to index it. Furthermore, you can implement an index of token hashes, rather than an index of tokens.
    - polyfractal 12y ago
      It would remove a lot of nice search features, however. If you just index tokens without positional information, you have a much harder time performing phrase matching. If you include positional information, you can probably crack the encryption because some tokens are statistically more likely to appear next to each other than others. If you index shingles (phrase chunks) instead, you lose out on sloppy phrases...you can only match exact phrases. I imagine you can perform a similar statistical attack too. Hell, just getting the term dictionary would probably allow you to reverse engineer the tokens, since written language follows a very predictable power law. Hashing also removes the ability to highlight search results, which significantly degrades search functionality for an end user. Basically, yes, you can do search with encrypted tokens...but it will be a very poor search experience.
  - skatenerd 12y ago
    This reminds me of the plot of Silicon Valley
  - sukilot 12y ago
    If they dont encrypt storage they are highly negligent. Index and search are done in RAM,which is slightly harder to steal than disk data.
- jacquesm 12y ago
  Is there a good reason to keep chat data longer than it takes to deliver it to the recipient?
  - buttsex 12y ago
    They archive chat messages so that you can search through them later.
    - jacquesm 12y ago
      That alone would be a great reason not to use them.
      - LaurentVB 12y ago
        It's also a great reason to use them, isn't it? Your searchable chat history basically becomes the knowledge base of your company.
        gaadd33 12y ago
        And a great target for discovery in any sort of lawsuit.
        brandon272 12y ago
        As is email.
        ncza 12y ago
        To me, that is something that you should keep internal, on internal systems with vetted free software.
      - deleted 12y ago
        [deleted]
      - brackin 12y ago
        It's why I love Slack. If I remember a conversation about something two months ago I go to the room, search and find exactly what I needed.
higherpurpose 12y ago
Maybe it's time for Slack to adopt the Axolotl ratchet, too.
- smerritt 12y ago
  I'd love for them to do that, but there's a couple of problems that they'd have to overcome first. First: Slackbot. This is a Slack-run bot that's in every channel; team owners can customize it to do various things, like scan messages for keywords and give out canned responses. Even if Slack adopted some variant of encrypted chat, each message would still need to be readable by Slackbot, so Slack would still have the means to collect every message. Second: channel history. When I join a channel, I can see the messages in that channel from before I joined. This means that Slack (the server) must be able to give me those historical messages. In an encrypted group chat, the messages are encrypted only with the keys of the participants at that time, which means newcomers can't read them. I'm sure there are other features in conflict with end-to-end encryption, too; these are just off the top of my head.
  - icebraining 12y ago
    The first could be solved by having the activation part of the bot run on the clients themselves, and only send those messages in a readable way to the server. As for the second, the server could ask one of the clients to re-encrypt the channel history with the newcomer's key. It would only fail if nobody was online the moment you joined the channel (and you still could get it later).

ihodes 12y ago

The post notes that the breached database is the user table, which would not contain chat history. I agree that making this abundantly clear makes sense.

benatkin 12y ago
This makes it sound like other data was compromised for some specific users. Since they didn't go into how they know it was only for only these users, I'm not very confident about this. > 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. Unless you have been contacted by us directly about a password reset or been advised of suspicious activity in your team’s account, all the information you need is in this blog post.
- octo_t 12y ago
  I would suspect things like "being used from a completely new country" or something similar. Could be those are the accounts with weak passwords that the attacker tried the top 10,000 passwords against.
- ablankst 12y ago
  This is actually an interesting point. A compromised user table could conceivably be used for all sorts of nefarious purposes. If the attackers "having access" to the information in that table includes the ability to modify that table, then it is pretty much open season on Slack. For example, an attacker could replace a target user's password-hash with a hash that the attacker knows the plaintext of. Depending on the implementation of the random salt, the attacker may have to replace the salt as well. Then, the attacker logs in as the user, downloads the desired chat history, logs out, and sets the password hash to the original. Not enough information was really given in the blog post, but by the sounds of it, some teams experienced more targeted attacks.
SideburnsOfDoom 12y ago
If you get the user table, you can log in. If you can log in as (some) users. If you can do that, you can see (some) chat history. edit you can log in if and when you crack some of the hashes.

fillskills 12y ago

My concern are the usernames, emails and phone numbers that were probably not encrypted

bitsweet 12y ago
ultimately passwords can be changed; internal chat messages regarding personal and confidential data can not be taken back.
- toomuchtodo 12y ago
  User metadata can be used for social engineering, and people are typically the weakest link.
ipedrazas 12y ago
Exactly!!! Encrypting user data should be a common practice like hashing passwords.
- laumars 12y ago
  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)
  - schrodinger 12y ago
    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.
    - lucian1900 12y ago
      Or just the application. Generally, it's much easier to convince apps to give you the data instead.

serve_yay 12y ago

It's still worth mentioning, even if it's not your "first concern".

justinv 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)." Under their FAQ on the post. It could be inferred that there was some unauthorized access to certain users' communication logs?

deleted 12y ago

[deleted]