E-Mail with login name and password in plain text

[auge8472]

When testing a few things in the update procedure i came across an issue with the after-registration-e-mail. The issue occured with version 2.4.24 as starting point of the tests and affects the case of a user, registered by the admin, who gets the welcome e-mail. The issue consits of four parts.

1. The e-mail contains the user-name and the password in plaintext.
2. The e-mail contains both, the user-name and the password, in one e-mail.
3. The e-mail contains a link for an immediately login, unveiling the user-name and the password in plaintext again.
4. The link with the login data breaks when the password contains one or more space chars. This in itself is not an issue of the script, but it shows the necessity to deal with special chars in the context of URL-parameters.

 '' => '%20'

My idea to solve the issues at once: Because the e-mails are always plain text, the first issue is not solvable. But we can mitigate the problem by sending user-name and password in two separate e-mails. This would mitigate the sub-issues one and two.

Sub-issue three and four (especially for this case) is solvable with removing the password from the login URL and to add an one time token instead. This solution would need a bit more effort than only splitting a message in two e-mails. Replacing the password with a token only solves nothing. So the user must provide something additional, i.e. the password in a second step after calling the tokenised URL from the e-mail. Additionally at least the forum operator, maybe also the user itself, must be able to resend a token.

For the sub-issue four itself we should check our e-mail- templates for URLs, that contain URL-parameters which could possibly contain chracters, that have to be masked in the URL-context. Most URLs should only contain message-IDs in the format of decimal numbers. So IMHO most of the URLs should be harmless.

Note: I didn't check, if the issue (one to three) occurs with up-to-date versions. I saw the issue during my tests for #643 in version 2.4.24 and wanted to document it so that it would not be forgotten.

[loesler]

Why not using a link like for the password forgotten function instead of sending the password in plain text?

[auge8472]

Why not using a link like for the password forgotten function instead of sending the password in plain text?

Another person another view.

Nice idea. But in this case it is questionable if the administrator must set a password when creating the account. The password will definitely be set by the user at first login. So there's no need to previously set another password by the admin. Beside the prevented effort for the admin (low with only one new user, noticeable when creating a bunch of accounts), an empty password field would be a suitable trigger to enforce the user to set a new password. We can take advantage of this in example for planned resetting of passwords.

Your hint sounds reasonable.🤔👍