Due to some relentless brute force login attempts on a user account, I’m experimenting with Microsoft SSO on a test server. Setup was successful and working fine, but the option to login with username/PW still exists so it really won’t mitigate hacking attempts while those are in place.
Considering editing wp-login.php and removing those fields. Would that effectively stop bot attempts or are bots written to directly send that info to the server whether the form fields exist on the front-end or not?
Also, I’m uncomfortable not having a username/PW option at all. The SSO integration is dependent on a plugin that I can only configure when logged in. If something goes wrong with the SSO plugin, I may be not be able to log in to troubleshoot it.
Thought about editing wp-login.php to add disabled attribute to username and pw fields and scripting a toggle to enable them. Wouldn’t think a bot would be ready for that. Or I could leave out the toggle and just edit the HTML in the browser to enable.
Would any of this be effective? Would new versions of WP overwrite changes to wp-login.php ?
[ad_2]
Definitely do not edit wp-login.php directly as it will be overwritten on upgrade. There are a number of different methods to secure your login. You don’t need all of these but these are strategies people use:
* Change the login URL (“security through obscurity” but it does decrease the bots)
* block xmlrpc.php if you don’t need it. Return a 403 status with a server rule
* Make sure you have good WAF in front of the site
* Use brute force protection plugin
* SSO is good
* Restrict wp-login.php by IP address. A hassle if you have a remote team and no static IP but doable
* Captcha on login
* Ensure user enumeration is blocked
To answer your initial question though you can modify the login form though with the `login_form` hook:
[https://developer.wordpress.org/reference/hooks/login_form/](https://developer.wordpress.org/reference/hooks/login_form/)
That would be the correct way vs. edit wp-login.php.