If an attacker knows my database username and password, what can he possibly do if he doesn't have access to my server? Let's say my database is using Microsoft SQL Server. Is there a way he can use those credentials to manipulate my database?

  • 1
    I'm kind of surprised nobody mentioned 'social engineering'. There's not enough content in my comment to make that a full fledged answer, but be aware of it. Feb 6 '14 at 23:46

Assuming that

  • You're 100% sure that your database server only accepts local connections.
  • You're 100% sure that the attacker doesn't have access to the local environment from which connections are allowed.
  • You're 100% sure that the application that uses the database is otherwise secure.
  • You're 100% sure that those credentials aren't used for anything else directly or indirectly related to the system.

Then, there's no problem in them being exposed.

Of course, as you can see, those are very big assumptions. If you're willing to take the bet, then go ahead and allow the credentials to be exposed. If not (I wouldn't), then work as best as you can on your security, and keep those credentials secret.

  • 14
    Also, if you have reason to suspect your database credentials have been compromised, CHANGE YOUR CREDENTIALS.
    – Shadur
    Feb 6 '14 at 16:08
  • 1
    And for good measure cycle any encryption keys that might be tied to the credential.
    – Steve
    Feb 6 '14 at 17:17

If he can't access the database, the credentials are meaningless. It's like having a key to a door that's inside a guarded military bunker hidden in a remote location in the Gobi desert. The key is only useful if you can get to the door.

That being said, it'd be very bad practice to let your credentials leak out like this. If you suspect that they're compromised, go change them.

  • 8
    Of course, your analogy works both ways. A determined enough infiltrator could find a way into the bunker and use that key. Doesn't matter whether or not they would - if it costs you almost nothing to change the lock, then why take the risk?
    – Aaronaught
    Feb 6 '14 at 17:11
  • Admittedly that could be a big 'if' WRT cost of changing the credential -- though hopefully the system has been designed to make this a simple process.
    – Steve
    Feb 6 '14 at 17:18

As long as the DB server is properly secured and the credentials are properly linked to IP addresses that he doesn't have access to, then he can't do anything with them, but it removes one level of protection and if he does find a way to access the DB, then you are hosed.

This is called defense in depth. Multiple mechanisms prevent a compromise, however if one level is suspected to be compromised, you are less secure until you fix the compromise.


In practise, almost all sql databases (MsSql, MySql, Oracle etc) have ability to execute operating system commands. So if attacker knows your DB password, he can execute OS commands on DB machine. If process which runs your db engine has high privileges then attacker can takeover your whole machine. Beyond this is limited with your imaginary. For example:

  • He/she can attack other computers in your network from the db machine.
  • If you are using virtualization, attack can be extended to VM engine and other OSes on virtual environment can be compromized.
  • Collect very important sensual data for future social engineering attacks.
  • Take user account names and passwords and try them for other information systems on your organisation. People mostly use same strong? password on multiple systems.
  • Listen traffic in your network and sniff important data.
  • Insert a trojan or backdoor for future access etc.

What you can do to protect yourself although attacker knows your db password:

  • You can limit db user account's privileges. Don't forget attacker can sometimes also increase his/her privileges on machine by special exploits using vulnerabilities on your OS.
  • Disable shell execute abilities of DB server (but mostly db user accounts have privilege to enable it again)
  • Limit db engine process privileges. Most of the time sql injection attacks are successfull because of wrong installation of db servers. Especially MsSql setup lets easily setting admin accounts as db process owner.
  • Isolate your db machine from network. Only let incoming requests. You need to do this by an outer firewallish machine. Remember attacker has access to OS so he/she can enable it if you limit it from DB Server.
  • Protect your users' accounts by hashing (with a salt of course) and if your CPU resource is available protect sensitive data with symmetric encryption at application level.

This is not a complete list. It can be grow larger.

  • "So if attacker knows your DB password, he can execute OS commands on DB machine." does not follow. The crucial middle step is that he also needs to get access to the DB.
    – Matt
    Feb 7 '14 at 16:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.