I know this has been asked before, but I haven't found anything about whether or not this will be a future change or how to work around it.
The passwords in Mailman, are stored unencrypted. The web connection can be encrypted by SSL to avoid man in the middle, but passwords are sent in clear text in password reminders.
Is there any plans of a future change so passwords will be stored encrypted, and some kind of one-time link to change the password, instead of sending reminders, or some kind of challenge will be implemented, to avoid revealing the password to third party?
Otherwise I will request such a change.
Henrik Rasmussen
On 07/02/2014 03:58 AM, Henrik Rasmussen wrote:
I know this has been asked before, but I haven't found anything about whether or not this will be a future change or how to work around it.
Mailman 3 does not store unencrypted passwords.
There are no plans for changing the way passwords are handled in Mailman 2.1.
You can always remove cron/mailpasswds from Mailman's crontab to avoid sending monthly reminders all together regardless of list or user settings. Users will still be able to request a reminder from the options login page.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
I have a script that disables password reminders on lists. So if you have a bunch of lists that may or may not have reminders set you can run this to disable them all and notify the list owners you did so.
https://github.com/jwhite530/Random/blob/master/Mailman/disable_password_rem...
Jeff White - GNU+Linux Systems Administrator University of Pittsburgh - CSSD
On 07/02/2014 09:28 AM, Mark Sapiro wrote:
Mark Sapiro writes:
On 07/02/2014 03:58 AM, Henrik Rasmussen wrote:
A more complicated option is to use MemberAdapter and handle authentication entirely yourself.
IMHO, for anybody who has done the work ensuring the security of the accompanying system (TLS/SASL for all communications, encrypted hard drives for all stored traffic including users' archives, etc), MemberAdapter will be a snap. :-)
Of course in security every little bit matters, and the design decision in Mailman 3 to never store unencrypted (or decryptable, for that matter) passwords was the correct one. But given how leaky the mail system is by default, I think the incremental benefit to the vast majority of our users to trying to plug this hole ex post design of Mailman 2 is too small to justify the effort.
On 07/02/2014 03:58 AM, Henrik Rasmussen wrote:
I know this has been asked before, but I haven't found anything about whether or not this will be a future change or how to work around it.
Mailman 3 does not store unencrypted passwords.
There are no plans for changing the way passwords are handled in Mailman 2.1.
You can always remove cron/mailpasswds from Mailman's crontab to avoid sending monthly reminders all together regardless of list or user settings. Users will still be able to request a reminder from the options login page.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
I have a script that disables password reminders on lists. So if you have a bunch of lists that may or may not have reminders set you can run this to disable them all and notify the list owners you did so.
https://github.com/jwhite530/Random/blob/master/Mailman/disable_password_rem...
Jeff White - GNU+Linux Systems Administrator University of Pittsburgh - CSSD
On 07/02/2014 09:28 AM, Mark Sapiro wrote:
Mark Sapiro writes:
On 07/02/2014 03:58 AM, Henrik Rasmussen wrote:
A more complicated option is to use MemberAdapter and handle authentication entirely yourself.
IMHO, for anybody who has done the work ensuring the security of the accompanying system (TLS/SASL for all communications, encrypted hard drives for all stored traffic including users' archives, etc), MemberAdapter will be a snap. :-)
Of course in security every little bit matters, and the design decision in Mailman 3 to never store unencrypted (or decryptable, for that matter) passwords was the correct one. But given how leaky the mail system is by default, I think the incremental benefit to the vast majority of our users to trying to plug this hole ex post design of Mailman 2 is too small to justify the effort.
participants (4)
-
Henrik Rasmussen -
Jeff White -
Mark Sapiro -
Stephen J. Turnbull