Password reset exposes if an account exists about fortify

[bkilshaw]

Fair enough -- in my opinion though leaking that information does depend on the nature of the site. Twitter, Youtube, Facebook, might not be a huge deal. You could actually probably assume a good chunk of people already do have accounts on those sites. With a package like Fortify though you don't always know what people are building with it and in some cases leaking that information could be much more personal; imagine if someone made like... "living-with-aids.com".

I get that as developers it's up to us to know and follow best practices, but it would also be nice for a package like Fortify to follow all and advocate the best practices as well.

[driesvints]

If you attempt to register an account on any app with an email address that exists you get the same result.

Using Twitter as grounds to dismiss a security issue is just ignorant.

Surely you're not comparing every website built with this to Twitter? Seems very detached from reality. You honestly cannot expect every small website to have the level of defence that twitter has against user enumeration spams.

In fact, as it stands you can spam this controller as long as you want and get all the emails/usernames you want even if it takes 3 months.

What about the systems that don't allow user registration and they have to be created by an admin?

This was a security issue 10 years ago. I really don't get why this is still an issue today.

[taylorotwell]

I'm not concerned about this:

[ali-alharthi]

@bkilshaw I totally understand this.
I build apps that are used by military/government contractors that don't have registration enabled. So I always respond with a success message that looks like the following:

If an account exists with the given email address an email with a password reset link should have been sent.

You can achieve this in Fortify:

1. Make sure that you are using your own routes and not Fortify's.
2. Extend the PasswordResetLinkController controller (only the store method) to return the following:

        return $status == Password::RESET_LINK_SENT
                    ? app(SuccessfulPasswordResetLinkRequestResponse::class, ['status' => $status])
                    : app(SuccessfulPasswordResetLinkRequestResponse::class, ['status' => $status]);

Or simply:

return app(SuccessfulPasswordResetLinkRequestResponse::class, ['status' => $status]);

And that should do the trick! I used to do the same with laravel/ui.

Like @taylorotwell said it is not a big deal but for some people like us it is! However, the majority don't mind leaking such information. Therefore, If you have a specific use case just extend (that is why I love Laravel).

[johanvanhelden]

I'm hoping for a way to easily do this without copy-pasting the Fortify routes and overriding the controller method. It makes updating a bit less easy.

Just a hook to override the response would be great and makes updating very easy.

[bkilshaw]

Not necessarily, especially when you're using email verification. There's no advantage to logging a user in after registration since they can't get in until they verify anyways. Ideally you display a message saying something more generic like "Thank you for your registration. Please verify your email by clicking the link in the email." This prevents exposing whether or not an email exists in the system in both the registration and password reset.

Over all by being more vague in the messaging you're able to prevent exposing user details. Hopefully Fortify can implement and advocate best practices since it's pretty much guaranteed to be widely used and can have a big impact.

[bkilshaw]

Thanks @ali-alharthi -- that's a much more thorough way to handle it compared to what I hacked together originally!

Still holding out that they eventually update Fortify to follow the best practices out of the box, but it's nice having the ability to easily make those changes!

[johanvanhelden]

My suggestion would be to add an option to specify our own response, with a value being available to us whether it was successful or not and the form input. This allows for maximum flexibility. So we could simply redirect->back with a generic message or show a detailed message.

In my case, I would send a message back like: If an account exists for "[email protected]", you will have received a confirmation mail.