Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The previous standard setting to NOT enforce new password on password reset needed back as a configurable option for security reasons on untrusted networks #2794

Open
LeeteqXV opened this issue Aug 15, 2017 · 2 comments

Comments

@LeeteqXV
Copy link

Both in lack of 2FA, and even after we get it, it is useful with the option NOT to enforce new passwords on password reset

On my current Backdrop 1.7.x sites I can not get any kind of 2FA to work in any way yet. Since I do NOT want to send a password when logging in from for example a cafe, hotel, travel junction, client network, insecure public wifi networks, or the like, the most practical way is to use the "forgotten password" function (having made sure beforehand that the account in question is using an email address where I actually HAVE 2FA login), and then get a login link to that one.

However, since BD is insisting that I create a new password on the SAME (untrusted) connection, then that extra security option is lost...

The standard Drupal behaviour that actually does NOT enforce the password change was changed (deliberately) for some other reasons in #140
I agree that some sites, and even perhaps the default behaviour, might be desirable to have as it is now (although I think that the main challenge here is more related to presentation / GUI logic to avoid confusion, than to the side effects of either choice...), but I think we need to have the choice, not remove the option entirely.

Furthermore; AFTER we actually get something like TOTP (see #2788 ), it is also then very useful to be able to use 2FA + email link over such insecure wifi connections, so the option of NOT having to set a new password is still relevant.

It would be nice for web sites to have the option to choose the policy that is appropriate for them, so this should be a configurable setting in the account settings page, IMO.

In case this (IMO very valid/relevant security scenario) was not considered when this behaviour was changed, then I think that we could consider this issue as a bug report (forgotten consideration), and not a new feature request.

@ghost ghost added the type - bug report label Nov 4, 2019
@quicksketch
Copy link
Member

quicksketch commented Jan 20, 2020

If you want to log in without setting a password, you can tack /login to the end of the password reset URL. Then you are logged in without setting a password. If you so wanted, you could edit your password reset templates and add /login to the end of the password reset URL token.

Although Drush uses this capability to log in without setting a password, we don't expose it easily. We could make another dedicated function and token to make this more easily accessible.

Right now we have user_pass_reset_url() we could make a companion user_one_time_login_url().

Same for tokens. Oddly we have a token named [user:one-time-login-url], which gives you a reset URL. IMO it would be much better to have [user:password-reset-url] that does the reset, while the current token would do the immediate log-in.

@stpaultim
Copy link
Member

stpaultim commented Jan 21, 2020

Related issue: #4281

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants