Free tool · no signup
wp-config.php hardening and salt generator
Make a fresh set of WordPress security keys and salts in your browser, and add the settings that close common holes: no code editor in the dashboard, https for the login and no debug output on a live site.
By the Bug Circuit security team · Last updated
Settings
/** Hardening settings. Place these above the line "That's all, stop editing!". */ define( 'DISALLOW_FILE_EDIT', true ); // no theme and plugin code editor in the dashboard define( 'FORCE_SSL_ADMIN', true ); // log in and use the dashboard over https only define( 'WP_ENVIRONMENT_TYPE', 'production' ); define( 'WP_DEBUG', false ); define( 'WP_DEBUG_DISPLAY', false ); define( 'WP_DEBUG_LOG', false ); @ini_set( 'display_errors', '0' ); define( 'WP_AUTO_UPDATE_CORE', 'minor' ); // security and maintenance releases only
- Back up wp-config.php first.
- Delete the eight old key and salt lines, if you are replacing them.
- Paste this block above the line that says
That's all, stop editing! - Load the site and the login page to check nothing broke.
- Keep wp-config.php out of the web root if your host allows it, deny it in .htaccess, and set its permissions to 640 or stricter.
How it works
What the keys and salts do
WordPress uses eight values (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY and the four matching salts) to sign login cookies and security tokens. If they are weak, shared with another site or have leaked, an attacker who obtains a cookie can keep using it. Replacing them invalidates every existing session, which is exactly what you want after a compromise or when an employee with admin access leaves.
The generator creates each key as 64 random characters using the cryptographic random generator of your browser, picks characters without bias, and avoids quotes, backslashes and dollar signs so the values are safe inside a PHP string. They are made on your device, never sent to us, and not stored.
The hardening settings
DISALLOW_FILE_EDIT removes the theme and plugin code editor from the dashboard, so an attacker who gets an admin login cannot edit PHP files there. FORCE_SSL_ADMIN keeps the login and dashboard on https. Setting WP_DEBUG, WP_DEBUG_DISPLAY and WP_DEBUG_LOG to false stops error messages, which can reveal file paths and database details, appearing on a live site. WP_ENVIRONMENT_TYPE marks the site as production, and WP_AUTO_UPDATE_CORE controls which core releases update themselves.
Two options are for specific situations. DISALLOW_UNFILTERED_HTML stops even administrators posting raw HTML and script, which limits the harm from a stolen editor account but can break page builders. DISALLOW_FILE_MODS blocks every install and update from the dashboard, which is strong but means you must update some other way, so leave it off unless you have that routine.
Adding them safely
Back up wp-config.php first. Delete the eight existing key lines if you are replacing them, and paste the new block above the line that says "That's all, stop editing!", because settings after it are read too late. Load the site and the login page straight away. Then check the file itself is protected: set its permissions to 640 or stricter, deny direct access in .htaccess, and move it one folder above the web root if your host allows that.
Worked examples
The block it produces
Keys on, the safe defaults ticked.
define( 'AUTH_KEY', '...64 random characters...' ); ... define( 'DISALLOW_FILE_EDIT', true ); define( 'FORCE_SSL_ADMIN', true ); define( 'WP_DEBUG', false );
The values are new on every click of Make new keys, and different for every visitor.
After a hack
You found and removed a backdoor.
1. Make new keys and paste them in. 2. Everyone, including the attacker, is signed out. 3. Reset every admin password.
Replacing the keys alone is not a clean-up, but it closes the doors that stolen cookies would otherwise keep open.
Updates handled elsewhere
You deploy with Git and never update from the dashboard.
define( 'DISALLOW_FILE_MODS', true );
Only safe when your deploy process updates plugins and core for you, because the dashboard can no longer do it.
Frequently asked questions
What are the WordPress salts and keys for?
Will changing the salts log everyone out?
Are the keys really generated in my browser?
Is DISALLOW_FILE_EDIT safe to enable?
Why not use the official WordPress key generator?
Where exactly do I paste it?
Does this make my site secure?
Keep reading
See what attackers see, for free
Run the free passive check on your website. No login, no impact on your site, results in seconds.
Ready for the full manual audit? See pricing