Jump to content
FlorianA

ForgotPassword: Why so complicated?

Recommended Posts

I've just tried the ForgotPassword module and I wonder why the password reset process can't be smoother for the user. Especially I don't understand why there must be this "verification code" that has to be transfered manually to the password reset form. Why couldn't it be integrated directly into the URL? It shouldn't make any difference as to security since both URL and verification code are transfered through the same channel (e-mail) anyway.

I'm planning to migrate my current non-PW site to PW, and since I don't have my user's clear-text passwords, I can't migrate them, too. That means I'll have to force all my users through the password reset procedure, and I really wouldn't like to make this more tedious than necessary.

Another feature request: I'd like to confirm the additional field values in the first step (before sending the e-mail) rather than in the last one. I think this would not only improve user experience, but it would also allow to use e-mail rather than user name for identification even if there are duplicate e-mail adresses, since you could use the confirm value field for disambiguation.

Share this post


Link to post
Share on other sites

 

Moderator Note

Moved this topic to General Support

Share this post


Link to post
Share on other sites

First of all: for feature requests you might want to open an issue at https://github.com/processwire/processwire-requests. This is how it'll have the best likelihood of gaining the attention of Ryan 🙂

12 hours ago, FlorianA said:

Especially I don't understand why there must be this "verification code" that has to be transfered manually to the password reset form. Why couldn't it be integrated directly into the URL? It shouldn't make any difference as to security since both URL and verification code are transfered through the same channel (e-mail) anyway.

I do agree that a sufficiently complex and rapidly expiring initial key embedded within an URL should be enough, but saying that the verification key wouldn't add any extra security isn't, in my opinion, completely fair. The longer the key the more secure it should be, and a second verification method (particularly one that user has to enter separately) adds another layer of safety. Technically it could also a) force the user to actually read the message, and b) prevent attacks where the user is somehow fooled into clicking an URL — though I'm not sure how common attack vector this would be.

The way I see it, current implementation trades some ease of use to some extra safety, and personally I'm fine with that: password reset process should be a relatively rare occurrence, and attacks targeting such features are a common problem. (But you do make a good argument here; perhaps this should actually be a configurable setting for the module?)

12 hours ago, FlorianA said:

Another feature request: I'd like to confirm the additional field values in the first step (before sending the e-mail) rather than in the last one. I think this would not only improve user experience, but it would also allow to use e-mail rather than user name for identification even if there are duplicate e-mail adresses, since you could use the confirm value field for disambiguation.

Again I think this depends a bit on your of view: on one hand current implementation makes sure that if one just gains access to a reset link they won't be able to change the password (particularly if you ask them to confirm something other than the email field), but on the other hand some experts recommend that this step should occur before sending the reset message (exactly for the same reason — security).

Seems like another potential module setting to me, perhaps even so that both options (confirmation before and confirmation after) would be available.

12 hours ago, FlorianA said:

I'm planning to migrate my current non-PW site to PW, and since I don't have my user's clear-text passwords, I can't migrate them, too. That means I'll have to force all my users through the password reset procedure, and I really wouldn't like to make this more tedious than necessary.

Just a quick note on this one: you don't actually have to force the users to go through the password reset procedure. In a case like this it'd be relatively simple to set up a custom process to handle the initial password reset — create and send the links to your users and process them through your own code. I've done that a few times during large scale migrations, and it's not that hard to do — though in most cases I would still recommend going through the password reset feature. Personally I don't think that the process is that hard on users.

Just an idea — again I get that you're hoping to change things in general, but if you need to get this done on a timely manner, it would probably be best not to wait for a core level change. Especially since it isn't necessarily a complete no-brainer how this feature should work 🙂

  • Like 3

Share this post


Link to post
Share on other sites

@FlorianA, you can probably achieve what you want by using hooks. ProcessForgotPassword::renderEmailBody is hookable and includes the link URL as an argument, to which you could add the verification code (which is also an argument) as a GET parameter.

Then you could hook before InputfieldText::render and if the field name is "verify" (you could do additional checks if needed) you could check $input and set the value from the GET parameter.

  • Like 4

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...