First let me say that there are only two things required to complete the entire system: download of Oracle 11g Enterprise edition and download of Java Development Kit (JDK) 1.5 or higher. These two downloads are free! All the rest is code that we develop in the book. You will not be burdened by any other application frameworks or ancillary (additional-purchase) applications.
The Final Solution:
Each user has an Oracle account (options are discussed and are possible), identified externally (no password). The user opens a Java application on their computer. The Java application gets the logged-in user ID from NTSystem or UnixSystem (JAAS). Thus begins Single Sign-On. The authenticated user establishes a proxy connection through a centralized access user.
The password for the centralized access user is the only password that is exposed in the application. For this user, we define him on a hardened Oracle database instance (as described in the book). He has very little access - just enough to be an application gatekeeper. His password is embedded in the application in encoded form. Various password encryption / hiding / access methods are discussed in the book, but we resolve to an encoded password that is encoded (encrypted) using an obfuscated Java class.
The access user determines if a 2-factor authentication code was provided, and if not, Oracle sends a valid for 10-minute, 2-factor code to mobile devices (cell phone SMS or pager) and/or e-mail for the authenticated user. Once the code is received, the user submits the code in a second connection, proxied through the access user. If the application, authenticated user, and 10-minute time to live are all acceptable, a series of encrypted Oracle passwords (connection strings) are returned for use in the application.
These passwords are encrypted on disk using DBMS_CRYPTO and a calculated password, specific to the client application. They are decrypted, then reencrypted using session-specific encryption for the current user / application. The session-specific encryption uses random encryption parameters like this: First a public / private RSA key pair is generated and the artifacts of the public key are submitted to Oracle. The Oracle instance generates a DES shared password key using random algorithm parameters (respect the power of random) and transmits the parameters to the client application -- the DES key parameters are encrypted with the RSA public key. Those passwords (connection strings) that Oracle returns to the client application are encrypted with the DES key for decryption as needed.
So now the application is free to begin using sensitive Oracle data. One of the encrypted connection strings is decrypted just-in-time, and the authenticated user is validated as a user of that Oracle connection through a secure application procedure. The user must be granted access to proxy through the Oracle user and must be granted the application role required for the connection. It is all very complex, and this brief summary is insufficient (so buy the book, please).
When we connected with this new encrypted connection string, and the user was validated for access, a new set of session-specific RSA and DES keys was generated. All sensitive data transferred for use in the application is transferred in encrypted form. We primarily use stored procedures that return result sets (cursors) for queries and stored procedures for data updates.
In the last chapter, I provide a GUI interface for bootstrapping the entire security system and then managing users, access, administration, applications and connection strings. If you'd rather build it than buy it, you can have Expert Security using this book. Or if you just want to learn secure programming approaches and the technologies used in commercial products, then this is a good way to get that insight. There is also a Supplement with the source code that provides some further insights and scenarios.
No comments:
Post a Comment