LAMP stack, dedicated server.

I set up some MySQL users, gave them full access rights to the necessary databases, and provided the user credentials to some freelance developers.

Now that the project is concluding, I've:

  • changed those passwords and updated any reference to them in the code
  • removed all developer FTP accounts
  • changed the cPanel password
  • verified that remote MySQL access is disabled

My question is:
What security risks are created and/or exacerbated by a malicious actor having valid MySQL credentials but no FTP, SSH, cPanel, or remote MySQL access?

  • it will be a little hard to say without scoping out your situation, but the first thing that comes to mind is sql injection attacks – schroeder Feb 15 '16 at 18:48
  • 1
    Thanks. How does possession of valid MySQL credentials increase vulnerability to injection attacks? – Nathan Feb 15 '16 at 18:53
  • I'm not clear on the question. If you've changed the passwords, confirmed that the new passwords work and the old ones don't, do the developers have valid credentials? – h4ckNinja Feb 15 '16 at 18:54
  • They do not. My question is more for future guidance. In this case, each freelancer had access for varying portions of the project, but I waited until the end before locking down. This was a lot more convenient than changing all mySQL user passwords and code every time I revoked any individual's access, but I don't want to trade security for convenience. – Nathan Feb 15 '16 at 19:04
  • @fournines it does not increase the vulnerability of injection attacks, but if there is one, then knowing valid credentials can make a bad situation worse – schroeder Feb 15 '16 at 19:06

For most information systems, the asset value lies not in the software but in the data - so anyone with access to the data has access to the primary asset. There is scope for information theft, vandalism and injections.

You say you have now changed the passwords, however...

Assuming that they only ever had remote MySQL access, they could still install a backdoor using SELECT....INTO FILE to create a PHP, or Perl script.

If these were developers working on code you are still running then they could have added backdoors in that code too. Having inherited a system in just that state, I know how hard it is to identify the bad code.

That you use FTP and CPanel does not inspire a lot of confidence in the integrity of your system.


The risk you're talking about is just a bit easier Code injection risk : they will have no need to run password "guessers"/crackers - it's not a laborious part of a hack nowdays. So you have no serious reasons to worry about.


No direct threat. But below given are the threat vectors I can remember.

  1. Imagine a situation where the adversary gained shell access on your application server. In that case, without much reconnaissance he/she can gain full access to your db.
  2. People are likely to reuse passwords. Attackers may be able to re use it elsewhere

Your Answer

