1

I'm guessing this applies to all implementations of sign-in links, but since I'm using Firebase I'd like to understand their concerns: https://firebase.google.com/docs/auth/web/email-link-auth#security_concerns

Do not pass the user’s email in the redirect URL parameters and re-use it as this may enable session injections.

What exactly are the concerns here?

Knowing that Firebase sign-in links:

  • Expire after 6 hours
  • Can only be used once
0
+100

TL;DR: Don't bypass the restrictions imposed by firebase on the application you develop. Although by default firebase doesn't allow you to change these values afaik, you have the options to create a custom e-mail template and a flow and "add" the tweaks.

Firebase "verifies" the user before creating a session by something the user know and another thing that user has. In this case e-mail and the link the user received in order.

In traditional approach, this is username and password.

If you put the "e-mail" information in to the object the user supposed to have, you reduce the factors from two to one.

And also if you let user to reuse the same object instead of unique asset that is generated every time the user intentionally request, you further reduce the security.

Take this examples:

  1. Developer generates a sign on link that is reusable and e-mail address embedded. And user goes on and pastes this link somewhere public. In this case anyone clicking on the link will log on as the same user.

  2. Developer generates a sign on link that is only reusable. User pastes the link to a chat application where others can see or guess its e-mail. With minimal effort, others will be able to log on as the same user.

The document just explicitly warns the developers to not bypass or workaround the restrictions imposed by firebase as you mentioned.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.