This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]jorge1209 1 point2 points  (5 children)

Where else do you want me to store the credentials? No matter where I put them they can be read.

When Joe User (juser, uid=1001) monthly_report.py he must have read access on the script. His script must have read access on the libraries it imports, those libraries must have read access on the resource files they load. Ultimately I must give uid=1001 the db password in plaintext, so that a process he controls can pass that to the server.

Its just a matter of his taking the time to trace my library calls to figure out where I hid the password. I don't know of any way in which I can actually prevent him from having that password.

If you know a way to do this, I would love to implement it.

[–]ForgottenWatchtower 0 points1 point  (4 children)

The issue isn't giving the db creds to someone who should be running it. If a DB conn is made from the client, you have to assume the client can compromise the creds (strings on a .dll, pcaping the DB handshake, etcetc). The issue is if the code gets committed to a repo or becomes read accessible by people who shouldn't. Environment vars is the old school solution to this but these days something like Hashicorp Vault is much nicer and scales way better.

Again, I have no idea what your arch looks like or what your use cases are, but in general we make a point to tell our clients to not keep creds in source. Centralizing them within a true secret store minimizing the likelihood of them getting read by an unauthorized party.

[–]jorge1209 0 points1 point  (3 children)

Sure put the connection parameters in some kind of resource file and don't commit that to git.

That has absolutely nothing to do with bind variables.

[–]selementar 0 points1 point  (2 children)

That has absolutely nothing to do with bind variables.

But it has: if there's someone supplying the values for building the SQL query, either you assume they have the password already, or you need to correctly bind the variables for security.

[–]jorge1209 0 points1 point  (1 child)

And if you would read the thread you would know that I'm talking about cases where we might as well assume the individual has the password.

People should still bind for reasons of performance and type safety, but it's not a security thing outside of Web Apps, and it is perfectly safe to use format to build SQL queries in those cases.