Though we would have to decrypt the password after retrieving them, it would be sensible to at least use some 2-way cryptography there. Having passwords saved as plain text really worries me.
They could be encrypted the same way the errors are encripted. That would be a function of SECRET_KEY.
Not sure if this is that useful tho ... a better approach would be a way to load those passwords from elsewhere, like a well protected file.
Could be, yes. The thing is, anything that didn't keep the passwords as plain text would be at least a bit more secure. Suppose an attacker attacks the database system only, but not the application server: today he would have access to the Redis password, but if we encrypted it, it wouldn't be easily broken.
Shouldn't be that hard to do something like this: https://github.com/ionelmc/django-monkey-team/blob/master/src/monkey_team/middleware.py#L25 and https://github.com/ionelmc/django-monkey-team/blob/master/src/monkey_team/views.py#L41
But it should be off by default - not everyone wants dependency on pycrypto. And if we do that then we need to prefix the passwords with the algo name (eg: plaintext and aes) just like the django's auth so you can change the default password "encoding" without losing all the previous passwords.
Sounds good for me. :-)
Now the thing is, because this doesn't actually improve security enough (if an attacker can compromise the database where these settings are stored then he can just poison the django sessions with executable code) this is very low priority for me ...