I'm writing a Python script which uses a MySQL database, which is locally hosted. The program will be delivered as source code. As a result, the MySQL password will be visible to bare eyes. Is there a good way to protect this?
The idea is to prevent some naughty people from looking at the source code, gaining direct access to MySQL, and doing something ... well, naughty.
maskpass() maskpass() is a Python module that can be used to hide passwords of users during the input time.
The function is a successor of the less secure MD5(). The PASSWORD(str) function is used by the MySQL itself to store passwords of its users, but its not recommended to use it in your own programs.
You can't.
If the password is stored in the artifact that's shipped to the end-user you must consider it compromised! Even if the artifact is a compiled binary, there are always (more or less complicated) ways to get at the password.
The only way to protect your resources is by exposing only a limited API to the end-user. Either build a programmatic API (REST, WS+SOAP, RMI, JavaEE+Servlets, ...) or only expose certain functionalities in your DB via SPROCs (see below).
The question here should not be how to hide the password, but how to secure the database. Remember that passwords only are often a very weak protection and should not be considered the sole mechanism of protecting the DB. Are you using SSL? No? Well, then even if you manage to hide the password in the application code, it's still easy to sniff it on the network!
You have multiple options. All with varying degrees of security:
Create one database-user for the application. Apply authorization for this role. A very common setup is to only allow CRUD ops.
DROP
queries (f.ex. in SQL injections?)UPDATE
and DELETE
queries without criteria (i.e.: delete/update a whole table at once).Create one database user per application-/end-user. This allows you to define atomic access rights even on a per-column basis. For example: User X can only select columns far and baz from table foo. And nothing else. But user Y can SELECT
everything, but no updates, while user Z has full CRUD (select, insert, update, delete) access.
Some databases allow you to reuse the OS-level credentials. This makes authentication to the user transparent (only needs to log-in to the workstation, that identity is then forwarded to the DB). This works easiest in a full MS-stack (OS=Windows, Auth=ActiveDirectory, DB=MSSQL) but is - as far as I am aware - also possible to achieve in other DBs.
UPDATE
and DELETE
rights can still accidentally (or intentionally?) delete/update without criteria. You risk losing all the data in a table.Write no SQL queries in your application. Run everything through SPROCs. Then create db-accounts for each user and assign privileges to the SPROCs only.
DELETE
and UPDATE
)You should never allow database administrative tasks to the application. Most of the time, the only operations an application needs are SELECT
, INSERT
, DELETE
and UPDATE
. If you follow this guideline, there is hardly a risk involved by users discovering the password. Except the points mentioned above.
In any case, keep backups. I assume you want to project you database against accidental deletes or updates. But accidents happen... keep that in mind ;)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With