Pkp-lib: Passwords should not be emailed. Ever. (2.0)

[mtub]

Passwords should not be emailed. We had a discussion (@ctgraham, @asmecher) about this, see #745. IIRC, it was decided to keep the support for the password variable in legacy versions of the applications, but remove it completely from the master/dev branches, see #750. That was 2015.

In 2016, we got this: #1469 (OJS) and this #1524 (OMP).

And now, OJS 3 still sends unencrypted emails with passwords. I cannot see why, but maybe I missed something. I'd really like to see this changed, what do you think?

[TobiasWantzen]

What's the alternative? Spontaniously I'd send a temporary password by mail, valid for 2 hours, »User must change password on next log in.« activated.

[WaDelma]

Usually password resets are handled by sending link to change the password that can be only used one time and is only valid for certain time.

[asmecher]

As I understand it, we're emailing only temporary passwords when a change is required upon use, which is equivalent (in my opinion) to sending out a hash. There's at least one thing we could probably improve upon, which is a limited window for credentials (whether hash or password) sent in this way.

[ctgraham]

I prefer eliminating any use of a temporary password in favor of consistent use of a password reset hash. The hash is a dedicated-use tool and is inherently time-sensitive.

[forgive38]

Hello,

Currently, with ojs 3.1.1, the process to reset a password is still in 2 steps:
1- receive a email with a one time link, then when you follow the link, you
2 - receive a email with a temporary password, that you have to change the first time you use it.

I think the first step is enough.
One ambiguous thing for the second step, is the mail (email_text key="PASSWORD_RESET")
It is written "We have included your username and password in this email, which are needed for all work with this journal through its website." so I think the mail should be something like "the password included in this mail is temporary, you have to change it the next you log on the website"

thank you

[mtub]

I'd like to push this again… please let's get rid of passwords in emails.

[mtub]

@asmecher, @ctgraham - is there any chance of moving forward with this?

[asmecher]

(The two-step nature of the password reset email also came up in the latest email/notifications UI/UX review. Adding the UI/UX label.)

[jalperin]

+1 for eliminating 2-step password reset. The workflow I typically see is, click "forgot password"; get an email with a hash; click link and be logged in and prompted to set up a new password.