Secure MySQL password in JAR file

Discussion in 'Plugin Development' started by GeekyGamer14, Dec 8, 2013.

Thread Status:
Not open for further replies.
  1. Offline


    I was just wondering, since I made a plugin that depends on MySQL, I need some way to hide my password.
    I want this:
    1. MySQL MySQL = new MySQL((Plugin) this, "111.222.333.444", "3306", "minecraft", "root", "passwordhere123");

    To become this:
    1. MySQL MySQL = new MySQL((Plugin) this, "(jibberish)", "3306", "minecraft", "root", "(jibberish)");

    Does that make any sense?
  2. Offline


    Yes, definitely!

    Well, in my opinion you should not put configuration info like this in your JAR directly. Something like DB connection parameters should be in a separate YML file (or whatever) that you do not distribute with your plugin (though distributing an example file would be nice)

    That way a server admin can set up their own connection info in a file that is secure on their server (well, secure in that only people with server access can see it).

    Otherwise you're going to be stuck in a chicken+egg loop- as in, you could encrypt the password, but then you have a decryption key you need to store in your JAR, and you're basically back to square one (though you have made it *harder* for someone to get the password, it's still possible).
    ZeusAllMighty11 likes this.
  3. Offline


    How would I securely get the config file from my web server?
  4. Offline


    You could also do the database connection with PHP I believe. You could then store the PHP file on your web host and create all the PHP methods in there.. Then you could maybe parse it into java.
  5. Offline


    Then it'd be as simple as a Bukkit.broadcastMessage(password) right before the actual SQL call.

    OP) You could make a user with only read perms, if that's all you need it for.
  6. Offline


    No, I mean that the PHP does all the MySQL and all the MySQL methods. It just returns whatever he would return is his methods. Example; Getting a player ID from username.

    His database may be storing sensitive information; this might not work.

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: Jun 5, 2016
  7. Offline


    DrMedia I can see what you mean by that, but I need to insert and update rows in the database. With a POST or GET call, anybody could do it without authentication.
  8. Offline


    Ahh, I forgot about that. Sorry.
  9. Offline


    You can't secure a password inside a plugin.
    There is always a way to get it.

    Why do you need to hide a password in a public plugin anyway?
  10. Offline


    GeekyGamer14 as NathanWolf suggested use a yml configuration. You could use a seperate custom config or the main config.yml of your plugin. For a start i would go for the latter.

    Use nodes like, mysql.port, mysql.database, mysql.username and mysql.password to store that data.

    To answer your question "Can you hide your password?" Well if it is your password to your database and you don't want to publish this data then fill the default configuration you include in your published jar with dummy data only.

    Anyone who will use your plugin would have to create a database user / database anyways so you do not need to provide such data.

    What you can do is provide enough informations on your plugin page (probably on a seperate page) to give enough information on "how to create that user/database".

    For security reasons others will hopefully not use root to connect to a DB and i strongly believe that you only use root as DB user because it is your test database.

    On topic "The password is clearly visible to anyone who can access that folder. Isn't that a security problem?".

    Well technicall it is but since you normally use a database user that does not have full access to the whole sql server (only to that database) with only local access there is no need to worry. Anyone who can access that folder should be handled as trusted or simply don't give them access to such places if it is something you count as critical.

    Also note that a sql server is normally only listen on localhost interface meaning it will not answer to queries from the outside world. Even if the server is configured to listen on a public interface the user would still need remote access rights and by default no one gets such rights so don't worry.
  11. Offline


    If you gather information from other servers, there will always be the possibility of abusing this
    by people with knowledge.
    Other similar systems can also be abused. Be it Facebook (fake- or multi accounts), a forum (mass-posting), or email (spamming).
    There is little you can do to avoid this. So either live with the risk of a minority abusing this, or you have to forget your idea.
Thread Status:
Not open for further replies.

Share This Page