hiding/encrypting the Oracle database connection information?

11 views
Skip to first unread message

Terrence-Monroe: Brannon

unread,
May 15, 2020, 12:30:10 PM5/15/20
to sqlalchemy
Hello, what is the recommended way to encrypt/hide the connection information that SA will use to connect to an Oracle database?



Mike Bayer

unread,
May 15, 2020, 1:02:54 PM5/15/20
to noreply-spamdigest via sqlalchemy
that issue is unfortunately one of the great mythological stories of business application development, how to configure an application such that the database credentials are not present in a config file where they can be viewed.  

the scope of that issue is way outside of SQLAlchemy and personally I don't think there is really any feasible solution to that problem - not that the credentials can't be encrypted, but it implies that there's a decryption key right nearby, which renders the whole situation basically security theater.   Even if you have some super sophisticated remote-server kind of approach, if an attacker is on the machine where the software is, the Python code is right there; they can run whatever routines your Python code uses to get these credentials into memory and then they have them.

However, anyone that's worked in app dev for more than 5 years has had to deal with managerial teams that are trying to make it happen and perhaps theater is all you need.   There's a good stackoverflow rundown of the full issue I found at https://security.stackexchange.com/a/22858 .


On Fri, May 15, 2020, at 12:30 PM, Terrence-Monroe: Brannon wrote:
Hello, what is the recommended way to encrypt/hide the connection information that SA will use to connect to an Oracle database?




--
SQLAlchemy -
The Python SQL Toolkit and Object Relational Mapper
 
 
To post example code, please provide an MCVE: Minimal, Complete, and Verifiable Example. See http://stackoverflow.com/help/mcve for a full description.
---
You received this message because you are subscribed to the Google Groups "sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+...@googlegroups.com.

Jonathan Vanasco

unread,
May 15, 2020, 1:59:30 PM5/15/20
to sqlalchemy
There are two related concerns on this concept:

* protecting your credentials in source code
* protecting your credentials on the server

For the first concern, I like to use encryption management tools like Blackbox (https://github.com/StackExchange/blackbox)

With an encryption management system, you "enroll" certain files to be managed by the system.  Instead of saving the plaintext files to version control, the encrypted files are saved.  Approved users (via GPG keys in blackbox) are able to decrypt or edit (decrypt+edit+encrypt) the files.  **When a project is deployed to a server, the files are decrypted and the plaintext version is left on the server**

For the second concern, I've never seen a foolproof way to safeguard the plaintext "secrets".  You can force stuff into environment variables, but hackers can still get to those.  You can trash files after starting an application... but then you can't restart the application unless you have an external service that logs into the machine and decrypts/reloads/deletes.  

I would focus on safeguarding your secrets from versioncontrol, and constructing them in ways that are prepared for leaks (for example, rotating credentials periodically, using ip whitelisting to limit where they can be used, using ACLs on the various services to limit what each credential can do)
Reply all
Reply to author
Forward
0 new messages