Password hashing
[quote] * Change these to different unique phrases!
* You can generate these using the {@link https://api.wordpress.org/secret-key/1.1/salt/ WordPress.org secret-key service}
* You can change these at any point in time to invalidate all existing cookies. This will force all users to have to log in again.
[/quote]And here are some i just generated:
define('AUTH_KEY', 'Xl2wc+1 +axlJFo$4| {#6NPQ>P~bqeeDGYeo7y2rE8Vy=|>FqlC!?;QB6e$IJok');
define('SECURE_AUTH_KEY', ':opi?(?dvLL+;K-(/8d$2-JeIW61o_Mv,EDU$Q0&!oO ~b@zcQjTNYNhlmg9;G_+');
define('LOGGED_IN_KEY', '?T$(hta| y-9}41Fvo719_GB0aQ5:Uo:Lm6AQ1erU|jSy7PLKYvn|PL.io>qC9HV');
define('NONCE_KEY', 'Vgo^HPxx?M2nhyhR?$cT{R_X!+a|R>eKaI{RIHgAjiMxQ~C};O&).A~I^4L{+qQ3');
define('AUTH_SALT', 'Uypz?l$XrMw*.-A j$1r>)FH0+7}|RKQ=8rHox21UBHtM-7&W[Buot@ghH@OAeTK');
define('SECURE_AUTH_SALT', 'V~jK%J;^lf-o2XH-YN+%$Rs qk(D@x<#.E=r-ur)jLD hSl9Gqy3r#,`aSbL|k>g');
define('LOGGED_IN_SALT', '~D[Hb|JqDJoQH8p]H.;W+?b#~BX`U!O!eZ_Ep33::zJpoZjIyU5Mb69u/8$ZG)^|');
define('NONCE_SALT', 'vJu/}MN.L* ntJ--sdpeZ||A7[f)<h@e7a*Y5L>8801$c5H%%{+M~MIO*}n5~yw+');
The real question is, "Why do you care? or... What problem are you trying to solve, where stored password hashes matter to you?"
ASKER
My ultimate goal is to merge users from an old instance into a new one, so i might need to explorer the implications of that.
But this is confusing: i would have thought that the procedure when logging in would be that the salt would be applied to the POSTed password, hashed and compared to the value in the db in order to authenticate. Now that can't be, as login would fail if the salt changed ...
But this is confusing: i would have thought that the procedure when logging in would be that the salt would be applied to the POSTed password, hashed and compared to the value in the db in order to authenticate. Now that can't be, as login would fail if the salt changed ...
Those items from the config aren't used to hash the password. Take a look at the code that WordPress uses to hash and you'll see that none of them are used.
Just merge the old users into the new site and you'll be good to go.
Just merge the old users into the new site and you'll be good to go.
ASKER
Thanks - i thought i'd better check
ASKER
I've now checked after the merge and find that merged users cannot log in. So i suspect there might be some instance-specific hashing going on. I'm certainly not "good to go" :(
OK. Check the Users table in your DB and make sure the data has been merged correctly. Also check what version of WP you merged from.
Can you explain how your actually did the merge - that may play a part in it not working
Can you explain how your actually did the merge - that may play a part in it not working
ASKER
Can you explain how your actually did the merge - that may play a part in it not working
I took the INSERT statements from the backup script and changed the first value in VALUES from the id value to DEFAULT (using autoincrement)
OK. In wordpress there are several tables that deal with Users. The wp_users table just contains the username / password / email etc. There is also the wp_usermeta table that contains the all the other information, such as access rights / roles etc. You'd need to make sure you're migrating both tables.
ASKER
I know about the meta table. The problem with that is that the data don't pertain in both cases. Actually i don't think that anything other than wp_users controls the actual login, does it?
1) My ultimate goal is to merge users from an old instance into a new one, so i might need to explorer the implications of that.
This is simple. Use one of the many user export + import plugins.
Export all users from one site + import them to another site.
Then reset all user passwords. Then they will just do a password reset + all will be well.
2) I took the INSERT statements from the backup script and changed the first value in VALUES from the id value to DEFAULT (using autoincrement).
Read Chris Stanyon's comment closely.
You can't just randomly change some SQL + jam a bunch of users into a WordPress database + expect this to work.
Best to restore your latest backup now, as your database is likely destroyed.
Then follow suggestion from #1.
This is simple. Use one of the many user export + import plugins.
Export all users from one site + import them to another site.
Then reset all user passwords. Then they will just do a password reset + all will be well.
2) I took the INSERT statements from the backup script and changed the first value in VALUES from the id value to DEFAULT (using autoincrement).
Read Chris Stanyon's comment closely.
You can't just randomly change some SQL + jam a bunch of users into a WordPress database + expect this to work.
Best to restore your latest backup now, as your database is likely destroyed.
Then follow suggestion from #1.
https://www.wpbeginner.com
The usermeta table contains the role and permissions of the user, so without that they can't log in. You need to migrate both tables across.
If you do, you'll need to make sure the User IDs match. As David says, if your ultimate goal is to migrate users, look at one of the many plugins as it will be much easier than trying to do it manually
If you do, you'll need to make sure the User IDs match. As David says, if your ultimate goal is to migrate users, look at one of the many plugins as it will be much easier than trying to do it manually
ASKER
I'm sorry Chris - i'm afraid i blundered owing to Javascript being partially disabled. Login works perfectly with it fully enabled
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Yes, thanks. I'll bear that in mind
From a deeply technical standpoint, yes... in a way... and...
Does a salt value alter actual password hashes stored in the database, no.
For example, if you reset all your salt values, all sessions will login + you will then login again with your existing password, so your hashes don't actually change in the database.
https://ithemes.com/securi