My requirement is to do column level encryption.
Tried below option
TDE - data is not encrypted to one who has access to database. Please correct me if I'm wrong.
DBMS_CRYPTO package, this works but client wants to store encryption key outside Oracle database.
I'm not able to find solution for storing key outside database.
Any help on this is highly appreciated.
Perhaps two different things here.
To do TDE at column level already uses an external key store, namely a wallet. The location is specified by ENCRYPTION_WALLET_LOCATION in your sqlnet.ora file, and you'd open the wallet when the database starts, eg
ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "thePasswordIchose";
Conversely, if you are looking at doing some "home grown" encryption of data using DBMS_CRYPTO, then key management also becomes your own responsibility. You could store the key however/wherever you like, but its your job then to manage it and pass it securely into the DBMS_CRYPTO routines
Related
Oracle 11.2.0.4.0 enterprise.
We are hosting multiple customers data in single schema, a new customer wants his data to be secure with his unique encryption key.
Using Transparent Data Encryption (TDE), can we somehow create multiple master encryption keys within single schema?
We can upgrade to Oracle 11.2 for that as well if any workaround available.
Lastly if no such thing possible as 'multiple master encryption keys within single schema' then what other approach suits best for us, should we create separate database in same instance or should we commission separate vm-machine for this new customer.
Wishes
For encryption purposes of some columns I wrote UDFs. I then realized that passing the keys through SQL is nonsense as the SYSDBA can trace SQL and look into session environment. And he exactly is the one, who should not access the data.
Full database encryption is no option for me due to the fact that most of the data does not need to be encrypted and speed is an important thing.
My approach is to transfer the key from client to server with ECC public/private key technique. This is easy to accomplish but where can I store the key for a session within my UDF? Can I get hold of some kind of information about the session of the caller within my UDF?
We are cleaning up servers for a customer and have stumbled upon an old application using an H2 database. While the accessing applications have credentials in their configuration files, none of them seem to work.
Even the "sa" user access is not known. As far as I can see, the password for "sa" defaults to an empty string, but access with "sa"/"" is denied (Wrong user name or password [28000-182] 28000/28000 (Help)).
As said, the database is not encrypted. Looking at the file, I can see the SQL statements for the tables, even some table contents.
Is there any way to gain access to that database? As far as my searches have shown it's only possible using the "sa" user. I'm looking for something along the lines of "--skip-grant-tables" from MySQL.
The easiest solution is probably:
Try to login to the database without password. This will fail (wrong user name or password), but it will run transaction log recovery so that the database is in a consistent state.
Then, use the Recover tool (org.h2.tools.Recover) to generate a SQL script.
Edit the script: Change the password for the default user.
Run the script. That way you get a new database.
I looking for a tool can migrate my users from AspNetSqlMembershipProvider user to WebMatrix.WebData.WebSecurity. I want to host my site on Azure and have a lot of trouble with the AspNet stored procedure.
It seem easy to export data from one table to another but not with the password. How can I do the task It must be transparent for my end users.
Thanks!
If the password is the only obstacle, don't worry. In fact, we cannot and do not need to know the passwords themselves.
In most of the system, the passwords are encoded and saved in a table. In asp.net mvc4 SimpleMembershipProvider, the table is called webpages_membership. In this table, 2 columns are the keys: Password and PasswordSalt. I know nothing about AspNetSqlMembershipProvider, but I think there must be a corresponding table which contains the 2 columns with similar names. Migrating data in these 2 columns should make it work.
I suggest to do it as following:
Create a new account in the old system with a password.
Create a new account in the new system with a different password.
Overwrite the Password/PasswordSalt in the new system by those in the old system.
Try to log in new system with password of the old system.
If it succeeds, it proves that the two systems are using the same machanism then and you can do the whole migration work.
Detailed algorithm can be found here: http://www.jasypt.org/howtoencryptuserpasswords.html
Does anybody knows how could I make a trigger or anything else to prevent people to connect on my database with any kind of applications besides mine?
Note that the super-old-and-unsecure trigger to block few .exe such TOAD or watever does NOT really works, since you can just rename the EXE to MyApplication.exe.
Hints?
An easier method would be to move the security to a role that can be enabled only by your application - see a previous answer of mine here
WIth this method another application may create a session but has no other privileges since the role is not enabled.
You may wish to consider Oracle's Secure Application Roles -- it won't prevent people from logging into the database through a rogue application, but it can prevent them from accessing tables and packages if the application doesn't set the role using the password that only it knows.
You can find an tutorial on deploying it here, although to secure it, you'd have to create the role with a password, and your application would have to know the password when issuing the SET ROLE rolename IDENTIFIED BY rolepassword; statement.
I don't know that Oracle has any functionality to help with this (I could be wrong though) so the next best thing might be to write a small server app that lets you have much better control over the login process and acts as the middle-man between the client apps and the database server. That way, all connections to the database come through your server app, and you can control how your server identifies which client app is legit. This will add a bit of complexity to the system though.
If you don't trust the program name in v$session then the only options that come to mind are to have your application encode the password, so that what they type in isn't actually what's used to connect to the DB; or have your app log in with a private username/password and authenticate users against your own users table instead of having Oracle user accounts for them. Both options make management of accounts more complicated though.
When your application logs on, you call a stored procedure that associates the current oracle session as a "trusted" session. Do this by creating a trusted sessions table with a field for sessionID and trusted bit (and optionally a random hash to prevent user tampering).
Create a system wide trigger, that checks the your current session id (and random hash) to detect if it is trusted. If the session doesn't exist in the table, you don't allow the query, and log off the user.
You should also setup a shutdown trigger to clear the trusted session table on exit.