When a administrator creates an account he has to create a password for the user and it is send as plain text.
This is a big security flaw and should be handled differently; e.g. send the user a link so that he can set his password by itself.
When a administrator creates an account he has to create a password for the user and it is send as plain text.
This is a big security flaw and should be handled differently; e.g. send the user a link so that he can set his password by itself.
<!-- github-sync-id:216007353 -->
At least warn that the password will be sent in clear text, especially when setting up the admin user on first start. With this info one could use a thrash password and change it afterwards to something secure.
At least warn that the password will be sent in clear text, especially when setting up the admin user on first start. With this info one could use a thrash password and change it afterwards to something secure.
<!-- github-comment-id:307165881 -->
But is there a way of forcing this to be disabled? and not letting it be up to the user
Thanks for your quick reply !
But is there a way of forcing this to be disabled? and not letting it be up to the user
<!-- github-comment-id:352675501 -->
Currently, there is no such "disable sending password by email to user" option. It could definitely be a simple option to implement (much simpler than sending a link to initialize password)
Currently, there is no such "disable sending password by email to user" option. It could definitely be a simple option to implement (much simpler than sending a link to initialize password)
<!-- github-comment-id:352677433 -->
Currently, there is no such "disable sending password by email to user"
option. It could definitely be a simple option to implement (much simpler
than sending a link to initialize password)
Until such an option is implemented, a user can change the template (child
theme, template extension, plug-in with a pre-filter)
Le 19 déc. 2017 09:47, "Pierrick Le Gall" <notifications@github.com> a
écrit :
> Currently, there is no such "disable sending password by email to user"
> option. It could definitely be a simple option to implement (much simpler
> than sending a link to initialize password)
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/Piwigo/Piwigo/issues/639#issuecomment-352677433>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/AAs-jWs_NK-T1h_OSmx8kqX6nLJXCWlWks5tB3gTgaJpZM4Mk9Yc>
> .
>
<!-- github-comment-id:352718867 -->
Currently, there is no such "disable sending password by email to user" option. It could definitely be a simple option to implement (much simpler than sending a link to initialize password)
There shouldn't be an option to 'display the password in the mail'. Passwords should NEVER be sent in plain text in an email.
> Currently, there is no such "disable sending password by email to user" option. It could definitely be a simple option to implement (much simpler than sending a link to initialize password)
There shouldn't be an option to 'display the password in the mail'. Passwords should NEVER be sent in plain text in an email.
<!-- github-comment-id:475913786 -->
If communicating the password over a different channel is considered too much of an effort, an administrator can always allow useres to register themselves, thereby also choosing their own passwords.
I'm a new user of Piwigo and really happy about it (thanks!), but just had this issue as well and have to say I'm a bit shocked. In my opinion, this is a serious security issue that, independently of a possible implementation of an initialization link, should be fixed in the meantime by removing the lines
https://github.com/Piwigo/Piwigo/blob/master/include/functions_user.inc.php#L245
https://github.com/Piwigo/Piwigo/blob/master/install.php#L513
optionally adding a comment that the password can be obtained from the administrator.
If communicating the password over a different channel is considered too much of an effort, an administrator can always allow useres to register themselves, thereby also choosing their own passwords.
<!-- github-comment-id:636374960 -->
Just installed a server today - password sent in plain text. Wow, noped that right off my server. Removing those lines is fine @DavidMStraub however, your point about a serious security issue is right on the money. I would think If Piwigo can see the password, so can someone else. The Piwigo platform should not be able to see anyone's password to send it. Haven't gone through all the code to see, just wondering if anyone else has or not.
Just installed a server today - password sent in plain text. Wow, noped that right off my server. Removing those lines is fine @DavidMStraub however, your point about a serious security issue is right on the money. I would think If Piwigo can see the password, so can someone else. The Piwigo platform should not be able to see anyone's password to send it. Haven't gone through all the code to see, just wondering if anyone else has or not.
<!-- github-comment-id:662451927 -->
When you log in, you send the username + password in plain text if you have an HTTP connection and not an HTTPS connection.
What I'm going to do right now is remove the password in the email sent by the installation form. This one is the most critical of course.
The email sent when an administrator creates a user is more complicated to remove, because Piwigo needs to handle it correctly. The solution proposed by @habakuk007 (sending a link to set the password) is nice and gives me the following idea:
the admin registers the user
the user receives an email with an "automatic login" link
Piwigo sees the user property needs_password_reset and as long as it is true, Piwigo asks to set the password
Piwigo does not store password in plain text.
When you log in, you send the username + password in plain text if you have an HTTP connection and not an HTTPS connection.
What I'm going to do right now is remove the password in the email sent by the installation form. This one is the most critical of course.
The email sent when an administrator creates a user is more complicated to remove, because Piwigo needs to handle it correctly. The solution proposed by @habakuk007 (sending a link to set the password) is nice and gives me the following idea:
1. the admin registers the user
2. the user receives an email with an "automatic login" link
3. Piwigo sees the user property `needs_password_reset` and as long as it is `true`, Piwigo asks to set the password
<!-- github-comment-id:662483146 -->
Sending passwords in plain text is not an issue, if they are "one time passwords" that needs to be changed immediately upon login.
We have addressed this issue globally at my employers (car manufacturing, so large, 300K employees, not Nissan) and the policy we set for that was discussed and agreed upon. Initial or OneTime passwords sent in e-mail, with a requirement to change them immediately, combined with the inability to see passwords anywhere - database or system files or whatnot - was accepted.
Admittedly we never addressed system owners or administrators passwords as mentioned initially in this scope, since they have huge responsibilities to handle this timely and efficiently.
In regards to Piwigo, how likely is it that you as admin request a password, get it in 30 seconds and during that time some hacker targets your site and effectively make an effort to intercept your mail?
I would rather direct the efforts towards two-factor authentication.
Sending passwords in plain text is **not** an issue, **if** they are "one time passwords" that needs to be changed immediately upon login.
We have addressed this issue globally at my employers (car manufacturing, so large, 300K employees, not Nissan) and the policy we set for that was discussed and agreed upon. _Initial_ or _OneTime_ passwords sent in e-mail, with a requirement to change them immediately, combined with the inability to see passwords anywhere - database or system files or whatnot - was accepted.
Admittedly we never addressed system owners or administrators passwords as mentioned initially in this scope, since they have huge responsibilities to handle this timely and efficiently.
In regards to Piwigo, how likely is it that you as admin request a password, get it in 30 seconds and during that time some hacker targets your site and effectively make an effort to intercept your mail?
I would rather direct the efforts towards two-factor authentication.
<!-- github-comment-id:670161875 -->
I stand corrected, if passwords are setup that way as described above then it’s fine to send via email. However there was no forced password expiry, although a bandaid, plegall came up with an alternative. I would vote for two-factor as well.
I stand corrected, if passwords are setup that way as described above then it’s fine to send via email. However there was no forced password expiry, although a bandaid, plegall came up with an alternative. I would vote for two-factor as well.
<!-- github-comment-id:670542246 -->
Sending passwords in plain text is not an issue, if they are "one time passwords" that needs to be changed immediately upon login.
We have addressed this issue globally at my employers (car manufacturing, so large, 300K employees, not Nissan) and the policy we set for that was discussed and agreed upon. Initial or OneTime passwords sent in e-mail, with a requirement to change them immediately, combined with the inability to see passwords anywhere - database or system files or whatnot - was accepted.
Admittedly we never addressed system owners or administrators passwords as mentioned initially in this scope, since they have huge responsibilities to handle this timely and efficiently.
In regards to Piwigo, how likely is it that you as admin request a password, get it in 30 seconds and during that time some hacker targets your site and effectively make an effort to intercept your mail?
I would rather direct the efforts towards two-factor authentication.
The system you are describing is out dated. More safe is to send the user an email with a link to set a password. But in Piwigo's case the user registers and sees the password he chose in the registration confirmation mail.
> Sending passwords in plain text is **not** an issue, **if** they are "one time passwords" that needs to be changed immediately upon login.
>
> We have addressed this issue globally at my employers (car manufacturing, so large, 300K employees, not Nissan) and the policy we set for that was discussed and agreed upon. _Initial_ or _OneTime_ passwords sent in e-mail, with a requirement to change them immediately, combined with the inability to see passwords anywhere - database or system files or whatnot - was accepted.
>
> Admittedly we never addressed system owners or administrators passwords as mentioned initially in this scope, since they have huge responsibilities to handle this timely and efficiently.
>
> In regards to Piwigo, how likely is it that you as admin request a password, get it in 30 seconds and during that time some hacker targets your site and effectively make an effort to intercept your mail?
>
> I would rather direct the efforts towards two-factor authentication.
The system you are describing is out dated. More safe is to send the user an email with a link to set a password. But in Piwigo's case the user registers and sees the password he chose in the registration confirmation mail.
<!-- github-comment-id:670946131 -->
Yeah, well you are right in so much that the system could be better and a password link as you describe is of course an even better solution. I never said I had the "best" solution...
Yeah, well you are right in so much that the system could be better and a password link as you describe is of course an even better solution. I never said I had the "best" solution...
<!-- github-comment-id:671519446 -->
Are there any updates on that? Passwords are sent in plain text to users when they register and this needs to be disabled.
Are there any updates on that? Passwords are sent in plain text to users when they register and this needs to be disabled.
<!-- github-comment-id:2034424944 -->
Yes, we've been re-discussing this subject a few week ago. We have 2 problems:
obviously, sending a password in clear text by email is a bad practice
emails are not our best friend, relying on it is not the best practice
Years after years, it's becoming harder and harder to successfully send emails (which would reach the recipient inbox, I mean). So I don't really like the idea to "send a short-period validity invite link by email". I would feel more confident in the ability to copy a "set my password" link from the administration, for a given user.
We need to think about the right UX to provide this link, but I would prefer to let the administrator decides how she sends the link to the user. It could be by text message, company internal chat, email...
Yes, we've been re-discussing this subject a few week ago. We have 2 problems:
1. obviously, sending a password in clear text by email is a bad practice
2. emails are not our best friend, relying on it is not the best practice
Years after years, it's becoming harder and harder to successfully send emails (which would reach the recipient inbox, I mean). So I don't really like the idea to "send a short-period validity invite link by email". I would feel more confident in the ability to copy a "set my password" link from the administration, for a given user.
We need to think about the right UX to provide this link, but I would prefer to let the administrator decides how she sends the link to the user. It could be by text message, company internal chat, email...
<!-- github-comment-id:2034536910 -->
Starting with version 15.0.0beta1, Piwigo will send an email with a link to set the password. Piwigo will also provide a way to copy this link, in case Piwigo would not be able to correctly send the email (email is so complex to make reliable...)
Starting with version 15.0.0beta1, Piwigo will send an email with a link to set the password. Piwigo will also provide a way to copy this link, in case Piwigo would not be able to correctly send the email (email is so complex to make reliable...)
<!-- github-comment-id:2200498564 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
When a administrator creates an account he has to create a password for the user and it is send as plain text.
This is a big security flaw and should be handled differently; e.g. send the user a link so that he can set his password by itself.
I agree, your solution would be better than current way of handling passwords.
At least warn that the password will be sent in clear text, especially when setting up the admin user on first start. With this info one could use a thrash password and change it afterwards to something secure.
Also when a new user registers they will receive an email containing the password in plain text.
@boge90 only if the checkbox " Send my connection settings by email " is checked
Thanks for your quick reply !
But is there a way of forcing this to be disabled? and not letting it be up to the user
Currently, there is no such "disable sending password by email to user" option. It could definitely be a simple option to implement (much simpler than sending a link to initialize password)
Until such an option is implemented, a user can change the template (child
theme, template extension, plug-in with a pre-filter)
Le 19 déc. 2017 09:47, "Pierrick Le Gall" notifications@github.com a
écrit :
There shouldn't be an option to 'display the password in the mail'. Passwords should NEVER be sent in plain text in an email.
Any update on this?
I'm afraid not.
I'm a new user of Piwigo and really happy about it (thanks!), but just had this issue as well and have to say I'm a bit shocked. In my opinion, this is a serious security issue that, independently of a possible implementation of an initialization link, should be fixed in the meantime by removing the lines
https://github.com/Piwigo/Piwigo/blob/master/include/functions_user.inc.php#L245
https://github.com/Piwigo/Piwigo/blob/master/install.php#L513
optionally adding a comment that the password can be obtained from the administrator.
If communicating the password over a different channel is considered too much of an effort, an administrator can always allow useres to register themselves, thereby also choosing their own passwords.
Just installed a server today - password sent in plain text. Wow, noped that right off my server. Removing those lines is fine @DavidMStraub however, your point about a serious security issue is right on the money. I would think If Piwigo can see the password, so can someone else. The Piwigo platform should not be able to see anyone's password to send it. Haven't gone through all the code to see, just wondering if anyone else has or not.
Piwigo does not store password in plain text.
When you log in, you send the username + password in plain text if you have an HTTP connection and not an HTTPS connection.
What I'm going to do right now is remove the password in the email sent by the installation form. This one is the most critical of course.
The email sent when an administrator creates a user is more complicated to remove, because Piwigo needs to handle it correctly. The solution proposed by @habakuk007 (sending a link to set the password) is nice and gives me the following idea:
needs_password_resetand as long as it istrue, Piwigo asks to set the passwordLooks better, right?

This is much better - e-mail is not secure and passwords have no place in them. Thanks for addressing this!
Sending passwords in plain text is not an issue, if they are "one time passwords" that needs to be changed immediately upon login.
We have addressed this issue globally at my employers (car manufacturing, so large, 300K employees, not Nissan) and the policy we set for that was discussed and agreed upon. Initial or OneTime passwords sent in e-mail, with a requirement to change them immediately, combined with the inability to see passwords anywhere - database or system files or whatnot - was accepted.
Admittedly we never addressed system owners or administrators passwords as mentioned initially in this scope, since they have huge responsibilities to handle this timely and efficiently.
In regards to Piwigo, how likely is it that you as admin request a password, get it in 30 seconds and during that time some hacker targets your site and effectively make an effort to intercept your mail?
I would rather direct the efforts towards two-factor authentication.
I stand corrected, if passwords are setup that way as described above then it’s fine to send via email. However there was no forced password expiry, although a bandaid, plegall came up with an alternative. I would vote for two-factor as well.
The system you are describing is out dated. More safe is to send the user an email with a link to set a password. But in Piwigo's case the user registers and sees the password he chose in the registration confirmation mail.
Yeah, well you are right in so much that the system could be better and a password link as you describe is of course an even better solution. I never said I had the "best" solution...
Are there any updates on that? Passwords are sent in plain text to users when they register and this needs to be disabled.
Yes, we've been re-discussing this subject a few week ago. We have 2 problems:
Years after years, it's becoming harder and harder to successfully send emails (which would reach the recipient inbox, I mean). So I don't really like the idea to "send a short-period validity invite link by email". I would feel more confident in the ability to copy a "set my password" link from the administration, for a given user.
We need to think about the right UX to provide this link, but I would prefer to let the administrator decides how she sends the link to the user. It could be by text message, company internal chat, email...
Starting with version 15.0.0beta1, Piwigo will send an email with a link to set the password. Piwigo will also provide a way to copy this link, in case Piwigo would not be able to correctly send the email (email is so complex to make reliable...)