something a little more secure for passwords

I am thinking of writing a patch for ModX to change the way it encrypts passwords.

I don’t give two hoots about security if I am honest, just that I would like to have a basis to integrate with SMF, but not using the bridge, because that only synchronises web users.

I want managers in SMF to be Managers in ModX, or at least have the same username/passwords for each....

The way I was thinking of doing this was having either mirrored password tables or a single table and creating SQL views for both SMF and ModX. Either way it would require me to change the way ModX encrypts passwords for managers - which got me thinking, it might be something that I can feedback into the community, and perhaps even get the core code running more secure encryption, because some people do care about security.

If you are unfamiliar with the way SMF encrypts passwords, it uses sha1 on the password, using the username and a salt as the hash.

Has anyone successfully altered the way encryption works, or are wanting to contribute ideas etc?

You should be able to accomplish this simply by writing a plugin that replaces MODx authentication (via OnManagerAuthentication and related events) with code which uses either an SMF API or similar to check credentials, maybe sync profile info from SMF along with groups and group permissions.

In the near future (0.9.7+), you will be able to provide a custom session handler class, as well as custom classes for users, their profiles, and their group memberships (which will no longer be separated into web and manager users, BTW), as an alternative method to customizing the user management in MODx.

For 1.0, I also have plans to allow configurations of chained plugins for aggregating user repositories in MODx, so you could quickly "mash-up" credentials from LDAP, SMF, and an OpenID provider, then supplement those with user profiles and group memberships from SMF. This prevents the need for two-way synchronization with the source, and allows MODx to manage only what it needs to of the user data locally. MODx could also serve as an "identity" provider then to other custom applications via various protocols, starting with API, but could quickly be extended to service SAML, OpenID, or other requests...

But for now, I’d try the plugin approach and if you are interested in collaborating on the next generation user management solutions for MODx, drop me a PM, or feel free to continue this dialog.

Quote from: OpenGeek at Jun 17, 2007, 10:56 PM

You should be able to accomplish this simply by writing a plugin that replaces MODx authentication (via OnManagerAuthentication and related events) with code which uses either an SMF API or similar to check credentials, maybe sync profile info from SMF along with groups and group permissions.

The SMF API isn’t as flexable as one might have hoped. From what I can tell it can only say if the login failed or not... but ModX will want to know the username - which is why something clever with the tables is what I had in mind. I am going to sit down with a felt tip and do some old fashioned dry running with the APIs etc. to see if I can get something working.

I will report on my findings here.

As far as the helping with the new login is concerned I really don’t know what I could contribute over other people that are probably far more PHP savvy than myself... but I would be happy to provide any insight, advice etc.