I've come to think about the question wether it's possible to disassemble a program to retrieve the credentials it's using to connect to a database, or perhaps intercept the program upon runtime and manipulate the (SQL) query (not talking about SQL-injection).
Perhaps it's an ridiculous idea, but I need to know if the program that my customers recieve should use an account that only has access (and rights, i.e read-only) to specific tables.
It's definitely not a ridiculous idea - there are many tools to disassemble a program into source-code. In the .NET world you have Reflector and ILSpy for example, and most languages have something equivalent.
If a username or password appears in plain-text in the source code, then it is trivially easy to obtain it with dissassembly tools. If it appears encrypted, but the encryption algorithm and key are part of your source code, then it is merely quite easy to obtain it.
To resolve this, in the .NET world you can store an encrypted password in the config file.
Alternatively, you can configure the database to use domain authentication, in which the user's domain account is transparently used for access, not a hard-coded username/password.
Finally, you should always use the Principle of Least Privilege wherever possible - only allow a user permission to perform the smallest subset of actions that is required.
In theory every program you make is a candidate to be disassembled, so you should never write any credentials directly into them.
Depending on the kind of program you are making there are some alternatives to writing credentials, for example in a web application you should use a jndi lookup to search for a server connection that you create separately from your app, so you don't store any connection info in the program.
If you are writing a desktop app, you could still use a jndi lookup but it will be a little more complex, in that case maybe you want to create a server application that will handle authentication and database connections from the server, and will only display the data to the client application.
If you're using the same account for all your customers and you're going to let it spread around, that's equivalent to not setting a password at all for that account (or to make it public), even if that's put inside your binary code. That's because it's de-facto impossible to keep control over a piece of reserved information that reaches more than 5 people, even if those are reliable, the systems they work with are not. If you really want to control who accesses your DB (as you should), keep the authentication on a restricted place, such as on the server side, as suggested above.
Regarding man-in-the-middle attacks, if you're going to communicate over unreliable networks (e.g., not your small LAN), you should assume this can happen (either to sniff SQL or any other type of information) and you should protect your communication, for instance by using encrypted connections (e.g., SSL or TLS). Unless, of course, you don't care what is sent around, or you accept a low-to-medium risk to be intercepted.
From a security point of view, diassembly is always possible. A sufficiently sophisticated attacker can just read the machine code and figure out what it does, as if it were normal source code. Sure, it's not easy, but it's hard in the "it requires decent tools and some cleverness" sense, not the "it's thought by mathematicians to require more time than the sun is expected to last" sense.
Disassembling a third party product is usually a violation of the license agreement so it is not recommended for that reason, alone.
That said, applications rarely use hard coded database credentials, since they are usually installation or deployment specific. Many applications store them in the web.config or app.config file. Legacy applications may store them in the registry.
A better solution may be to run a network sniffer like WireShark and look at the packets going across the network. If it is SQL Server, it will use port 1433 by default.
