Should personal information, email, be removed from the magic link in Email provider

[hongymagic]

Would a (longer and shorter expiry) token be enough to identify the magic link?

Leaving a breadcrumb of personal information via URLs don't seem like a great default for a auth package. Was this ever discussed? Was there a concern with lack of rate-limiting or anything else that stopped from having a single or combination of tokens?

I couldn't find any issues/discussions, so tarting one here.

[richardasymmetric]

We just had a security audit done our our software, and this exact issue was raised:

Sensitive information is sent to the server via URL query string parameters. An attacker who gains
access to any location where URLs are stored will be able to view sensitive information passed
via the query string.
Depending on the nature of the information, a malicious user may obtain personally identifiable
information (PII), private user data or information which would allow user impersonation (in the
event of credential or session identifier exposure).

And both token and email are flagged.

@balazsorban44, sorry for pinging you directly, I'm not sure if this should go through the vulnerability reporting or not, but I'd love to hear your opinion on this.

[balazsorban44]

When in doubt, ALWAYS ASSUME PRIVATE, RESPONSIBLE DISCLOSURE. See https://authjs.dev/security

That said, I'll answer this here as the discussion is 2 years old and haven't seen it until now... (it's a shame that OP didn't check for security policies, when talking about "auth best practices" 😔)

PII is not a vulnerability but a privacy concern. And we can definitely do better. In fact, since the latest versions, it is now possible to create a flow where the email is not part of the URL.

This would require you to modify the sendVerificationRequest method on the provider to craft a url without the email, as well as modify your adapter's useVerificationTokens method to not look up tokens by a combination of token+email.

We recently started doing checks in the core libraries to support even custom adapters not tested by us to handle this correctly.

If your company considers the email exposure as a privacy concern, you can implement this stricter flow.

As for the token, that's how Magic links work, and it's a cryptographically random value (with enough entropy to withstand brute forcing several times the age of the universe). This value is then stored in the database for a short amount of time (configurable by the developer, one day by default) in a hashed form, so even a db leak would not let an attacker use the code. Other than that, the token is never stored anywhere else, and transmitted with your chosen email provider to the user's email address directly. The email content, including the link is fully configurable via the sendVerificationRequest method.

This form was chosen over OTPs by the original library author, to avoid a developer needing to add rate-limiting on top of their app, since OTPs have significantly lower entropy.

(That said, I think we can still support this by allowing only one attempt per OTP in the future, I'm actually working on this)

I'm also adding a DX improvement to handle cases where corporate email clients click email links, by first sending the user to a UI with a verify button. On that page, we'll actually make use of the email query param for UX purposes to let the user know which email they actually authorize. To avoid a DB lookup, the transmission of the email in the query param is convenient, but not mandatory as mentioned earlier.

I hope this is exhaustive enough of an answer. If not, please reach out according to our security policy and let's continue chatting in email.

Happy to answer more questions about the topic there!