Password Hash

What form of hashing will Rev be using for the passwords? From what I read, plain MD5 Hash is terrible as it’s easily hacked, without the knowledge to back that up could someone tell me which form Rev will be using.

I would assume it uses some variant of SHA.

Really this is a very minor security concern IMWO. In order to take advantage of any security vulnerabilities in the password hash the attacker would have already had to hack your server and get access to your database. By the time that happens password hashing is the least of your concerns.

I actually forgot to mention that many other applications don’t use MD5 now and use SHA so wondered how this would effect integration with these apps...

What about upgrading from prior MODx versions? That is a reason to keep using MD5 passwords.

From what I read even sha1 can be broken. You would also need a salt, but since the salt is stored on the server/db the hacker will have access to it.
You can only make it harder for the hacker.

What I would like to know is how do different applications that use different hashing for passwords manage to be properly integrated? I’m asking as I do not have any knowledge of how this works but from my experience working with different hashing has made it hard for me to integrate things easily. Example, I recently tried to integrate SMF with MODx but since it’s 2 different hashing, I can’t simply copy encrypted passwords between the 2 databases. If the 2 systems used the same encryption I would of been able to copy the user passwords over, correct me if I’m wrong on that but that was what my intention was to do. Still learning so Just wondering what Rev will be using and how it will affect integration with other apps that would require a shared user database.

Usually you can bypass one application’s password storage altogether. They use a SESSION to maintain a user’s login status, so it’s easier to hijack one of the SESSION arrays to make the application think the user is logged in.

The logging application would have to be modified to have the required SESSION values that the other application requires, and the second application would need to start the same session that the logging application uses.

From the comment above the encode function in xpdoobject class :-

* NOTE: This implementation currently only implements md5. To implement additional
* algorithms, override this function in your xPDOObject derivative classes.

So you can override this and implement what you wish, the overridden function can support as many algorithms as you wish, selectable by the $type parameter.

And if you need more than one? Perhaps integration with a forum and an ecommerce application?

Would the idea of using SESSIONS be similar to this?

A user would sign in to modx using their registered username and password with modx, on authentication a new SESSION is created; perhaps a plugin in modx would activate the SESSION onweblogin. In the 2nd application you would modify it to look for this new SESSION and if it is found, validate it against a username in that applications database, if it’s found they are signed in? So there would be no reason to check the password against the modx password as the SESSION was created via modx and then validates against the 2nd application user database?

I have been using COOKIES for a similar technique, would simply changing the COOKIE to a SESSION be the same thing?