4 ms·
> 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
by 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.
- jesseendahl 7y ago> 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. Again, this flow is still very much possible with a design that verifies session ID. Please re-read my last comment and gregmac’s comment carefully! To be really clear, you can design it so that you: (1) start the login process on a public computer, (2) click the link on a mobile device, and (3) end up logged in on the public computer. And you can do this while ensuring that the session ID is the same in steps #1 and #3.
- anderspitman 7y agoI think I see where the confusion is coming from. emauth essentially already works the way you're describing. It validates whatever session makes the original request. Having the link isn't enough to login on its own.