I have been bouncing around the SilverStripe database for a few hours, and one of the things that has immediately jumped out at me is that member passwords in the `Member` table are stored unencrypted.

Shouldn't there should be some sort of encryption, at least md5, and perhaps a dash of salt as well. Many (most?) people recycle at least some of their passwords for various services; I am not sure of other people's general opinion on passwords, but I for one would be more comfortable in knowing that my password is not sitting in a database somewhere in clear view of anyone with access to it.

Is there any reason why the passwords are stored in clear text that I am not aware of? And wouldn't a change to encrypted passwords be a fairly trivial task? (I have not yet delved deep enough into the SilverStripe database queries to see how many references to that table would need to be ammended to make such a change).

Thoughts?

With SilverStripe 2.0, we used years of previous experience to improve the product. This is both in terms of things we've learnt as programmers, and also while doing our day to day customer support. One of the decisions we made was that the benefit of being able to resend people's existing passwords seemed to outweigh the issue of trusted administrators taking advantage of their knowledge and power. (SilverStripe v1.0 does encrypt passwords, and this is how we learnt of how "less technical people" go around in circles resetting passwords, wasting a lot of their own and customer support time).

That said, we value your opinion greatly, and by do treat security with importance.

SilverStripe is a) designed to be easily modified and extended, and b) is a community based product, so if you would like see strong password protection then we could happily make it an optional configuration item in the system.

Either have a go yourself (and we can include the patch with an upcoming release; we will happily show you files to modify or given general assistance) or request it at http://www.silverstripe.com/feature-requests/

Looking up the passwords is done in Security::authenticate(). This would be trivial to modify. However, there will be other bits of code in the 'reset password' and 'set password' systems - these would need to be put into the Member class so that existing customisations didn't break.

I think that in v2.1, we'll have a method along the lines of Security::set_pwd_encryption(), that can be passed a MySQL method such as "password" or "md5", as well as the default of "", meaning no encryption.

This might be a good opportunity to look at abstracting the authentication system a bit, so that (for example) an LDAP authenticator or an authenticator built around another database (such as a 3rd party forum) could be integrated with the system.

Sigurd, I can appreciate from a support point of view that it is a lot easier to resend users' passwords, but I would argue it is just as easy to reset their password instead (perhaps to a random 8 character string) and allow them to change it to something else upon logging in again (this is the procedure I currently use on current websites I maintain with large user bases). This is especially important if the new (or existing) password is going to be sent to them via email; who knows how many computers that unencrypted email bounces through before it lands in the user's inbox.

My main concern is not "trusted administrators taking advantage of their knowledge and power" but rather, if there is ever an SQL injection exploit found in SilverStripe, an attacker could harvest the passwords of every single user. I realise that an SQL injection exploit would mean that an attacker could insert their own MD5 string into the database fields anyhow, but I am not so much talking about the security of the CMS here or the site itself being compromised, but rather the security of users' passwords which in some cases could be the same password they use for their email, home computer, and god forbid, internet banking.

Sam, I think your suggestion of a switchable password db storage class is a great idea. Choice is always a good thing, and giving a site administrator the ability to encrypt passwords in the database would be a solution that would satisfy those on both sides of the fence.

I will take a look at creating a patch myself (once I fully familiarise myself with the SilverStripe code) although if it is planned for v2.1, then there is no need for me to reinvent the wheel.

Any assistance you can provide with patching the system to support this would be much appreciated! :-)