View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 414 | Composr | core_cns | public | 2012-03-25 17:22 | 2014-10-08 23:11 |
| Reporter | Chris Graham | Assigned To | Chris Graham | ||
| Priority | normal | Severity | feature | ||
| Status | resolved | Resolution | fixed | ||
| Summary | 414: Switch from md5 to SHA-512 hashing | ||||
| Description | Update Composr password storage. Currently if someone gets the hash+salt via some other security hole (either on server, or from getting cookie hashes), they can use a server farm (e.g. Amazon instances, or some government farm) to generate rainbow tables for the salt used, and eventually get a password back. It's expensive, but within the means of larger organisations. This is made possible because techniques have been found to make md5 collisions easier than originally thought, but also because rainbow tables have become easier to produce due to increased computer power. The solution is to move to using the PHP 'crypt' function instead of the 'md5' function, which is stronger, and harder to compute rainbow tables for due to it's execution time. Using crypt allows complexity to be ramped up via configuration adjustments, by storing crypt-style salts that encode hash options in them; crypt allows configurable algorithmic [computational] complexity. We can therefore improve future password generation in Composr as hardware improves, without slowing down current hardware by being too strong off the bat. We should start with SHA-512 with some appropriate 'rounds' number; SHA-512 which is well supported in more modern versions of PHP. The following files would need to use a new password API, for checking/generating password hashes: - cns_members_action2.php - cns_members_action.php - lostpassword.php - ejabberd_auth.php - cns.php - passwd.php - password_rules.php The API would use the same flexible password mechanisms Composr currently uses, but with support for the new 'crypt' method. 'crypt' is supported in PHP5.3+, effectively. So we would need to raise our minimum requirements. Older versions of PHP have the function, but rely on operating system availability which is no good for site portability because existing hashes could stop working if a new server does not support what an old server did. (NB: A lot of systems moved to sha1 years ago instead of md5, but this is as bad as md5, and not available in our current system requirements -- so we're fortunate to have skipped a pointless change cycle and now be targeting the next generation mechanism in PHP) (NB: It is important to point out that md5 is not inherently insecure per-se, it is only insecure if you find a way to grab a user's hash, which should not be possible anyway, and then you need to spend serious resources reversing the hash to a password) --- As well as using this system for member passwords, we should do it for the site master password also. | ||||
| Tags | Risk: Database change | ||||
| Attach Tags | |||||
| Time estimation (hours) | 5 | ||||
| Sponsorship open | |||||
|
|
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). |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-06-08 00:15 | Chris Graham | Tag Renamed | Database change => Risk: Database change |
