Xjyuk

Our system uses passwordless login to send user a login code+link by e-mail by which they can login.

We found one of our customers has a mail scanner that actually follows those links. We invalidate the login codes on use to the reduce the attack surface for an attacker. But now such emails no longer have a valid login link.

There seem to be two solutions to this:

• Do not provide a login link but only a code in the message.


• Let the login code be valid after first time use for X period (say it invalidates after 15 minutes)

Option 1 seems to be unacceptable by our UX team.

Option two seems to be much less secure:

• Provides a bigger attack surface because more codes will be active in our database


• Social engineering will be easier: a user could take a picture of someones mail and type of the code within the valid period (even though user already used the code) and login with this code.

Would there be any other or better solution that would be both UX friendly and (atleast as) secure?

Instead of invalidating the login code when the link is clicked, have a script on the page that runs and makes a request to your server to invalidate the code. This will only be effective if the "mail scanner" just visits the page and doesn't run any scripts on it.

You should also invalidate the code after a period of time (your second option), because if the user is running a browser with scripts disabled the code will not be invalidated by this method. The timeout serves as a backup if this is the case.

If you find that whatever "mail scanner" your users have is running scripts on the page, this won't work. Instead, you could require a user action on the linked page to complete the login process. Your users would click the link in the e-mail and be taken to a simple page with a login button, and perhaps some text like Log in as <username>?. Only log them in (and invalidate the login code) when they click the button. This would require two clicks from your users instead of one, but I don't think that's too inconvenient.

Since the "mail scanner" will only visit the page and not click the button, it won't use up the code.

See this similar question.

Edit: I'm liking the login button click more and more. It doesn't rely on the mail scanner not running scripts so it should be more robust. You could even combine it with Steffen Ullrich's cookie idea. If the user clicks the login link in the e-mail and has the cookie, you know they're not the mail scanner so you can log them in right away. One click and they're logged in. If the cookie is NOT present, the click might actually be coming from the mail scanner, so you show a page with a login button. If it's actually just the user on a different browser (or the same browser with cookies disabled), they'll click the button and log in. In this case it took them two clicks, but that's only a slight inconvenience and it's only necessary if the cookie isn't there.

It is unclear in which context the password-less login is used. But, if the user gets send the link to login only after visiting the site, then you could issue a cookie to the users browser and expect this cookie when the user logs in.

Most users will likely use the same browser to login after getting the link via mail and in this case you could align the clicked URL with the cookie send by the browser. Since the security appliance has no knowledge of the end users cookies you can easily reject the click from this appliance.

In case the user uses a different browser for clicking the link or if the user has deleted the cookies explicitly or implicitly (like when using a new private browser session) you can still have an explicit token in the mail the user can manually enter to continue with the authentication.

This way almost all users are handled transparently when clicking the link, the remaining users can continue manually by entering the token and any automatic systems are left out - even if they are able to execute the Javascript on the page.

I would not count on the inability of these analysis systems to run script. I'm pretty sure that many will actually handle script since this is also a typical mechanism used in phishing mails to complicate analysis. Instead you should count on missing knowledge of the system (i.e. does not know the cookie) and not missing capabilities.

Log in only on POST request. The link in the email should not cause a login: it should simply link to a login page. The URL code can be extracted from the URL and put into a hidden form field. When the form is submitted, which the email scanner will not do, then, and only then, is the user logged in.

If you want to reduce user friction, you can have javascript submit the form automatically once the page loads.

I'll add my comment question as a possible stated answer.

Block the one-off customer USER-AGENT on your server? Couple with the customer Static IP.

Assuming these are sufficiently unique, you can make it transparent.

Don't hard code the one instance, assume it will happen again and set up a reference table of USER-AGENT and IP to be blocked. That way you can simply add to the table as required.