REST API returning value of password field in user record
I’m aware that it’s not the actual cleartext password.
From a security perspective should even salted and hashed passwords should stay behind the API or might there be a need for something on the other side of the API to access that field?
thanks
On Jan 10, 2015, at 10:58 AM, Andrew Stuart wrote:
I’m aware that it’s not the actual cleartext password.
From a security perspective should even salted and hashed passwords should stay behind the API or might there be a need for something on the other side of the API to access that field?
Keeping in mind that the core's REST API is a privileged API, only to be exposed over localhost, it is intended to make the hashed password field available. For a public facing proxy, I would expect this field to be filtered out.
Cheers, -Barry
Andrew Stuart writes:
From a security perspective should even salted and hashed passwords should stay behind the API or might there be a need for something on the other side of the API to access that field?
At present the REST API is available only on localhost (at least by default), so it's not that big a risk (yes, I understand defense in depth, but there's a need of corresponding importance). In the absence of a proper authz/authn module inside of Mailman itself, I don't see a real alternative to making that data available to mailman.client, and thus making it possible for other user apps (HyperKitty, Postorius) to get authorization to access a specific user's data.
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.
If Barry is serious about World Domination, we need to fix this, but I don't see a huge hurry.
Steve
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
participants (3)
-
Andrew Stuart -
Barry Warsaw -
Stephen J. Turnbull