The most surprising thing about this article isn't the article; its the comments in here, and the surprising number of people who have no clue how Slack works or how corporate/enterprise regulation & compliance works.
"the surprising number of people who have no clue how Slack works or how corporate/enterprise regulation & compliance works" Why would this be surprising? Most of us have probably never cared to think about these subjects. Your comment would be a lot more useful it contained some information about these subjects instead of just expressing your shock that some people don't know things that you do. edit: I guess this i…
Slack enables customers to control their encryption keys in enterprise version
81–90 of 178 posts
Re: Slack enables customers to control their encryption keys in enterprise version
#82Earlier quoted context omitted.
The article says it’s only open to enterprise customers. Computing freedom you have to pay a ton for is not really freedom. It’s really not even close to the control of IRC.
Is it not worth Linux running on mainframes because mainframes are expensive? Is it not worth Kerberos being free software because the only real users of Kerberos are enterprises? Computing freedom for anyone is computing freedom, and contributes to a norm of user control instead of service provider control. This step is a very small step, and it only affects a few users. But it's still a step in the right direction.…
The non-strawman scenario would be if Linux only ran on expensive mainframes.
Re: Slack enables customers to control their encryption keys in enterprise version
#83Isn't this just shifting partly your trust from Slack to Amazon?
I think it's very smart of Slack. AWS Encryption SDK[1] is a well designed, battle tested data encryption library. Amazon KMS is a well audited service used by AWS to manage all sorts of keys and even supports external HSM integration. For slack to build all this from the ground up would be time consuming. Hard part being 3rd party validation, penetration testing and certification. [1]: https://docs.aws.amazon.com/en…
However, this pattern is good and IMHO should be adopted by SaaS orgs that want to appeal to enterprise/regulated customers. We have a few vendors that we're sort of pressing in this direction, and a few have come to us with similar architectural proposals to address GDPR.
Specific to AWS it would be even better of the service allowed for the customer to host the CMK in their own account so they can choose to import key material if they like. This has some downstream implications on what you can do with the key vs. Amazon-generated CMK which may be advantages in some cases.
Re: Slack enables customers to control their encryption keys in enterprise version
#84The most surprising thing about this article isn't the article; its the comments in here, and the surprising number of people who have no clue how Slack works or how corporate/enterprise regulation & compliance works.
Very generally surprising in that maybe we expect folks to be a bit more technical at hacker news.
Less so when we realize how widely varied technology and businesses are and you can be a hyper smart, productive and technical and know nothing about how other technology works.
I worked with someone who I managed to establish a working relationship with a very capable engineer at a previous job. Without getting into details he did some chip design and once you got "in" with him he was a great asset to work with if you were on the support side (where I worked at the time). I made a joke once when his phone was having a problem that some of our equipment must be between his phone and the server and it was having X problem (something we were working on). I'm 90% sure he actually didn't realize that the equipment the company made was ultimately something that could in fact be between his phone and the server. He was amazing at his job ... just didn't need to know that thing to be that way.
Re: Slack enables customers to control their encryption keys in enterprise version
#85Earlier quoted context omitted.
>All it takes is for a admin (or hacked admin account) to change the password of the target slack user and login as said user to view all their private messages. An admin cannot change a user's password. You can enable an account wide feature which allows admins to view all messages but that's separate and costs money. Also not what you described.
I don't think that's true. In the corporate world, Slack is authenticated with AD/SAML/etc. and Slack has no idea who is changing passwords on that backend system. The reality is that IT administrators are the root of trust at all organizations. This new feature doesn't change that.
Re: Slack enables customers to control their encryption keys in enterprise version
#86Earlier quoted context omitted.
I wouldn't say "nothing"–it's certainly not complete control but it reduces the attack surface. I don't control the proprietary password manager I use, but the fact that I control the encryption keys and they don't means I'm less vulnerable to attacks on their service infrastructure.
EKM does not provide the same security as a password manager for the content (i.e. Slack messages and passwords). In this case Slack is still able to request a key from the KMS in order to perform operations over the messages (search, archive etc). Those keys generally have some sort of expiration on them by default (hour, day, etc) before they're rotated. However, during that window the key could be copied and used…
I don't understand that about companies. The trust situation just doesn't change:
Before "managing their own keys", they
have to trust Slack to not break their security
After, they have to trust Slack to not break their security
But I've seen enterprises take and in fact insist on this often. It never seems to matter that this is a useless gesture. A signed contract that they won't break their security, which is a far less invasive and easier measure, is better. At least that provides some recourse.Re: Slack enables customers to control their encryption keys in enterprise version
#87Re: Slack enables customers to control their encryption keys in enterprise version
#88Earlier quoted context omitted.
The article says it’s only open to enterprise customers. Computing freedom you have to pay a ton for is not really freedom. It’s really not even close to the control of IRC.
It's pretty clear many customers don't want control, they want features, and irc lacks those.
Re: Slack enables customers to control their encryption keys in enterprise version
#89Reads more like "Hands over control to any customer that will pay for it." [1] I wonder if the UI shows the employees that their employers have the keys. [1] Edit: as opposed to only regulated customers. Also, there's an upcharge...you don't automatically get control.
What is your expectation if the UI does not show that? That your communication is private? Why would you expect private communication when using your employer's infrastructure or, worse, a third party infrastructure like Slack? If you don't own the keys, it's not your data.
No. Just feel like who owns the keys is relevant. I can see, for example, if my employer is using a self-signed cert within my browser. Though I understand they have other ways to see what I'm doing in a browser even if there is no MITM cert.
Re: Slack enables customers to control their encryption keys in enterprise version
#90The most surprising thing about this article isn't the article; its the comments in here, and the surprising number of people who have no clue how Slack works or how corporate/enterprise regulation & compliance works.
I have no idea how corporate/enterprise regulation & compliance works in relation to Slack. Could you elaborate?
What it boiled down to is you have to be able to track every communication you can, and depending on the jurisdiction, you had to keep it around for 7-25 years.
Not only did you have to keep it around, you had to provably keep it in such a way that it couldn’t be “sabatoged”, generally this meant you had to store it on “WORM” (Write Once, Read Many) storage.
The basic rationale is because of the $$ involved, you wanted to make sure no one was a) insider trading, b) defrauding investors, c) defrauding the bank.
Banks are pretty good at these types of controls.
Example controls they do:
1. You can’t trade outside of their monitored platform
2. You are mandated to take a vacation of at least 2 weeks every year (once you reach a certain level), the idea being that any “off books stuff” you may be doing would get exposed.
3. They regularly “flag” specific keywords, and not just the obvious ones, to identify bad actors. I won’t go into details, but it is much more robust than you think.
Just my 2 cents...
Minor edit: spelling