Closed Bug 1348975 Opened 7 years ago Closed 6 years ago

Slack OS X desktop uses built-in Chromium for SSO login rather than system browser

Categories

(Security Assurance :: General, task)

x86
macOS
task
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: Atoll, Assigned: srich)

Details

While logging in with Slack desktop OS X, I noticed that Duo asked me to thumb my U2F key. This is impossible in Safari and Firefox, which means that they could only be using Chromium in-process. Three problems occur as a result of this:

1) My system browser is already signed-in to Mozilla. By refusing to use my system browser to complete the login process, they take the "Single" out of "Single Sign-On", forcing an unnecessary extra "enter your LDAP password" "approve your MFA token" process every week on several hunderd users.

2) My system browser has access to my saved passwords. By refusing to use my system browser, they prevent me from easily accessing my LDAP password as stored in a secure repository, and instead require me to open up the store, find the password, copy it to the clipboard, and paste it manually.

3) The Slack app has full capability to read my keystrokes on the SSO form. One of the most valuable security protections of SSO on the web is that you never enter your password into a third-party site. I trust my vendor-provided browser to keep my keystrokes to itself. I have no such reassurance about Slack.

There are only two ways on OS X that Slack can correctly do SSO in a secure manner:

a) Open the Auth0 session in the default system browser, using a callback to provide the received token to the app.

b) Open the Auth0 session in an WKWebView, using decidePolicyForNavigationAction in the WebPolicyDelegate of your WKWebView to provide the received token to the app.

Apple has banned the solution Slack is using on the *mobile* iOS store, which is why (presumably) their app uses either a) or b) rather than the insecure, MITM-able option they present today.
Assignee: nobody → gene
Status: NEW → ASSIGNED
(In reply to Richard Soderberg [:atoll] from comment #0)
> While logging in with Slack desktop OS X, I noticed that Duo asked me to
> thumb my U2F key. This is impossible in Safari and Firefox, which means that
> they could only be using Chromium in-process. Three problems occur as a
> result of this:
> 
> 1) My system browser is already signed-in to Mozilla. By refusing to use my
> system browser to complete the login process, they take the "Single" out of
> "Single Sign-On", forcing an unnecessary extra "enter your LDAP password"
> "approve your MFA token" process every week on several hunderd users.
> 
> 2) My system browser has access to my saved passwords. By refusing to use my
> system browser, they prevent me from easily accessing my LDAP password as
> stored in a secure repository, and instead require me to open up the store,
> find the password, copy it to the clipboard, and paste it manually.
> 
> 3) The Slack app has full capability to read my keystrokes on the SSO form.
> One of the most valuable security protections of SSO on the web is that you
> never enter your password into a third-party site. I trust my
> vendor-provided browser to keep my keystrokes to itself. I have no such
> reassurance about Slack.
> 
> There are only two ways on OS X that Slack can correctly do SSO in a secure
> manner:
> 
> a) Open the Auth0 session in the default system browser, using a callback to
> provide the received token to the app.
> 
> b) Open the Auth0 session in an WKWebView, using
> decidePolicyForNavigationAction in the WebPolicyDelegate of your WKWebView
> to provide the received token to the app.
> 

Apple has banned the solution Slack *desktop* is using today on the *mobile* iOS store which is why (presumably) their mobile app uses either a) or b) rather than the insecure, MITM-able option they present today. Their desktop app needs to follow that same logic, no matter what theoretical UX improvements come from using an embedded browser for SSO.
(In case anyone asks, https://medium.com/posts-from-emmerge/implementing-an-oauth2-login-flow-in-wkwebview-de74e23fe9ee is what it looks like to use WKWebView to handle callback URLs from OAuth-ish flows.)
:atoll's assessment is right (as in I also tested this, due to his comment - I previously only used the web site/client instead of the "native" client myself).
The fixes can only be done on Slack's side and we should start the dialog with them (since they've having this issue with the Apple Store as well this seems like a good time for this).

Adding :srich for vendor communications
To be clear: They may or may not have *had* this issue on iOS, but they either no longer do or very soon will not, because Apple won't approve new uses of anything other than the (a) or (b) model and has made it very clear that existing uses should get on with the (a) or (b) model. I have no information on where they stand vs. App Store (OS X) for this.
Assignee: gene → gdestuynder
Assignee: gdestuynder → srich
Sent email to vendor on 3/21 asking for escalation to engineering/security. Account rep and customer success manager out of office until 3/24. Will follow up on 3/28
I noted today while signing in to a non-SSO Slack service that their "magic email link" service implements precisely what would be necessary here. To describe a more secure workflow here:

1) User instructs Slack desktop app to sign in to our.slack.com
2) Slack says "Sign in with SSO" in the desktop app
3) User clicks "Sign in with SSO" in the desktop app
4) Desktop app opens system default browser to SSO signin URL, with ReturnTo= as noted in 6)
5) User's system browser processes SSO sign-in request, optionally challenging for credentials and/or MFA if they have no active SSO session already.
6) When SSO signin concludes, SSO processes ReturnTo= argument to the same URL that "magic email link" ends up at: https://our.slack.com/z-app-10282920000-162320000000-tz70000000?s=1
7) User clicks the "Launch Slack" button on this page, which returns them to the Slack desktop app, logged-in.

This meets all of the many benefits described above, and requires little or no additional coding for Slack, as they already have infrastructure in place to deal with 'system browser' sign-in. To wit:

a) This puts the 'Single' in SSO.  By using the system browser, in which the user probably already has an active SSO session, most of the time users won't even have to enter credentials or MFA to finish signing in.

b) This prohibits Slack.app from having the technical capability to sniff SSO credentials.  By using the system browser, which runs in an isolated process from Slack with its own security model, we shut down an entire category of attack and no longer need to evaluate whether Slack handles our credentials correctly.

c) This is a simple change to make. Slack can easily alter the "sign in with SSO" button to open in system browser rather than built-in browser, and to return to the same URL used above for "magic email link" signin (6) in the system browser to return handling to the desktop app.
I would be happy to provide a video of the "magic email link" process, with optional voiceover, if that's easier than text here.
Slack shipped a release that fixed this briefly, but it locked some of us out of Slack+SSO, so they reverted. Anyways, it'll be fixed eventually by upstream, no point in keeping this around.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.