Fixing weak salts

WordPress signs every login session — and the magic links and codes MagicAuth emails — using eight secret random values called security keys, often shortened to salts. They live in your site's wp-config.php. If those keys are still the placeholder text WordPress ships with, or are empty, MagicAuth shows a notice asking you to set real ones.

This is a quick, one-time fix, and nothing here can lock you out: MagicAuth never edits wp-config.php for you, and there are always three ways back in.

Why this matters

Your wp-config.php contains eight lines like this:

define( 'AUTH_KEY',         '...a long string of random characters...' );
define( 'SECURE_AUTH_KEY',  '...' );
define( 'LOGGED_IN_KEY',    '...' );
define( 'NONCE_KEY',        '...' );
define( 'AUTH_SALT',        '...' );
define( 'SECURE_AUTH_SALT', '...' );
define( 'LOGGED_IN_SALT',   '...' );
define( 'NONCE_SALT',       '...' );

These secrets are meant to be unique to your site and known only to your server. When WordPress is installed by hand, the sample config ships them as a fill-in-the-blank:

define( 'AUTH_KEY', 'put your unique phrase here' );

If those placeholders were never replaced (or the lines are empty), your "secret" keys are the same public example text anyone can read in the WordPress source. That weakens your WordPress session cookies and other internal tokens.

Your MagicAuth magic links and codes stay safe either way — each one carries its own random secret that is never derived from the salts — but strong salts are part of a healthy WordPress install, so it is worth fixing.

The fix

You will edit one file. Most people use their host's File Manager (in cPanel, Plesk, or the hosting dashboard), an SFTP app like FileZilla or Cyberduck, or their code editor on a local site.

1. Open api.wordpress.org/secret-key/1.1/salt/ in a new tab. It returns eight ready-made define( ... ); lines, freshly randomised. This is WordPress's own official generator. Any set it gives you is fine — leave the tab open.
2. Open your site's wp-config.php. It is in the main WordPress folder (the one that also contains wp-content and wp-admin). Some hardened setups keep it one folder up (the folder above the WordPress directory) — if it is not next to wp-content, look there.
3. Find the eight existing lines that start with AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, AUTH_SALT, SECURE_AUTH_SALT, LOGGED_IN_SALT, and NONCE_SALT, and replace all eight with the lines from step 1.
4. Save the file.
5. Back in WordPress, reload Settings → MagicAuth (or any admin page). The notice clears itself.

A few things to keep it safe:

• Replace the whole line, including the quotes and the trailing semicolon.
• Replace all eight — do not leave any placeholders behind.
• Leave every other line alone. In particular, do not touch the DB_NAME, DB_USER, DB_PASSWORD, or DB_HOST lines — those are your database settings, not your keys.
• Do not leave a copy named wp-config.php.bak on the server; a readable backup would expose your database password.

Managed and environment-based hosts

Some platforms — WP Engine, Pantheon, Flywheel, Kinsta, and Bedrock-based sites — set your keys through environment variables rather than as plain text in wp-config.php. You might see a line like:

define( 'AUTH_KEY', getenv( 'AUTH_KEY' ) );

MagicAuth reads the keys your site has actually loaded, so when these are set correctly it sees strong keys and shows no notice.

If you do see the notice on a managed host, it means the live keys really are weak or missing at runtime. Do not paste literal keys into wp-config.php to override the platform — instead, ask your host's support: "Are my WordPress security keys (AUTH_KEY, SECURE_AUTH_KEY, and the rest) set to unique, random values?" Most managed hosts set strong keys automatically and can confirm or rotate them in one reply.

Can I turn on the branded login screen anyway?

Yes. The weak-salt notice is advisory, not a block. You can enable Replace WordPress login screen under Settings → MagicAuth → Branding while the notice is showing; MagicAuth saves the choice and shows a reminder. Fixing the salts first is still recommended, because it strengthens your WordPress session cookies and the short 6-character codes — but it is your call.

If you get stuck

You cannot be permanently locked out. Three independent ways back in, from easiest to most hands-on:

1. Use the "Sign in with password" link on any MagicAuth sign-in form. It drops you onto a normal password sign-in.
2. Add ?magicauth=off to your login URL: https://your-site.com/wp-login.php?magicauth=off. This shows the standard WordPress login for that visit.
3. Add define( 'MAGICAUTH_DISABLE', true ); to wp-config.php to switch MagicAuth off entirely while keeping all its settings. Remove the line to turn it back on.

See Troubleshooting → Lockout recovery for the full details.

Still stuck?

Double-check that you replaced all eight key lines and saved the file. On a managed host, confirm with support that your keys are unique. If the notice persists after that, open a thread on the support forum or file an issue at github.com/EtticDevelopment/magicauth.