Can I enforce secure admin passwords?
I am concerned that list owners can put insecure admin passwords on their lists. My testing suggests that short passwords are accepted as well as alpha-only. The only control I have found is the length of admin passwords generated by Mailman. I have not located anything else that would enforce even minimal password security.
Am I missing something here?
Kirke Johnson Internet: kjohnson@pcc.edu Email Administrator, TSS , Sylvania Campus http://www.pcc.edu/ Portland Community College, Portland, OR, USA (503) 977-4368
Kirke Johnson writes:
No, except that there are other security issues with all Mailman passwords. Specifically, that these transactions are conducted over unencrypted channels anyway. I think the passwords are also stored in clear on the server (those of the list members are, since they appear in monthly reminders) but I could be wrong about that.
It would be easy to add checks, I suppose, but you'd have to decide what checks you want. I don't think it would be much more difficult to add the concept of a user-supplied checker. Dealing with the link and storage security issues would be more complex. You'll have to wait for Mark to speak up to find out if there are any plans in 2.2.
For Mailman 3, I suspect this is all still pretty much up in the air. Check the wiki and maybe post a feature request to Mailman-Developers.
I suggest posting a feature request to the tracker in any case so the suggestion won't get lost.
Stephen J. Turnbull wrote:
In Mailman 2.x, user passwords are stored in the clear, but list admin and moderator and site passwords are stored encrypted. In Mailman 3, all passwords will be stored as encrypted values and reminders will go away. There will be an on demand reset mechanism for user passwords.
There is no plan to change the way passwords are stored for Mailman 2.2. It is not difficult to secure communications, i.e. to make Mailman generated URLs be https and to redirect http to https in the web server.
Adding a hook to a user supplied password checker could be done in 2.2. I'll take a look at this idea. How about a default checker that just checks for minimum length defined in Defaults.py/mm_cfg.py, but overridable by the site. or maybe an mm_cfg.CheckPassword() function defined in Defaults.py as
def CheckPassword(pwd): if len(pwd) > 0: return True else: return False
Then the site can redefine this in mm_cfg.py to do anything they want.
I think this should probably apply only to list and site passwords in MM 2.2.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro writes:
It occurs to me that this API is going to make it hard to provide help to users. Maybe CheckPassword's API should be to raise an InvalidPasswordError with an appropriate reason, or alternatively to return a false value if nothing is wrong with the password, otherwise return a list of reasons it is invalid (ie, return 'reasons' in the example below).
So I'd like to be able to do
import re letter_re = re.compile("[a-zA-Z]") digit_re = re.compile("[0-9]")
minimum_admin_password_length = 8
def MyCheckPassword(pwd):
# require passwords to contain letters and digits
reasons = []
if not re.search(letter_re,pwd):
reasons.append("your password did not contain a letter")
if not re.search(digit_re,pwd):
reasons.append("your password did not contain a digit")
if len(pwd) < minimum_admin_password_length:
reasons.append("your password was not at least %d characters long" %
(minimum_admin_password_length,))
if reasons:
raise InvalidPasswordError(reasons)
CheckPassword = MyCheckPassword
I think this should probably apply only to list and site passwords in MM 2.2.
Agreed.
We took care of the clear text transmissions, I believe. One of the first things we did with Mailman was to make sure all web activity uses https. Similarly, we use SSL for email server authentication and mail transfer security.
What is bothering me is list owners who want to use their initials or the list name as list owner passwords. I feel like kind of a sitting duck when we can't see the passwords they have chosen and have no way to enforce decent choices.
Thanks for your interest and thoughts as to how Mailman might be enhanced in this area!
At 06:48 PM 6/2/2009, you wrote:
Kirke Johnson Internet: kjohnson@pcc.edu Email Administrator, TSS , Sylvania Campus http://www.pcc.edu/ Portland Community College, Portland, OR, USA (503) 977-4368
Grant Taylor wrote:
What known values? List name, yes, but the list owner's name, initials, whatever are not known to Mailman - only her email address.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Jun 3, 2009, at 4:33 PM, Kirke Johnson wrote:
This isn't a mailman problem as you well know. And I don't think that
the solution is to have mailman test for weak passwords.
The real, long term solution is to encourage people to use good
password management systems. The best password management system I've
seen is sadly OS X only: 1Password. But there are also the password
management systems built into web browsers, which are better than
nothing.
-j
-- Jeffrey Goldberg http://www.goldmark.org/jeff/
Kirke Johnson writes:
No, except that there are other security issues with all Mailman passwords. Specifically, that these transactions are conducted over unencrypted channels anyway. I think the passwords are also stored in clear on the server (those of the list members are, since they appear in monthly reminders) but I could be wrong about that.
It would be easy to add checks, I suppose, but you'd have to decide what checks you want. I don't think it would be much more difficult to add the concept of a user-supplied checker. Dealing with the link and storage security issues would be more complex. You'll have to wait for Mark to speak up to find out if there are any plans in 2.2.
For Mailman 3, I suspect this is all still pretty much up in the air. Check the wiki and maybe post a feature request to Mailman-Developers.
I suggest posting a feature request to the tracker in any case so the suggestion won't get lost.
Stephen J. Turnbull wrote:
In Mailman 2.x, user passwords are stored in the clear, but list admin and moderator and site passwords are stored encrypted. In Mailman 3, all passwords will be stored as encrypted values and reminders will go away. There will be an on demand reset mechanism for user passwords.
There is no plan to change the way passwords are stored for Mailman 2.2. It is not difficult to secure communications, i.e. to make Mailman generated URLs be https and to redirect http to https in the web server.
Adding a hook to a user supplied password checker could be done in 2.2. I'll take a look at this idea. How about a default checker that just checks for minimum length defined in Defaults.py/mm_cfg.py, but overridable by the site. or maybe an mm_cfg.CheckPassword() function defined in Defaults.py as
def CheckPassword(pwd): if len(pwd) > 0: return True else: return False
Then the site can redefine this in mm_cfg.py to do anything they want.
I think this should probably apply only to list and site passwords in MM 2.2.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro writes:
It occurs to me that this API is going to make it hard to provide help to users. Maybe CheckPassword's API should be to raise an InvalidPasswordError with an appropriate reason, or alternatively to return a false value if nothing is wrong with the password, otherwise return a list of reasons it is invalid (ie, return 'reasons' in the example below).
So I'd like to be able to do
import re letter_re = re.compile("[a-zA-Z]") digit_re = re.compile("[0-9]")
minimum_admin_password_length = 8
def MyCheckPassword(pwd):
# require passwords to contain letters and digits
reasons = []
if not re.search(letter_re,pwd):
reasons.append("your password did not contain a letter")
if not re.search(digit_re,pwd):
reasons.append("your password did not contain a digit")
if len(pwd) < minimum_admin_password_length:
reasons.append("your password was not at least %d characters long" %
(minimum_admin_password_length,))
if reasons:
raise InvalidPasswordError(reasons)
CheckPassword = MyCheckPassword
I think this should probably apply only to list and site passwords in MM 2.2.
Agreed.
We took care of the clear text transmissions, I believe. One of the first things we did with Mailman was to make sure all web activity uses https. Similarly, we use SSL for email server authentication and mail transfer security.
What is bothering me is list owners who want to use their initials or the list name as list owner passwords. I feel like kind of a sitting duck when we can't see the passwords they have chosen and have no way to enforce decent choices.
Thanks for your interest and thoughts as to how Mailman might be enhanced in this area!
At 06:48 PM 6/2/2009, you wrote:
Kirke Johnson Internet: kjohnson@pcc.edu Email Administrator, TSS , Sylvania Campus http://www.pcc.edu/ Portland Community College, Portland, OR, USA (503) 977-4368
Grant Taylor wrote:
What known values? List name, yes, but the list owner's name, initials, whatever are not known to Mailman - only her email address.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Jun 3, 2009, at 4:33 PM, Kirke Johnson wrote:
This isn't a mailman problem as you well know. And I don't think that
the solution is to have mailman test for weak passwords.
The real, long term solution is to encourage people to use good
password management systems. The best password management system I've
seen is sadly OS X only: 1Password. But there are also the password
management systems built into web browsers, which are better than
nothing.
-j
-- Jeffrey Goldberg http://www.goldmark.org/jeff/
participants (5)
-
Grant Taylor -
Jeffrey Goldberg -
Kirke Johnson -
Mark Sapiro -
Stephen J. Turnbull