Uhh.. the user passwords in my database are 34 characters long that look like gobbledygook.
So, it’s certainly encrypted.
Moderator
Jan Dembowski
(@jdembowski)
Forum Moderator and Brute Squad
Why does WordPress stores DB password in plain text?
If you mean the passwords in wp-config.php then the answer is “Because mysql requires the passwords to work.” and that’s not just a WordPress issue.
If there were a way to encrypt it (there isn’t, more below) then that would be used.
The reason it isn’t encrypted is because you’ve need to also store the decryption keys somewhere WordPress could find it. That gets you back to square one and storing plain text keys is a really bad idea.
There may be ways to make that work but that would also make WordPress a higher order of magnitude difficult to support when users lose their passwords.
The solution is to protect the wp-config.php file. There is never a scenario where that file should be loaded by a browser and all such requests should be blocked at the web server level.
There is never a scenario where [wp-config.sys] should be loaded by a browser…
The above case (linked) seems to prove you wrong? How can you stop that attack then?
the user passwords in my database are 34 characters long that look like gobbledygook.
So, it’s certainly encrypted.
I must respectfully disagree with your definition of encrypted. It may be difficult to guess but certainly in plain sight when the file is accessed.
I have already showed you a hacking example where wp-config.sys is accessed remotely. I think I can copy and paste your long password…
Moderator
Jan Dembowski
(@jdembowski)
Forum Moderator and Brute Squad
The above case (linked) seems to prove you wrong?
It doesn’t prove that at all. You are conflating a revslider vulnerability to clear text passwords in wp-config.php.
Your WordPress installation needs to be able to access the mysql database and those credentials are stored in that wp-config.php file. The article you linked to demonstrates that that plugin was vulnerable and permited remote viewers to access any file on your installation.
The solution there is make sure your code is secure and that you keep up with your versions. You can use your web server to deny requests to /wp-config.php but if a plugin will hand you that file or any file then the problem is that plugin.
You are conflating a revslider vulnerability to clear text passwords in wp-config.php.
I am not conflating. I’m showing you that because of the use of clear text password a vulnerable code allows entire sites to be compromised at the highest level. Vulnerabilities happen. It is the way of life. ‘No’ code can be 100% secure. There ‘will’ be vulnerabilities. Security means you are prepared for that.
if a plugin will hand you that file or any file then the problem is that plugin.
The vulnerability was exploited becatse the passwords were accesible. If they were not in plain text hacking would not have worked! Can’t you see that?
A plugin is part of WordPress. It doesn’t matter if it is supplied outside the core files. WordPress is expected to have plugins. Hence, the developers of WordPress should have expected such vulnerabilities in plugins. Relying a system where the password is stored as plain text is wrong.
I cannot believe that after all those high level hacks during 2015, many in the international news even, here I am trying to explain that relying on plain text password is a bad, bad practice.
Moderator
Jan Dembowski
(@jdembowski)
Forum Moderator and Brute Squad
The vulnerability was exploited becatse the passwords were accesible. If they were not in plain text hacking would not have worked! Can’t you see that?
I don’t agree, but do you have an alternative? Again, WordPress needs that password to access mysql. And by alternative I don’t mean just stating “encrypt the password” I am asking how can this be done?
Obfuscating the password won’t work. The means of un-obfuscating would need to be available and if plugins or attackers can access all your WordPress files then you are back to square one.
Storing the password as an honest to goodness encrypted value somehow won’t work for the same reasons. WordPress needs the regular clear password and the keys to decrypt would be available to attackers as well.
Storing the password as an honest to goodness encrypted value somehow won’t work for the same reasons.
You have just said that THE only solution on a CMS is to store plain-text password on a file, on a public path whose only protection is file attributes.
I’m not a wizz-kid coder but I cannot buy that, the above decleration is true. I sincerely hope that someone will prove you wrong.
