
What If All Your Slack Chats Were Leaked? - hbgb
https://www.nytimes.com/2019/07/01/opinion/slack-chat-hackers-encryption.html
======
jedberg
I live by the following hierarchy:

\- Anything written down and transmitted digitally will be available to anyone
who wants it eventually. Besides my copy, the recipient has a copy, as do any
number of intermediaries. Encrypted or not, that encryption will almost
certainly be broken in my lifetime.

\- Anything written down on physical medium or stored digitally (but not
transmitted) will be freely available to anyone that wants it eventually. It's
slightly more secure than a digital copy, because I have physical control over
the only copy and would most likely know if that physical control was
compromised (so my NAS is considered transmitted since it is possibly
accessible).

\- Anything I say to someone in person is pretty safe, depending on how much I
trust them not to record what is said (otherwise it becomes classified as
digitally transmitted). Of course now a copy remains in their mind's eye,
which is in some cases worse since it can be modified and they don't even know
it.

\- Any thought I have that I have never expressed outside my body is almost
completely safe, baring successful administration of truth serum (or until
someone invents adversarial brain scans).

How does this affect me in real life? I don't write down things I wouldn't
want other people to know, and I am pretty careful about saying things I don't
want other people to know. I use encryption whenever I can because it will at
least slow down the attackers, but I never assume something that is encrypted
is safe.

~~~
weinzierl
> \- Anything written down [..]

> \- Anything I say to someone [..]

In my hierarchy these two points are swapped. At least I think there is a real
chance to keep written material secret as long as you are not a target of a
state level adversary. I can write in a room where I am sure there are no
cameras watching and I can put my copy in a safe where I would know if it was
compromised. On the other hand I can almost never be sure not be audio
recorded - be it deliberately or accidentally by any of the microphones that
are almost everywhere nowadays.

~~~
penagwin
I had a similar comment.

We're increasingly surrounded by microphones/cameras, some of which are
embedded in IOT or other appliances.

Given the NSA's track record, the risk of devices getting hacked, etc. I've
become rather conscious of potential implications they could have.

------
fencepost
There seems to be a fundamental assumption here that's just _completely
wrong,_ and that is that there's a way to guarantee that your chat logs /email
/search history /whatever can ever be 100% secure from disclosure. This is as
wrong as assuming you don't need backup because you have RAID, excellent
malware protection, are fully patched, have great sprinklers, are geologically
stable, not in a flood plain, etc.

You need to start from the assumption that _it can happen here_ and take steps
to ensure that damage is minimal /recoverable. Part of that is policy, part
culture, another part is technical but none are sufficient by themselves. On
the tech side, look at systems designed to comply with data protection laws.

~~~
Bartweiss
I didn't get that assumption from the article at all. (Unless you meant "on
HN" instead?)

To me, the article's focus on permanently deleting old messages specifically
_avoids_ that error - it's not about avoiding disclosure but as defense-in-
depth since disclosure is always a possibility. Beyond that, avoiding Slack
(even with data deletion) is unlikely to increase security, but it does
decrease priority for smaller users who might be swept up in an attack on
Slack in general.

------
yters
Slack seems like a huge single point of failure. The chat logs across who
knows how many companies and groups all stored on a single set of servers by a
single company. All it takes is one bad insider with the keys to the kingdom,
or just a government backend into the system, and all the secrets are loosed.
And who's to say Slack employees don't watch our chat logs already? I really
don't get the amount of trust placed in Slack, especially in the IT industry
where everyone is very aware of security.

------
thomastjeffery
I worked at a company that uses Slack as its main casual communication medium.

One day, I walked into a meeting to learn that I was being fired without
warning, and would have absolutely no opportunity from that moment forward to
log in to any of my business-related accounts.

That sudden unexpected contextual change really puts the lack of privacy
control into perspective.

Suddenly, all the conversations that I had had with other coworkers were taken
away from me, and made available to whoever was in charge of handling my old
logins. Is that really acceptable?

I always make a point to remember the communication medium that I am using,
and to filter myself respectively, but how many events like this exist that I
have no control of? How can I predict the events that will put my privacy in
jeopardy? What text exists that I would have liked to be more private?

~~~
gdulli
I don't think the firing changed anything, though. You have to assume your
employer had access to your chats already. And emails, etc. Your net privacy
didn't change.

~~~
thomastjeffery
Two things changed drastically:

1\. My access to that record. I can no longer audit or edit that information.
Even though I made a constant _effort_ to preserve my privacy, I am left with
a worrying lack of certainty. After all, I can't be expected to remember many
months worth of communication, or what out of that I may find concerning in
this new context.

2\. My relationship with my (ex) employer. Sure I could have assumed an
eventual change in that relationship from the beginning, but it's still
drastic to have that change come suddenly and without warning.

I realize those are subtle, and that - hopefully - they do not become an
issue. I only want to highlight my experience, because I found it eye opening.

The real issue is that there is an _informal_ expectation of privacy without
the user having permanent control over his/her information.

------
mbritton72
Anonimnity is fake. Assume your conversations in Slack are reviewed, don't be
mean and sneaky, and you're all set. If you're a true dick irl, Slack will
only serve to magnify that fact.

~~~
thomastjeffery
> and you're all set

Except the desire for privacy isn't limited to the rude things you say.

None of us truly wants to live in a world where a third party can secretly
review a permanent record of our communications.

------
DyslexicAtheist
once worked for a start-up that went through a high amount of churn and
employee turnover. one of the pain points was the know-how being locked inside
Slack threads and we had hit the 10K message limit months before I joined. The
place was also politically toxic and the CEO was mostly the cause of this.
Initially when I had still some passion left I suggested to move Slack to a
self-hosted Zulip installation (threaded topics FTW) because the CEO
constantly complained about having to pay for Slack subscription and he was
_totally against this as somebody who believes in FOSS_.

After getting this Zulip migration approved the CEO pulled the plug in the
last minute because he realized during a discussion about how to handle the
import of the original messages - that all the old (toxic) discussions would
now be in the hands of his internal employees and they couldn't be trusted not
reading all the shit him and everyone else said behind each others back.

This made me aware that Slack has some interesting reasons for why teams are
locked into their SaaS platform which may have nothing to do with scalability
or uptime. In our case it was fear of libel lawsuits and further turnover.
While you might be able to live with the insider-threat at SlackHQ with them
being able to read your messages, sometimes the idea that anyone in your IT
can read everything management has said shared or discussed in the past may be
too risky for most.

~~~
rishig
In case anyone runs into this in the future, Zulip has a few features that
could help:

* You can set a message retention policy that will delete each message after N days. (We're building the UI for it, but currently you can email support@zulipchat.com for help on turning it on.)

* On Zulip Cloud, you can set a message visibility limit that will save all your messages (e.g. for legal/compliance reasons), but only the last N messages will be visible to the team.

------
mapcars
First thought: who the hell would be interested to read thousands of lines of
discussions like how to name a field in REST response or notifications of
someone making a build xD

~~~
Cthulhu_
Nobody, but it's not about that. It's about trade secrets, access keys for
e.g. AWS, git; it's about private information that can be used for social
engineering or extortion. If a malicious actor can take over someone's account
they could do even more convincing social engineering and access confidential
information.

If you think "I have nothing to hide" you're lacking in imagination.

~~~
Beldin
Note: Privacy is about consent, not about hiding.

------
ltbarcly3
What if all your search history were leaked? What if all your text messages
were leaked? What if all your emails were leaked? I guess those things aren't
trendy enough to worry about.

For a long time I have noticed what I would call 'ankle biting journalism'.
Basically take whatever is trendy, make only the most obvious observations
about it (things that someone who only rudimentary knowledge would come up
with in a few minutes), then act like these obvious things are _serious_ and
_there is a problem here_.

As usual, it's not that serious, and there isn't a problem here. I have no
idea how Slack stores user chat history, but lets say they store them in plain
text in the cloud. Then Slack is about as secure as IRC, which is exactly what
it is trying to be, IRC 'but better'.

Besides, if you are using Slack for work, whoever is the 'Owner' of the
enterprise account can export and view every conversation whenever they want,
because 'compliance'.

~~~
ken
"In hindsight, complying with the company's Document Retention Policy (which
at Netscape was basically, ``shred anything within 90 days unless you can't
get your job done without it'') might have been a good idea." [1]

Do companies no longer have Document Retention Policies? That seems like the
bigger piece of the story here.

[1]
[https://www.jwz.org/gruntle/rbarip.html](https://www.jwz.org/gruntle/rbarip.html)

~~~
ilikehurdles
FYI if you're referred from hackernews and have never visited the site before,
the jwz links redirect to (somewhat nsfw: photoshopped testicle in an egg cup)
[http://i.imgur.com/32R3qLv.png](http://i.imgur.com/32R3qLv.png).

------
zztaway2019
I worked for a fortune < 10 company. One day I found a complete dump of all
public AND PRIVATE slack messages sitting on a dev server that was open to
all.

I reported it to security. Next day I'm suspended. Turns out security did it
because they wanted to search through 'just in case' but didn't want to go
through the process properly.

Either it was my fault or they were incompetent, guess which one they chose. I
was forced to quit eventually.

~~~
simonebrunozzi
I hope you hired a good lawyer and made them pay handsomely for this. They
would have deserved it.

~~~
zztaway2019
Oh yes, and they played the long game until it was economically self
destructive for me to continue. Never forget the time advantage a corporation
has over an individual.

In the end I lost all my equity.

~~~
Something1234
What would have been the correct way to handle such a discovery in order to
cover your own rear?

------
AndyMcConachie
I recently setup a Prosody server and gave out accounts to my friends and
family. Seriously folks, it's dirt simple. XMPP rocks!

------
james_pm
The single most terrible thing about Slack is the hostage holding of message
archives. You don’t pay? Fine...you get 10k message history, no ability to set
retention and Slack still stores all those messages forever, taunting me that
they have it all and won’t let me do anything with them.

That’s just user hostile. If I don’t pay, I shouldn’t have all that message
history stored forever. Either let me set retention on my messages or delete
anything over 10k automatically. Don’t hold my content hostage and make it
completely inaccessible and un-deletable unless I pay.

~~~
jmkni
I worked on a project a while ago that used this as a feature. They were
worried about a Freedom of Information request for chat archives (UK Govt
linked) so intentionally didn't pay for Slack, so most of the message history
wasn't available if a request came through.

~~~
gruez
>intentionally didn't pay for Slack, so most of the message history wasn't
available if a request came through.

I'm pretty sure that won't work. They keep the logs regardless of whether you
pay. It's not like if you don't pay for it, they erase your messages starting
at 10k. You can't see it, but upon paying for slack premium, you'll
immediately get access to them.

------
dsfyu404ed
I've been spending all these years holding my tongue because as a matter of
principal I don't write anything I don't want a permanent record of and it
would be nice to see all that overhead pay off or more accurately, it would be
nice to see people get burned for being sloppy. So no, I wouldn't really stand
to lose anything if everything I ever said on company chat was published in an
easily searchable format online.

~~~
smt88
1) Very few Slack users are chatting as though their messages could become
public at any moment. Maybe you don't have a problem, but this article isn't
about one person with extreme discipline.

2) There's no way to know now what you'd want to be private in the future.

For example, let's say you're gay and mention your boyfriend casually in a
Slack chat. Then your country outlaws homosexuality. Suddenly, a casual detail
becomes a secret you're terrified of getting out.

You can apply this analogy to your religious beliefs, traveling to certain
countries, or even reading certain websites. You just don't know what the
public or your govt will find unacceptable in the future.

------
czbond
When.... they all are leaked. Enron told us something (then it was email).

------
opticbit
Keybase has an import team from slack tool.

Keybase is open source and uses pgp. Easy for the the average user. Can be
used in command line.

Been using keybase for a while now, haven't tried the tool.

------
roemance
I've never understood why Slack can't add support for E2E encryption. I'm 100%
positive they've got large clients demanding this functionality.

~~~
ltbarcly3
They could, but I don't think it would really add much benefit. One of the
main features of Slack vs IRC is that Slack has persistent and consistent chat
history. If you look at apps like Signal, when you log on from a new device
your history isn't available, because of the end to end encryption used to
store the messages. To view the history you would have to be able to decrypt
it, but that means there has to be some mechanism for users joining a channel
for the first time to decrypt the history of that channel (unless you want to
break that functionality). Unless there is some really neat cryptography trick
I'm not aware of, that would mean you can't have end to end encryption where
each user's data is encrypted in a way that is opaque to everyone except
user(s) in the chat like Signal or Telegram.

Now I guess you could set up some kind of broker system and have like a
different encryption key per channel or per conversation or something, which
would at least mean some hacker has to get both the archived chats as well as
the keys. This would make stealing chat histories more complicated, but not
less possible.

~~~
yoz-y
In iMessage this was possible but all combinations of pairs of your devices
had their own keys. When a new device was added you needed to allow it from a
device already registered and they would then sync messages device-to-device.
This has resulted in quite a lot of mangled histories.

Now with iMessage in iCloud, I do not know how the E2E encryption is done.

~~~
konspence
>Now with iMessage in iCloud, I do not know how the E2E encryption is done

It isn't done. Apple holds the master keys. The trust is that the iCloud
server is not compromised.

~~~
yoz-y
I've read some discussions and key base articles and it seems that at least
the master key is encrypted using your pin code. Not much, but I guess one
could use a complex password.

~~~
konspence
Care to cite? I'm curious

~~~
yoz-y
[https://support.apple.com/en-us/HT202303](https://support.apple.com/en-
us/HT202303)

> Messages in iCloud also uses end-to-end encryption. If you have iCloud
> Backup turned on, your backup includes a copy of the key protecting your
> Messages. This ensures you can recover your Messages if you lose access to
> iCloud Keychain and your trusted devices. When you turn off iCloud Backup, a
> new key is generated on your device to protect future messages and isn't
> stored by Apple.

[https://pxlnv.com/linklog/improving-imessage-
encryption/](https://pxlnv.com/linklog/improving-imessage-encryption/)

> During an interview with Apple blogger and Daring Fireball’s owner John
> Gruber, Federighi said that the company has figured out a way to do syncing
> while still remaining unable to read your iMessages.

------
perlgeek
> Slack is one of many Silicon Valley unicorns going public this year, but
> it’s the only one that has admitted it is at risk for nation-state attacks.

Gosh, everyone who runs a computer is at risk for nation-state attacks.

The real question is: how high is the risk?

The risk section of an S1 tries to list every imaginable threat as a risk,
without any assessment of the probability or impact (the two components of
risk). Using this is a source for such an article is simply wrong.

------
deegles
I mean, the article is generally right but they immediately get a detail
wrong:

> Right now, Slack stores everything you do on its platform by default — your
> username and password ...

I would be extremely surprised if they store plaintext or even encrypted
passwords. Maybe the author means usernames/passwords sent in messages, but
that's not unique to slack.

~~~
hsnewman
If they don't store the password encrypted or in plaintext, how would they be
able to authenticate you? It must be stored somehow, either plaintext or
encrypted (preferred).

~~~
swebs
[https://en.wikipedia.org/wiki/Bcrypt](https://en.wikipedia.org/wiki/Bcrypt)

~~~
lucb1e
I don't know if it is generally discouraged on HN, but let me just say that I
find link-only answers discouraging (similar to lmgtfy) and of little value if
you don't highlight the important bit. Additionally, your link is about a
particular hashing scheme. Someone with no clue what hashing is will not be
helped by a link to a particular hashing scheme. The first link in the
article, however, gets you to a page that explains everything, and might have
been a much better text to cite and link:

> Password verification commonly relies on cryptographic hashes. Storing all
> user passwords as cleartext can result in a massive security breach if the
> password file is compromised. One way to reduce this danger is to only store
> the hash digest of each password. To authenticate a user, the password
> presented by the user is hashed and compared with the stored hash. A
> password reset method is required when password hashing is performed;
> original passwords cannot be recalculated from the stored hash value.

[https://en.wikipedia.org/wiki/Cryptographic_hash_function#Pa...](https://en.wikipedia.org/wiki/Cryptographic_hash_function#Password_verification)

------
LinuxBender
This may be a taboo take on systems like Slack and I know this will not be
popular given the number of developers here, but I had to explain this to HR
and it was not easy to convey these concepts in plain terms.

Slack itself is just a chat system. Ok, what's the risk? By design, people
(the user base, or admins, up to each company) can integrate third party
applications. The permissions system allows chat data to flow to these third
parties without any logging or visibility by the Slack business customer. So
in effect, each employee (depending on perms) may on behalf of their company,
relay all chat messages to third parties that their company does not have a
legally binding agreement and NDA with. This is the actual risk with Slack
(the product, not the company).

So by design, employees can leak all the chats for all of the #public channels
they are a member of and they won't even see it happening. Some companies
choose to have admins review the third party applications and integration.
"But they are #public, right?". People in a company don't assume that the
public channels are really public in the sense that third parties outside of
their company can see these messages. Employees may discuss very sensitive
topics about their own customers that may not be appropriate to relay to
extended parties that their company does not have mutually binding agreements
and NDA's with.

When you run your own servers such as IRC, Mattermost, etc.., the chat admins
know what third party servers (if any) they are linking to. This does not
preclude an employee from relaying their own data through their workstation,
but that can be addressed by edge DLP devices for monitoring or mitigation.
Even then, the employee knows exactly what they are relaying.

When the chat system itself is a third party, and that third party allows
relaying of user data, chat data to fourth parties, then by design, the system
will always leak data. Slack does not alert members in a channel which bots
are reading their messages real time and where that data is being stored and
who is reading it and for what purpose. This also becomes a problem for data
retention policies. The parties external to Slack may retain and use the data
for as long as they wish, even if Slack purge data from a channel after a
period of time. I see this as a legal quagmire.

In terms of leaking private messages, those are also stored so that an admin
in a company may review them by request. This is only an issue if Slack's
servers were compromised. That risk applies to both self hosted and third
party chat servers, though Slack becomes a much more juicy target by having
the private chats of many companies. This is similar to the risk of routing
non-static content through Akamai. Akamai had employees caught selling
sensitive data to other nations which highlights the risk of aggregating
private data through one transit provider that can decrypt your data or see
your data in plain text. This risk could be mitigated by having short data
retention policies, however that is the opposite of what users expect. They
expect their messages to be around forever.

------
ilikehurdles
I wouldn't care. I imagine our company wouldn't be too happy about the data
now available to its competitors.

------
gallamine
Keybase chat is very nice and I've switched to it for many things. Also has
self-destruct feature for messages.

------
duxup
That's a lot of silly gifs the hacker guys are going to have to filter
through....

~~~
ThePirateofOz
/giphy #mashup weak news clickbait

[http://media4.giphy.com/gifsu/2w5ffEOlO1ni8ArLnq/giphy-
overl...](http://media4.giphy.com/gifsu/2w5ffEOlO1ni8ArLnq/giphy-overlay.gif)

------
darepublic
I'm more afraid of my internet history being leaked by my isp

------
IronWolve
Thats ok, I'm safe, I use IRC.

------
rmdashrfstar
Has anyone attempted at building a chat solution, similar in scope to Slack,
that runs serverlessly? I imagine it’s technically possible, but perhaps not a
better self hosting option than something like Rocket.chat.

