How can I prevent Seafile from sending passwords in email?

463 views
Skip to first unread message

Sean Madsen

unread,
Dec 30, 2014, 11:40:48 AM12/30/14
to sea...@googlegroups.com
I am setting up a new Seafile server to use with many people. I have enabled email delivery, and I am happy to see that users can reset their password through the web interface by clicking on "forgot password". The email message that Seafile sends is good because it contains a URL and does not contain a password.

I'm unhappy to find that when I create a new user or when I manually reset a user's password from the web interface, then Seafile sends the user an email message containing the new password, in cleartext. I see this behavior as a security risk and would like to re-configure my server to mitigate this risk.

How can I prevent Seafile from sending these emails containing cleartext passwords, while retaining the functionality of Seafile being able to send password reset URLs over email?

Thanks,

--
Sean

JiaQiang Xu

unread,
Dec 30, 2014, 9:33:18 PM12/30/14
to sea...@googlegroups.com
Hi,

If the admin wants to set a new password for a user, how do you think is better to tell the user the new password, without sending it?

Sean Madsen

unread,
Dec 30, 2014, 10:50:07 PM12/30/14
to sea...@googlegroups.com
If I'm doing my job correctly as an administrator and I need to reset someone else's password, I should never even be in the position where I need to communicate that password to them. Users who forget their password can use the "forget password" functionality which already works well in Seafile. The most often use-case in my experience where I would need to reset a user's password is when I need to log in as that user myself to troubleshoot issues or transfer documents after a staff transition. Other use cases would be when the user is physically present and I can have them type their own password into my computer, say if I'm helping set up Seafile for them and guiding them through the process of using it, in-person.

As an administrator, it is my responsibility to never see anyone's personal password. Not even temporary passwords, because many users won't change them unless forced to. This is good security practice. People's passwords are their personal property. Especially since many people re-use passwords (unfortunately), our technologies should help to facilitate password privacy.

So if when I reset a user's password in Seafile, or when I create a new user and specify a password, Seafile should not send any notification that includes the password in email. If for some strange reason I do need to communicate this password to the user, then I can choose a secure method of doing so (e.g. in-person or through encrypted email). Not cleartext email -- it's like writing it on a postcard!

It has honestly been years since I've interacted with a web application that sends passwords in cleartext. This practice was common a decade ago, but people have been catching on. It's big a security risk. None of the other web applications I use do it.

I've worked around this issue in Seafile by disabling outbound email while creating new users. For each user I create, I set a strong random password (which I immediately discard). Then I inform users to go to the site and click the "forgot password" link. This works fine, but I wish I didn't have to disable and re-enable email delivery.

Ken Barbson

unread,
Jan 1, 2015, 3:36:08 AM1/1/15
to sea...@googlegroups.com
I agree with Sean and have had similar concerns. I hope an appropriate solution will be found for this.

JiaQiang Xu

unread,
Jan 2, 2015, 10:15:50 PM1/2/15
to sea...@googlegroups.com
Sean,

Thanks for your feedback.
For the requirement that the admin needs to access the content of a user's library, it's simpler to allow the admin to access all the libraries in the server. There is no need to reset password for doing so. This is a feature that will be added in the future.

Florian Kerle

unread,
Jan 8, 2015, 4:14:04 PM1/8/15
to sea...@googlegroups.com
Good to hear!

Ofc, you won't allow that for encrypted libraries?

But still, if creating a new user, don't set a password at all! Just send a similar email, as if hed lost his password (the user needs to enter his first password himself)
Still, you can keep the option to explicitly set a users password.
Reply all
Reply to author
Forward
0 new messages