Are Magic Links secure?
How to use magic links securely for your product
A Magic Link is a single-use URL that authenticates a user when clicked.
It is a UX pattern that has grown in popularity over the last couple of years, especially after users started getting more familiar with it by logging into Slack or Medium. For more details on what a Magic Link is and how you can use it, check out our blog post here.
This is all well and good, and you can see the immediate benefits from a user conversion perspective, but how is this secure?
The tl;dr; version
- Implementation of Magic Links needs to be tailored for your particular web app.
- Magic Links inherently eliminate password security headaches.
- Magic Links need to be implemented as single-use and have an appropriately short expiry time. The secrets used to generate Magic Links need to be protected server-side at all costs.
Problem with Magic Links
There are some inherent security considerations with Magic Links. While most of these can be addressed within the behaviour of the Magic Links themselves, how it is implemented is crucial to the overall security of your web app.
The considerations fall into 2 broad categories.
- Magic Links are like username / password combinations when valid.
Since Magic Links are pre-authenticated, these links are essentially like passwords for your users. Therefore, if a Magic Link gets to a user who is not the intended recipient, your users’ accounts can get compromised. - Magic Link generator is an attack target.
Even worse is if an attacker gets their hand on a set of keys responsible for generating the Magic Link for your app. This would mean all your users are vulnerable.
Why we believe Magic Links are still great
Superior UX
Your users can be onboarded faster through the appropriate use of Magic Links, as highlighted here.
Magic Links reduce the security issues that come with passwords
It is crucial that magic links are used in the right way for the correct use case and that a considered approach is taken into account security.
Let’s start with eliminating passwords. With this, the headache of passwords is eradicated. It is a well-known fact that passwords are inherently insecure for a multitude of reasons.
- Approximately 60% of people tend to reuse their passwords, making them very vulnerable for attackers. If a website had poor password management practices (e.g. leaving them unhashed in a database and is not secured by at least 2FA) and that site’s users also happen to be your users who tend to reuse their passwords, you are leaving them wide open for an attacker to compromise their data.
- Passwords are also prone to phishing sites to grab user credentials and then reuse them on real sites like yours.
- Even for apps with good password management practices like salting and hashing the passwords, an attacker can run a narrowed search of common passwords and likely passwords in a dictionary attack if the database gets compromised.
By eliminating passwords from the entire flow, you avoid such headaches.
However, this transfers the security risk to the email provider of the user and the security measures email providers take in securing access to it. Gmail, for example, can detect logins from a different device and prompt 2FA credentials for the user to authenticate.
It is to be noted, that a Magic Link-based authentication is at least as secure as password-based authentication since password reset flows (where a reset password link is emailed to the user) carry the same level of risk as Email Magic Links.
How to make Magic Links more secure
Magic Link security
- Magic Links should be single-use.
Magic Link should be able to be used only once and should fail when used a subsequent time. This means it should contain a single-use code that can be exchanged for an auth token. - Magic Links should have an appropriately short expiry time.
The Magic Link expiration should ideally be < 15 minutes (with exceptions). This means a shorter exposure to email sniffers.
While ideal, point no.2 cannot be applied to the use case of one-click email authentication, where you can send mass marketing emails or email newsletters with embedded Magic Links. Since the user did not initiate these emails, a longer expiry is required (a few days) to allow the user a chance to be able to view the email and click on the link. The outbound marketing flow described above is an excellent tool to boost user retention and conversion.
However, there are some principles that can be applied to secure your web app based on the use case. Differentiate between “Signup” and “Login”; i.e. when the user clicks on the Magic Link, are they signing up for the first time or are they logging in as an existing user?
In the case of mass marketing email campaigns or scaled email outreach, chances are they are first time users. In the case of recurring email newsletters, chances are they are existing users logging in.
This is important in judging how long the Magic Link expiry should be.
Magic Link Expiries
To elaborate on the diagram above,
- A first-time user has no data to protect, so a long lasting Magic Link is more appropriate.
- A user logging in with an existing account has data to protect, so a long-lasting Magic Link is only appropriate if the protected data is non-sensitive (e.g. no personal, payment or health data).
- If the data is indeed sensitive, it would be better to:
-> Refrain from using long-lasting Magic Links OR
-> Use them in conjunction with another factor of authentication either immediately as they log in or before they perform a sensitive action. For example, embed a Magic Link in a newsletter; the user clicks on it to log in straightaway without heading a login screen; user can access all parts of the app but when user tries to perform a sensitive action such as making a payment or accessing personal details send them a new Magic Link to be able to perform the action.
The same principles applies in a scenario on an onboarding journey where you do not want to ask the user to leave your onboarding flow to click on an email link. You would rather let the user in, in an unverified state; however before they can access sensitive information you can send them a Magic Link to perform just-in-time authentication.
Magic Link generation security
If you are generating the Magic Links yourself, you should apply similar principles from password storage to storing the temporary link, including hashing and salting.
If you are using a third-party service to generate the Magic Links, such as EZiD, the Client Secret must be protected server-side and should never be exposed to a client. It is recommended to have internal processes and access control in place to determine who has access to the Client Secret. This is because if this is exposed, an attacker could use Client Secret to impersonate you to, in turn, impersonate your users.
UX
Communicating clearly to your customers forms a critical part of this. Your customers should be able to identify that a link is a Magic Link very clearly, so that it is obvious to them not to share or forward it.
This can be addressed through the UX, for example, by wrapping the Magic Link in a button that clearly says “Log in” or “Sign up”. If they enter the web app through an embedded Magic Link in a marketing email, you can make the authenticated state in the web app really obvious to the user that they have logged in. You can even write a ‘do not forward’ message if you wish.
So…
With appropriate consideration given to the implementation of Magic Links, it can be a very powerful and secure tool to onboard your users faster.
Interested?
Are you interested in securely implementing Magic Links? You can check out our EZiD APIs to get started.
