On Jan 10, 2015, at 01:57 PM, Stephen J. Turnbull wrote:
In the long run we need to do something about this. However, Mailman has operated based on passing around *cleartext* passwords by *email* for decades, with no serious issues that I know of.
Just to be, ahem, clear, by default MM3 does not store cleartext passwords.
It uses passlib to hash the passwords set via the REST API and only stores those hashed passwords internally. From src/mailman/config/passlib.cfg:
[passlib] # This is the output of passlibs.apps.custom_app_context.to_string(). # See http://packages.python.org/passlib/index.html for details. schemes = sha512_crypt, sha256_crypt default = sha512_crypt all__vary_rounds = 0.1 sha256_crypt__min_rounds = 80000 sha512_crypt__min_rounds = 60000 admin__sha256_crypt__min_rounds = 160000 admin__sha512_crypt__min_rounds = 120000
It's possible to configure passlib to use an 'identity' hash which would leave passwords in the clear, but you'd have to go out of your way to do so.
The key 'cleartext_password' is only used with PUT/PATCH on the user resource. The idea being that the client doesn't hash the password, but instead passes it in cleartext to core over REST. The core then hashes it and stores it on the user record.
The JSON representation of the user resource has a 'password' key which contains the hashed password. So when you GET a user, you get it hashed, i.e. exactly what's stored on the user record.
User resources have a 'login' subresource which you can POST to to verify a password. This also takes a cleartext_password, presumably as you'd receive from a login form.
Cheers, -Barry