Tell HN: Security notice from Slack regarding Shared Invitation links
5 comments
I’m willing to bet someone `JSON.stringify`’d the entire user object without realizing the password hash is in there.
The broader conversation I think here is facilitating a shift to passwordless. Magic links, OAuth, Yubikeys all make passwords redundant.
If I put in a password I still need MFA and I can reset my password with just MFA, so why do I need the password at all? Let’s just switch to MFA-only signon.
Slack kinda led the charge to magic links and passwordless so it’s strange to see they’re still stuck on this. Many enterprise orgs have moved SSO setups to enforce solely passwordless already.
The broader conversation I think here is facilitating a shift to passwordless. Magic links, OAuth, Yubikeys all make passwords redundant.
If I put in a password I still need MFA and I can reset my password with just MFA, so why do I need the password at all? Let’s just switch to MFA-only signon.
Slack kinda led the charge to magic links and passwordless so it’s strange to see they’re still stuck on this. Many enterprise orgs have moved SSO setups to enforce solely passwordless already.
While getting rid of passwords is admirable and advisable, I don't think it is the answer here. What happens when `JSON.stringfy` posts your fancy magic link token somewhere undesirable?
Applications will always need to generate, process, and transmit sensitive data. They 'just' need transit it to trusted places. Easy! ;)
Filtering data before it gets to untrusted sinks, or at least warning when it does, seems like a more generalizable pattern. The downside is you both need to know what's sensitive and go out of your way to handle it as such in basically any language or framework.
Cases in point: * https://www.google.com/search?q=java+avoiding+logging+sensit... * https://www.google.com/search?q=golang+avoiding+logging+sens... * https://www.google.com/search?q=python+avoiding+logging+sens...
Applications will always need to generate, process, and transmit sensitive data. They 'just' need transit it to trusted places. Easy! ;)
Filtering data before it gets to untrusted sinks, or at least warning when it does, seems like a more generalizable pattern. The downside is you both need to know what's sensitive and go out of your way to handle it as such in basically any language or framework.
Cases in point: * https://www.google.com/search?q=java+avoiding+logging+sensit... * https://www.google.com/search?q=golang+avoiding+logging+sens... * https://www.google.com/search?q=python+avoiding+logging+sens...
I also received such messages. I think I could sleep more easily if there was a notice on the Slack website as well concerning this issue.
I searched briefly but couldn't find one; does anyone else know more?
I searched briefly but couldn't find one; does anyone else know more?
----
We’re writing to let you know about a bug we recently discovered and fixed in Slack’s Shared Invite Link functionality. This feature allows users with the proper permissions to create a link that will allow anyone to join your Slack workspace; it is an alternative to inviting people one-by-one via email to become workspace members. You are receiving this email because one or more members of your workspace created and/or revoked one of these links for your workspace between April 17th, 2017 and July 17th, 2022. We’ll go into detail about this security issue below.
Important things first, though: We have no reason to believe that anyone was able to obtain plaintext passwords for users in your workspace because of this vulnerability. However, for the sake of caution, we have reset impacted users’ Slack passwords. They will need to set a new Slack password before they can login again. A list of impacted users is below.
<redacted>
Now, for some technical details — feel free to skip the next two paragraphs if that doesn’t interest you. When you’re connected to Slack, we keep your client updated using a piece of technology called a websocket. This is an always-open stream of behind-the-scenes information, specific to just you and your account, that we use to push new information to your Slack client. When a new message is posted, a new file is uploaded, a new emoji reaction is added, or a new teammate joins, all of this information (plus much more!) is sent to you over a websocket. Data streamed from Slack’s servers over the websocket is processed by the Slack client apps, but often hidden from the user's view.
One of the hidden events we send over the websocket is a notice that a shared invite link was created or revoked. The bug we discovered was in this invite link event: along with the information about the shared invite link, we included the hashed password of the user who created or revoked the link. This information was sent over the websocket to all users of the workspace who were currently connected to Slack. The hash of a password is not the same as the password itself; it is a cryptographic technique to store data in a way that is secure, but not reversible. In other words, it is practically infeasible for your password to be derived from the hash, and no one can use the hash to log in as you. We use a technique called salting to further protect these hashes. Hashed passwords are secure, but not perfect — they are still subject to being reversed via brute force — which is why we’ve chosen to reset the passwords of everyone affected.
When your users reset their passwords we recommend selecting a complex and unique password. This is easiest to do by using a password manager to help generate and store strong, unique passwords for every service.
If you have additional questions, or if you need our help as you investigate this issue, you can reply to this message or email us [email protected].
We know that the security of your data is important. We deeply regret this issue and its impact on your organization.
Sincerely, The team at Slack