SQL login security?

Yes, the DB password can easily be extracted by a hacker with the client, which is why it's recommended to have the client communicate with a trusted server, who in turn connects to the DB.

What about if the client was supplied with credentials that limit them to the use of their own area of database?

Would this suffice?

Yeah, that limits the damage that a hacker can do, e.g. they won't be able to delete your whole database or add new tables ;)

However, depending on what you're using the database for, this probably still leaves the door wide open for cheating.

This is more for a network client utility (rather than a game). So, if a user puts in dodgy stats, then they are essentially 'cheating' themselves.

Their dodgy stats wont have any effect on other users or the other users 'experience' within the app.

So, this is probably the option I will take (at this stage) to reduce development time. If the app becomes popular (dependent on completion of-course), I might up the security then.

Thanks Hodgman :)

Even disregarding issues like password theft, letting anyone directly connect to your database server is a terrible idea.

If it's possible to connect to a database directly, it is in principle possible to exploit it, which includes using some SQL injection hack to delete anything the user has access to, or do something worse -- in the worst case rooting the server.

One should never let someone access a service that will execute more or less arbitrary input (such as a database server will do!). You wouldn't let someone send arbitrary perl or python scripts to your server either!

Always make them access some program or script which only accepts some precisely defined requests, pedantically validates data, and then forwards that a well-formed request to the database.

Even disregarding issues like password theft, letting anyone directly connect to your database server is a terrible idea.

Agreed.

Even a thin API wrapper between your internal applications and your database can be a positive thing. For the most part the main issues here are shielding yourself from malformed, incomplete and/or intentional malicious things - most notably the unintentional especially where quotes and special character escaping like $@!* are concerned. It is relatively simple to do since in most cases queries only require on a very small portion of information from the actual client side such as a function name and a date range or other criteria found in the 'WHERE' clause.

In most cases the only information a client should send is (authentication to your app server should be separate from the database login credentials and already complete at this point!) a few variables set to determine what function to call and the parameters it needs to reliably build the query server side. It is important to note that this forces you to an extent to validate the client requests and validity of their request before sending anything to your database and not rely solely on the somewhat lacking security features on various database engines.

This is not only ideal for security reasons but for maintainability. You can usually update/improve your query server side without having to update the clients in any way.