Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've lost the source code for a very old application that connects to a MS SQL-server for some SQL queries. Since the login is hard-coded in the application I can't change the username/password on the server. One day the password will probably be known to the users and we surely need to change it. But how?

One idea is to only allow the old application to do the queries on the SQL server and block out any other application like the query analyzer etc. Can I set process permission somehow?

  • The SQL server (MS SQL 2005) and application (C++) are on the same machine
  • It's too costly to rewrite the old program

Thanks for help!

share|improve this question
up vote 1 down vote accepted

You can't really do this, AFIAK. You could block the SQL ports with Windows Firewall so that only the machine running the application can connect to SQL, which you say is the SQL server itself. Of course, this breaks anything you have that connects using SQL that doesn't run on the SQL server.

Are you saying that the users are also logged into the SQL server (and thus able to run Query Analyzer locally), or are they always remote? If the former, you're out of luck. And what are you doing allowing users to login to the SQL server itself anyway? :-)

Can you try using a hex editor to find the password in the EXE and replace it? If it's encoded, even though you've lost the source, you must remember what algorithm was used to encode it?

You've definitely learned two hard lessons. Don't hardcode passwords, and don't lose things that you don't have backed up. Do you have other important things that aren't being backed up? You may want to do an audit of your backup & restore or DR processes. Or write some, if you don't have any.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.