3 ms·

I think Slack has an extra step where it sends some token from the browser that opened the link to the Slack app. This way just opening the link is not enough.

by kichik 7y ago

I think Slack has an extra step where it sends some token from the browser that opened the link to the Slack app. This way just opening the link is not enough. Links can be opened by the controller of the email even if they didn't make the original request. Links can also be opened by something scanning the email before the user sees them. Neither of these potentially malicious use-cases are covered by emauth.io.

anderspitman 7y ago
Both valid points. I think the email scanner issue will be especially common. Could you explain more how the Slack browser token would work? Warning the user not to open the link if they weren't expecting it is a pretty common approach. My initial plan was to require the user to reply to the email, which solves the scanner problem and has the benefit of not opening a new tab. This comes at the cost of being an unfamiliar flow, and requiring an extra click. What are your thoughts on that? I ended up starting with links since it worked for me (apparently gmail and fastmail don't pre-open links) and was simpler to implement for the prototype. Also it's less dependent on the speed of the user's email server.
- jesseendahl 7y ago
  > Could you explain more how the Slack browser token would work? Hi Anders — see my comment above for how do to this.
jesseendahl 7y ago
This is more or less what we do at Fleetsmith for our magic link login functionality, to defend against the threats you’ve mentioned. We store the user’s session ID at the time they request the email be sent, and then validate it’s still the same session ID when the token (which is a parameter on the URL) is consumed. If you’re using something like Mailchimp or SendGrid to send emails, this design also protects against a scenario where the email service is compromised by an attacker. The attacker will be able to see the emails, but will be unable to use the links to login.
- tjoff 7y ago
  This breaks the use-case where the user is on a desktop computer but checks mail on their phone. Not too rare of a thing. Or segments their browsing in different browsers/containers.
  - anderspitman 7y ago
    Yeah, working across devices is a must. I'm leaning towards the reply-to-verify flow I mentioned above. What are yall's thoughts on that?
    - jesseendahl 7y ago
      As another commenter (gregmac) mentioned, you can still allow clicking the link from a mobile device, but only authorize the session ID of the original browser for login. The only flow that’s not possible then is to start login on one device and finish it on another, which seems pretty niche (why would the user start a login process on desktop if they wanted to login on their phone?). To clarify, it’s still possible to allow for this user flow with the design I mentioned: 1. Request magic link on desktop. 2. Click magic link on mobile. 3. Become logged in on desktop. gregmac mentioned (correctly) the things you’d want to do in terms of UI/UX if you want to allow for this flow. A reply based design leaves you open to attacks because you have no way of having strong security guarantees/validation on the email reply. You would have to rely on validating that the email has valid DKIM, but DKIM won’t be available 100% of the time. And without DKIM the reply could be spoofed.
      - anderspitman 7y ago
        > why would the user start a login process on desktop if they wanted to login on their phone? I've run into this a lot for things like when I want to log in to a public computer, such as to print something. Having a logged-in device with you makes this much quicker. > A reply based design leaves you open to attacks because you have no way of having strong security guarantees/validation on the email reply. You would have to rely on validating that the email has valid DKIM, but DKIM won’t be available 100% of the time. And without DKIM the reply could be spoofed. It's just as strong as using a link, because you can verify against the message ID of the original email. And has the advantage that it's not going to be triggered by your email client without action on your part. Plus you can use DKIM when it's available as a bonus security layer.
vi-mode 7y ago
Out of curiosity: Which email service is opening links itself? Yes, they scan attachments or check for domains known being malicious but opening links??
- anderspitman 7y ago
  I too am curious about this.
- gruez 7y ago
  If you don't visit the link, you only have the url to go by. If you visit the link, you can analyze the contents of the page as well.
  - anderspitman 7y ago
    So what happens when an email scanner opens a Slack link?
anderspitman 7y ago
After talking through this thread a bit, I realized that I'm pretty sure emauth.io already works the way you're describing. Having the link alone is not enough to login. Only the process (whether in browser, on your server, curl, or whatever) that made the original request will know that the email has been verified. The browser that opens the link simply gets a text response that says the email was verified (or failed if already expired). You can use that information however makes the most sense. For a secure application, it would be used by your server to validate a session.

by kichik 7y ago

anderspitman 7y ago

Both valid points. I think the email scanner issue will be especially common. Could you explain more how the Slack browser token would work? Warning the user not to open the link if they weren't expecting it is a pretty common approach. My initial plan was to require the user to reply to the email, which solves the scanner problem and has the benefit of not opening a new tab. This comes at the cost of being an unfamiliar flow, and requiring an extra click. What are your thoughts on that? I ended up starting with links since it worked for me (apparently gmail and fastmail don't pre-open links) and was simpler to implement for the prototype. Also it's less dependent on the speed of the user's email server.

jesseendahl 7y ago
> Could you explain more how the Slack browser token would work? Hi Anders — see my comment above for how do to this.

jesseendahl 7y ago

This is more or less what we do at Fleetsmith for our magic link login functionality, to defend against the threats you’ve mentioned. We store the user’s session ID at the time they request the email be sent, and then validate it’s still the same session ID when the token (which is a parameter on the URL) is consumed. If you’re using something like Mailchimp or SendGrid to send emails, this design also protects against a scenario where the email service is compromised by an attacker. The attacker will be able to see the emails, but will be unable to use the links to login.

tjoff 7y ago
This breaks the use-case where the user is on a desktop computer but checks mail on their phone. Not too rare of a thing. Or segments their browsing in different browsers/containers.
- anderspitman 7y ago
  Yeah, working across devices is a must. I'm leaning towards the reply-to-verify flow I mentioned above. What are yall's thoughts on that?
  - jesseendahl 7y ago
    As another commenter (gregmac) mentioned, you can still allow clicking the link from a mobile device, but only authorize the session ID of the original browser for login. The only flow that’s not possible then is to start login on one device and finish it on another, which seems pretty niche (why would the user start a login process on desktop if they wanted to login on their phone?). To clarify, it’s still possible to allow for this user flow with the design I mentioned: 1. Request magic link on desktop. 2. Click magic link on mobile. 3. Become logged in on desktop. gregmac mentioned (correctly) the things you’d want to do in terms of UI/UX if you want to allow for this flow. A reply based design leaves you open to attacks because you have no way of having strong security guarantees/validation on the email reply. You would have to rely on validating that the email has valid DKIM, but DKIM won’t be available 100% of the time. And without DKIM the reply could be spoofed.
    - anderspitman 7y ago
      > why would the user start a login process on desktop if they wanted to login on their phone? I've run into this a lot for things like when I want to log in to a public computer, such as to print something. Having a logged-in device with you makes this much quicker. > A reply based design leaves you open to attacks because you have no way of having strong security guarantees/validation on the email reply. You would have to rely on validating that the email has valid DKIM, but DKIM won’t be available 100% of the time. And without DKIM the reply could be spoofed. It's just as strong as using a link, because you can verify against the message ID of the original email. And has the advantage that it's not going to be triggered by your email client without action on your part. Plus you can use DKIM when it's available as a bonus security layer.

vi-mode 7y ago

Out of curiosity: Which email service is opening links itself? Yes, they scan attachments or check for domains known being malicious but opening links??

anderspitman 7y ago
I too am curious about this.
gruez 7y ago
If you don't visit the link, you only have the url to go by. If you visit the link, you can analyze the contents of the page as well.
- anderspitman 7y ago
  So what happens when an email scanner opens a Slack link?

anderspitman 7y ago

After talking through this thread a bit, I realized that I'm pretty sure emauth.io already works the way you're describing. Having the link alone is not enough to login. Only the process (whether in browser, on your server, curl, or whatever) that made the original request will know that the email has been verified. The browser that opens the link simply gets a text response that says the email was verified (or failed if already expired). You can use that information however makes the most sense. For a secure application, it would be used by your server to validate a session.