Hey quick question. I thought I read it somewhere,...
# security-discussion
t
Hey quick question. I thought I read it somewhere, but in the passwordless recipe, do the one time tokens only work when used at the device that caused the email to be sent?
r
OTP, yes (since the originating device has device id and preauthsessionid stored in localstorage), magic link, no (since the link contains all the necessary information)
t
Interesting... Couldn't you local storage an extra token (in combination with the token that's in the link of course) and then validate both on the back-end?
r
what do you mean? Could you rephrase please?
t
Like as a thought exercise, trying to get magic links to be bound to the device that caused the sign-in. My solution would be to ask the back-end to send the email. Then have the back-end send an email and respond with an additonal token. The front-end could store this into local storage, so that when the link in the email is clicked, the front-end can send both the email and local storage tokens to the back-end to authenticate. Alternatively, maybe the back-end could set a cookie and also remember a redirect url. Then the email could open the url at the back-end server (which could be different from the website domain where the client lives). The back-end server can then check the email code and the cookie it set earlier to authenticate.
Or I guess in short... aren't there solutions to making the email link only work on the device that caused the email?
Although, perhaps it's a non-issue since the link probably has a limited lifetime and intercepting the link without email access is probably very difficult if not impossible. And once an attacker does have access to someone's email, then why bother stealing links if you can just login using a new link haha
r
Exactly. That would just cause bad UX in many cases anyway. So no point.
9 Views