localhost in the case of Wordpress just means the database is running on the same machine as the web server. Practically every WP instance is set up that way.
That's not what he meant. What he meant was reading that the database is on localhost doesn't mean it's a development system. Many production instances of Wordpress run the database on the same host. Therefore localhost can also mean production. That might not be true for other services, but for Wordpress that's common. This is what he meant.
Most wordpress devs support multiple environments in their .wpadmin (dev -> localhost, prod -> some server). So this is creating a lot of false negatives.
Exactly. Also remember that on many many wordpress servers you also have phpMyAdmin. You can use the username + password to login, and you'll get access even when it's restricted to localhost.
It's pretty scary to have phpMyAdmin public facing. IIRC some older versions of mysql-server even had a bug where it'd let you in with a random password in 1/256 chance!
It should be really bad, since phpmyadmin get attempts are the most frequent on my home webserver and I don't even have it installed. Maybe older vulnerable versions are still around though.
I agree with mahouse and of course are some of these password legit. But this is nothing new, don't store sensitive data in git. Everyone know you can search this stuff on GitHub and if we look back - Google was a nice password search engine too (and still today)
How would you go about making a repeatable, automated deployment if you don't store configuration information in source control to load into the environment variables?
Doesn't this just push the problem up (down?) a level in the hierarchy? I mean, you still need to deploy these and configure them with the information the rest of your deployment requires right?
That link is talking about a problem with e.g. .htaccess and basic directory permissions, not a problem using git per se. But yeah, put that stuff in envars.
If there's any question, I think the rule has to be the former. There are standard, auditable ways to keep sensitive data out of git: .gitignore, environmental vars, etc. Once it's in git, any attempts to keep it out of a public repo will probably be manual and ad hoc.
If the organization is "closed" by default, i.e. it only rarely releases code to the public, this may not matter as much.
If you're the sort of developer who puts a wp-config.php file in a git repo (eg no proper deploy process.. otherwise that file wouldn't exist in the repo, or no reference to the config file in .git-ignore), you're probably the sort of developer who'll use the same password on your local dev machine and your live site because "setting up MySQL users is hard."
Keep clicking, because I found what appear to be two valid passwords in 5 different config files (with public hosts.)
Obviously I didnt test them, so you might be right that they change or are in dev mode, but that smells like a lot more than 6 9s.
