Allow better database password protection (10 posts)

  1. kelly7552
    Posted 3 years ago #

    Certain hosts like dreamhost offer features that allow some cross user file sharing, for PHP programmers using mysql you could have an include file 'buried' in a separate user with the MYSQL database password. So if a php script insertion happens, the hacker cannot 'see' the password. The assumption for this to work is that the mysql connect call have the password in it directly and not in a variable, and NOT in a GLOBAL variable. WordPress puts the password in a global variable in wp-config.php then wp-include/wp-db.php uses it to open the database. If wp-config were written in a way to both have the password and connect the database, then this code could be isolated, and put in a place that was secure with an includes statement. Right now all a hacker needs to do after a script insertion is echo DB_PASSWORD and s/he's good to go!

    So in a perfect universe wordpress would create and includes file with configurable links to place it where ever we want, and all DB password would be in variables that don't survive the reach of the include.

  2. Certain hosts like dreamhost offer features that allow some cross user file sharing, for PHP programmers using mysql you could have an include file 'buried' in a separate user with the MYSQL database password

    Having cross-user filesharing like that strikes me as a hell of a lot more dangerous than the php script insertion ... I mean, I could do a lot of damage without needing to touch your DB.

  3. kelly7552
    Posted 3 years ago #

    To be clear on the concept,

    User A and User B are the same dream host account (therefore the same file ownership), USER A has a directory hidemyfiles with a permission of 110, in the directory is wp-config.php (with a permission of 440) which is an includes file of wp-config.php containing passwords and other sensitive stuff. User A has group read permission user B does not, in the end PHP includes only needs execute privilege to work.

    Right now lots of websites are telling Word Press users to move wp-config.php out of the web directory or make an include out of the web directory. Those would be useless to a script insertion, but so would everything else BECAUSE the damned password is a GLOBAL!


  4. I think I'm not understanding why two users share a dreamhost account. This sounds really ... weird to me. I have a server (a VPS) and every account on the server is it's own account. If someone wants a second login account, it's presumed they trust the person to give them that access. How is this special on Dreamhost?

    Yes, having the password a global is dangerous but it's like closing the barn door after the horse is out. You can't get to the files without having access, and you shouldn't have access without being given that (or you hack in, at which point I'm screwed anyway), and if you're given that access, clearly I trust you.

  5. Dion Hulse
    Lead Developer
    Posted 3 years ago #

    Lets just ignore the global constant for a moment here.. Even if it wasn't a constant, Being able to execute PHP code to start with is much more dangerous, If you can execute PHP on a target, you can forcably re-include any configuration files, thus including the password again.

    You could make a Database Dropin which simply extends wpdb and do whatever you want with the password if you wished.. For example, you can have a look at this db file to enable MySQL SSL: http://pastebin.com/caZpUfZm you can define DB_PASS to anything in wp-config, and have that file access the password however you wish.

  6. Not that I think it's any more secure, but make a file or symlink in wp-content named db.php, and that gets loaded instead of the wp-db.php file. Make a copy of the file there, put any changes in it you like, including hardcodeing the password and such.

  7. Someone kicked me this URL: http://wiki.dreamhost.com/Enhanced_User_Security

    So ... it's exactly what I was thinking it was. If you open up your site to other people, you get what you deserve.

    Don't disable Enhanced User Security. That's just like leaving the keys to your car in the ignition, and the door open.

  8. kelly7552
    Posted 3 years ago #

    Let me try to explain myself better: Dreamhost allows an unlimited number of users per account. The current recommendation is to have 1 user per application. So if you run wordpress on mysite.org/blog you'd have a user for mysite.org and a user for mysite.org/blog and BOTH would have enhanced security. This process is to create a 3rd user which has NO website, and can only be accessed by SFTP. This user would not have enhanced security turned on. On this user we'd have a directory mysite with execute only permission and in it we'd have a file include.php with the permission of 440. The effect of this is not to decrease your security, but to significantly enhance security. In this configuration, two users in the same account CANNOT share files, my solution allows a one way, execute only solution for password safety.

    Back to my issue: The entire solution is voided by the current design of wordpress to transmit passwords all around.

  9. Dion Hulse
    Lead Developer
    Posted 3 years ago #

    Back to my issue: The entire solution is voided by the current design of wordpress to transmit passwords all around.

    And both me and Otto have pointed out that you can use a Database dropin to overcome the specific use-case you have. Ultimately, unfortunately your scenario is unlikely to be used by most people, and Dreamhost having multiple users per customer account is useful, but not common outside of them.

    It wouldn't matter where it was stored, A constant, a Variable, the result of a function lookup, the fact is, the password has to exist somewhere within the application, and making it available via a constant is the most obvious and useful method.

  10. kelly7552
    Posted 3 years ago #

    Cool I will look into it. Just concerned about all the people who are telling WP users to move their passwords to the root file, outside the website. This is pretty useless advice in the face of all the hacks we've had lately and all the cleanup people are having to do to wp databases.

Topic Closed

This topic has been closed to new replies.

About this Topic


No tags yet.