7

If I change all the cookie & salt hashes in wp-config will all currently stored passwords need to be re-set?

define('AUTH_KEY',         '9YF,b]b:G5,!@Z||G.r*lI`?yl+u_-=2SO@# :Y8f1ZW=qP)U^w+(V=i:NTZ|v/N');
define('SECURE_AUTH_KEY',  '@AoU9+`<IztB@~49`PB#+YBqiz%{xRZ<_Yp+-3$h2T|{v-cJKi^of+uK..+[41nS');
define('LOGGED_IN_KEY',    '+Xnu<OsPjg]#](HJ)j|`hCaMU5M7bv<Nk]t|r#P|Ln(G}+8+_.yqz,+U!Z+~@b4F');
define('NONCE_KEY',        '8MTF|G,yw>nNK/Ne*I4__kr~Ab.o4@WRAh03^Yy*nep|->FJ-%;&dSF80>hqb1GK');
define('AUTH_SALT',        'y2qJ|e|ug%yz]z1uQPYnyxgY|izrnVq8{N]~d)K5*,psJzazLE{ed~xo2&`nncKO');
define('SECURE_AUTH_SALT', 'rswSqKj#l(F&3Sh&nA.:eob32Gg11hcNH68_+WAi4/n|V_+X~4{zxShr_srf]N2d');
define('LOGGED_IN_SALT',   '%(0jiu`GI&{r9`&ZwO?AG7xve]4g?uYD2?-,4h#A{t7N*hWL6N,#hr{&UB;|^{#L');
define('NONCE_SALT',       'Z|EL[9mU=-5WIWpa}-=T@Aj9xR3q}9|[*<gMk1fx*U[8>1zy*yiG}R7E9;.<?j}+');

Disclaimer: not real keys - https://api.wordpress.org/secret-key/1.1/salt/

I know the salt is stored both in the database AND in wp-config and are often used together to create the hash however the 'one way' hashing of passwords (rather than encryption) is meant to add a level of entropy not feasibly reversed...

So then if the salt is changed wont all subsequent attempts to match the hash of the password fail?

I'm just confused as some places claim you should change these keys regularly (from once a month to every 6 months)

1 Answer 1

9

No the passwords won't break (those are in the database and aren't changed by changing the salt). However all logged-in users will have to login again.

More on Salts here.

Note: Updating your keys & salts will force all logged in users to log in again, because changing them automatically invalidates the login of any user logged in to the site. For example, if you have any suspicions of a hack, updating your security keys and salts will force the logout and reauthentication of all logged in users.

And a very good, and much more technical explanation here.

The salt gives your logins an extra layer of security, as they are added to the cookie the user gets when he/she logs in. Without the salt, the username and password are much easier to crack/guess/hack.

Feel free to change the salts often, some say every 30 days for added security, though personally I don't change them this often.

6
  • 2
    +1 but something is really wrong with your security model if you feel the need to change salts every month. salts should be changed if the are exposed, and if they can be exposed.... well your problem is most likely much more serious than the value of the salts and will not be solved by changing the salts Commented May 16, 2018 at 19:27
  • Agree, most of the docs I've seen and recommendations say to change them often "to be safe", not because of any particular vulnerability. Commented May 16, 2018 at 19:41
  • The one thing missing from your answer is that nonces will "expire" as well, therefor I will not just change it without a good reason "just because" someone thought it is a good idea but have no concrete explanation why ;) Commented May 17, 2018 at 3:51
  • There're tons of ways someone could get salt values. Many of them don't require any compromised server (think about someone looking at a developer's screen).Exposed salts don't equal hacked site, but makes brute force much more easier. Changing salt values often prevents hurt from someone that stole the salts, but didn't make a "successful" use of them because had no time or will (yet).Surely it's a "paranoia mode on" kind of thing, but depending the kind of stored data (or how much you have to pay if the client site is hacked) it's not bad idea to do it, even because its cost is close to zero
    – gmazzap
    Commented May 17, 2018 at 14:26
  • Thanks for the input everyone - I assume then the particular salt is stored against the user when the password is created then? Or else there would be no way to verify subsequent logins... If so where are they - can't see any in any user tables...
    – Bysander
    Commented May 17, 2018 at 15:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.