For about 10 years I’ve worked on various in-house desktop client applications with SQL Server data stores. Rarely did I start these projects – most are takeover work.

One thing that seemed constant everywhere was that there was a single global SQL Server user account that this application used that granted it permission to the common database, and yes in some naive situations it used the sa user account, which I generally tried to fix when possible.

You can’t really effectively hide this username and password that the application uses to access the database. They’re usually stored in an ini or config file, or possibly baked into the executable itself. In all cases, they’re visible to the user if they do a little digging. In one case we actually used a config file but encrypted it, but of course the encryption key had to be stored in the executable (we weren’t naive to the limitations of this, but it did effectively stop people from poking around who were savvy enough to look inconfig files).

READ MORE …

Category: DataBase Security