We have a Wordpress site which we are going to gradually rebuild using the cakePHP framework. We will replace different parts of the Wordpress site incrementally, so we need to implement some sort of single sign on to allow authorization across both frameworks during the time while both frameworks are running side by side.
We have a pretty good strategy for how to do this. In short, we will duplicate all user rows in two different tables: one table for Wordpress (wp_users) and a different table for Cake (users). [More details outlined here (in case you're interested).]
This means when we create a user in Wordpress or Cake, we create the same user in the other table as well. This is "mostly harmless"...
We are struggling with the different password hashing strategies between Wordpress and Cake. In order to save the same user password in both tables, we need to figure out how to hash it so that each respective framework can check it.
Wordpress uses a pretty advanced hashing algorithm: PHPass. Cake (by default) seems to offer a choice of more traditional algorithms: SHA1, md5, blowfish... with optional salting.We're stuck on the fact that Wordpress generates/emails a default password to new users and then immediately saves a hashed version in the DB. This hashed version of the password is pretty useless to cake, unless we can figure out how to replicate all of the Wordpress authorization protocols (which seems somewhat daunting for new Cake users).
Is there an elegant solution to this problem?
I would suggest to keep user management centralised in either Wordpress or CakePHP until the migration to CakePHP is completed.
As of CakePHP 2.3, bcrypt/blowfish is officially supported for hashing passwords;
http://book.cakephp.org/2.0/en/core-libraries/components/authentication.html#using-bcrypt-for-passwords
However, if you already have your Single-Sign on working, why not leave the password syncing for the time being? Once migration to CakePHP is complete, consider the following options;
Send an email to all users containing a unique link to reset their password; resetting the password will actually create a hashed password in CakePHP and enable the new account. The unique links should be invalidated after that (also make sure that the link will expire after a certain period anyway)
Because both CakePHP and PHPass use bcrypt/blowfish, you may be able to copy the hashed passwords to CakePHP when migration is completed. However, you will need to determin 'how' PHPass passwords and salts are stored (separate fields? single field with a delimiter?). You may have to write your own Authorize Object that will pick the right 'salt' from the database
Related
For one of my webapps I'm using ASP.NET MVC 5. For sometime I used default password hashing algorithm. I would like now to switch to custom hasher.
But the question is: What happens to exising data? How do I update hashes for exising users?
You cannot update hashes for existing users.
The only option really is to add a column to the database table indicating the hash method, and write code to support both the old and new hashing methods contingent on the value found in that column.
If you like, you can update each user's hash as they sign on individually (since that is the only time the site has the cleartext password available). But there is no way to update the hashes on a batch basis whilst offline.
Drupal site migrated into PHP Framework,
In new database and current drupal contents are migrated,
Show stopper ? is login authentication.
what methodology / encryption method drupal has used for username and password authentication and validation.
Drupal code is open source and, in the case of user authentication, quite easy to understand. One only have to look at the source (Clive already provided the link on the comment to the OP).
With Drupal core, user authentication is password based. User authentication is done in the user_authenticate() function. Actual password verification is done in the user_check_password() function. As one can see, this actually compare hashed passwords (the stored one, and the one provided as clear-text to the function). Password hashes are computed using the _password_crypt() function, using salt and repeated hashing to increase security.
If you need to re-use Drupal user authentication outside of Drupal but keeping the password unchanged, you will need to replicate the user_check_password() function and all it dependencies.
My client gave me a bunch of databases with wordpress generated passwords. Now he wants me to make a login system, but not with wordpress (I must use those wp-generated passwords). Is there a way to make use of those passwords?
Thanks!
IF you know what algorythm was used to encrypt passwords in your Wordpress database, you can easily write your own function for comparing passwords for your login system using the same HASH.
Here is some more info on WP_HASH: http://codex.wordpress.org/Function_Reference/wp_hash_password
EDIT: Very good article about Wordpress Password Hashes: http://resources.infosecinstitute.com/wordpress-password-hashes/
I need to synchronize three of them but I have already 18k Asp.Net Members. (Offline synchronization)
So how can I convert default "Password Hashing" of Wordpress and Drupal to Asp.Net Membership's (SHA1 with Salt) ?
I don't know if you can. MD5 and SHA1 are uni-directional algorithms. This is why they are used. They provide security for the user passwords. So you will not be able to revert the hash back to the passwords. Nor can you convert from MD5 to SHA1 directly.
In this scenario I think you are stuck with resetting the Drupal and Wordpress user passwords when you merge. (See edits for alternate solution.)
EDIT: This post had a interesting idea / solution. Write some custom code to generate the SHA1 passwords upon your users first logging in. Collect the SHA1 hashes, and use those during merge. Any users you don't get, force them to do a password reset.
I'm migrating an application from ColdFusion to ASP.Net MVC and have a little problem I cannot seem to get my head around. The original application stores user's passwords in a MD5 hash format with no salt in the database. I'm using the ASP.Net membership store and would like to allow for as seamless a transition for the existing users as possible. Here's the possibilities I was thinking of...
1) Since I cannot decrypt the values of their current passwords, I was thinking of storing this old password in a table, checking against it on login... if it's not empty and their password matches, I prompt them to update their password, which would then set the password properly in the asp.net membership table and wipe out their old password, never to be checked again.
2) Users login with their email, not their screen name, so I was thinking of resetting everyone's password to their screen name and forcing them to change it after first login. The only problem is that I'm not sure I can update their password via SQL without the current password. Executing the aspnet_Membership_SetPassword proc doesn't appear to encrypt the password in its own.
What you say?
I've used a variant of #1 in a live application. It worked great, users never noticed the change as far as I was aware.
A couple of refinements:
You don't need to prompt them to update their password; they provided you the cleartext to log in (and you know it's the correct cleartext since it hashed correctly), so just go ahead and set that as their password.
Make sure you clear the legacy password hash if they use the password reset functionality.
I would under no circumstances use option 2; it's wildly insecure.
One other thing -- it is possible to set a password without knowing their current one, it just requires two steps.
Reset the user's password. You now know the reset password.
Use the newly reset password to set the password to a known value.
I had a similar situation recently- An old application of mine used a salted MD5 and I very much wanted to upgrade without affecting my users. What I ended up doing was wrapping the original hash in a better hash and then re-salting it to mitigate the loss of resolution.
For example my initial hash was MD5(pass + salt)
I upgraded everything to SHA256(MD5(pass+salt) +salt) - that way my app is secure and I never needed to find out the original passwords or reset anything.
Once your new authentication process is in place simply run an update script over all existing users in the DB. It is a little bit of a pain but is essentially seamless for you users.
--
Bah- I apologize, this isn't really tailored to ASP.net membership as I'm using a custom auth class on my application. I still think it is one of the more sound methods for performing the upgrade, but i'm not sure of the ASP.net membership specifics.
Option 2 is a pretty big security risk. If anyone knows the email of a screen name can log hijack that account before the rightful owner logs in. Knowing or guessing the email of most popular site users (ie. most tempting ones to hijack) may be more prevalent than you think.