I think if going to this trouble it might be worth adding a mechanism to force password changes periodically based on groups and one that ensures a user cannot re-use an old password. I did a system like this for one CMS where I stored an Algorithm used alond with salting method and and number of runs through the hasher into a table and stored it as a profile. Then When I changed a password I could store itr as an unacceptable password (for that user) by storing there old hashed pwd and the hashing profile with it. this way when I forced a change on them I would check all old stored passwords with old profiles for a match. If I found one I told them nope sorry must choose a different password. I found this very important because other sites using the CMS the admins were trapping users passwords then using them to log into my site. With a system like this I could avoid that type of breach.

Generally security experts recommend against forcing strict password rules. Personally I'm against it, I think it just makes people invent password naming schemes [append 1, then 2, then 3, etc], or end up writing down the always-changing passwords somewhere insecure. At the least, it really annoys users.

That said, I don't think I'd have an issue with it being in Composr as long as it was off by default.

I can see that point and I think in a general sense you are right but it is also why I mentioned it should be able to use on a "Per Group" basis because I myself would most likely only use it sparingly on those with elevated privileges (especially to any admin areas) because people tend to use the same password elsewhere if I don't force them a change once or twice they are very likely to have used the password at another site where it then becomes easy for that site owner to use it to get into my site. I wouldn't care so much with reg users but Admins I want to make sure I am secure. As I say I have had it happen and it is a very weak flaw when it does. Nothing to do with the software but the users themselves for not picking new passwords. But this situation for me lead them into many more places like emails and some server access (due to stored passwords in places that should have not been visible without admin access) so I kind of think it would be a great feature. One that no other CMS I know of has so it also a selling point of extra security when you need it. I have most of the code written for another CMS that could easily be adjusted to fit into Composr if you're interested at all. If not I may try making it fit for personal purposes then.

Feel free to commit, if you do do via a git branch though - that's how I've been working recently, it files it away neatly for merging at an opportune point (E.g. v10). Hopefully you do have access to do "git push origin <branchname>".

I agree.

We have a similar restriction that limits what IPs a user can login with - forcing confirmation of them via their email account, each time a new one comes up against their username.

Note that PHP has added functions for doing most of what is defined in this task. However, this is in PHP 5.5. It may be best to emulate this API and follow it, then remove the emulation layer further into the future.

We are going with what PHP5.5 supports, with PHP5.3+ compatibility code, and with fallback to our preexisting hashing scheme for even older versions.

We also have added password expiry rules and prevention of re-use, as options, since this discussion (was done for a corporate client with very stringent security rules).