I have some data in my user database that I would prefer to be encrypted. Most of the data will need to be decrypted when requested, but there are also passwords that can stay encrypted (in the old days we would use pwdcompare but I believe this is obsolete now).
I have followed the steps here, so I have now successfully encrypted my data.
What I don't understand is the correct way to open the master key at runtime, in order to encrypt/decrypt data. If I want to use stored procedures to retrieve encrypted data, how do I go about opening the master key? Do I pass in the master key's password using a stored proc parameter?
As I have understood, you should create master key once (you can do this during installation process) and this is the first and last time password is needed. After that, using master key create encryption key (symmetric or asymmetric) without a password and use it to encrypt/decrypt your data. You don't have to give a password for it, all you need is use your encryption key and have CONTROL permission on it. The only issue is that your DBA can have it too :)
See this article: Using Asymmetric Encryption and Digital Signatures in a SQL Server 2005 Database
Related
I don't know about encryption keys much. But I got a project where I need to transfer SQL Server database from one computer to another. I can't connect it online as the database needs to be local only. Also I generated create scripts of complete database using SSMS. But create scripts of asymmetric keys are not generated. I want to know that if I create asymmetric key with the password given by the project owner, will old data still be validated from it? I mean does asymmetric key is system independent?
First, I would recommend getting an overview on column level encryption through a book, video, technical session during a SQL Saturday or other means. Even though I am going to provide the solution, you need a solid understanding of how the encryption system works so that you will understand how to avoid losing encrypted data by making a mistake. That said, the solution is to backup the database, then backup the Database Master Key providing a password to encrypt the key in the file specified. Migrate the files to the destination server then restore the database and restore the Database Master Key using the password previously provided. This will complete the encryption hierarchy. Since all database keys, including asymmetric and symmetric keys, are backed up with the database, they will be transferred to the destination server in the backup file.
I have been asked to produce a system that is the middle point in a bunch of systems that handles payments to a small group or people. For it I will be required to store the peoples bank details.
What is a good way of encrypting this data to be stored within the database and then decrypt the data when required to pass onto the next system?
For this project I need to use Microsoft SQL Server.
If you're using SQL Server 2008 the you can use the built in transparent data encryption (TDE). Check out and see if it fits the bill.
I encrypt the values at application level along with an encryption key, and then pass this encrypted value to SQL Server.
When decrypting I pass the encrypted values to the application, and decrypt before using them within the application.
I prefer this method as it keeps the encryption method seperate from SQL Server.
Otherwise, if a user was to hack into your SQL Server, including your encrypted values, and you were using a T-SQL User Defined Function, they would have the ability to decrypt the values, making the encryption worthless.
I've got a problem scenario w.r.t data cyphering or encryption/decryption in SQL Server 2005.
Scenario:
There is a specific table in the database
The table has a column, let's say "Credit Card"
The requirements is that the content or data in this column should be encrypted
Required (plausible) solution:
Data that is inserted in this table's column should be encrypted, i.e., is unreadable to people running direct queries on the database and/or table; or only by using a specific decryption logic, which requires a KEY of some sort
While reading the data in any application, the method-of-decryption should be easy, maybe KEY based
The process or methodology should be easy to use
But difficult to break
Please give me some suggestions or solution in this regards.
Thank you.
you encrypt data with a symmetric key
you encrypt the symmetric key with a certificate
you encrypt the certificate with a password
periodically you generate a new symmetric key to encrypt new data
priodically you rotate the certificate and re-encrypt the symmetric keys with the new certifictae, dropping the old certificate
Application requests password from the user and opens the certificate in the session. It then uses DECRYPTKEYBYAUTOCERT to encrypt the data. This is the general industry standard. It protects data rest and guards against accidental media loss as well as access from a person not knowing the password.
You will find a lot of bad advise ont his topic. Any scheme that is 'automated' and does not requests the user for a a decryption password is wrong. If you want 'automated' encryption or decryption you should look into Transparent Data Encryption which protects agains accidental media loss. TDE does not protect against other users browsing the data, if they have access priviledges.
Try looking into the DecryptByKey function.
This is one for all you security gurus out there.
I have a SQL Server 2005 database with a database master key, which is encrypted with a very strong password using the server key, which in turn is encrypted using the service account credentials in the Windows Data Protection layer.
I have a certificate which is encrypted using the database master key.
I have a symmetric key using AES256 which is encrypted using the certificate, and I am using the symmetric key to encrypt and decrypt confidential fields in the database.
What does someone need to crack the encrypted fields in the database? My only assumption is that brute force can't be employed due to the strength of the symmetric encryption algorithm, and the symmetric key itself is protected by 4 additional layers of encryption:
Windows DPAPI -> Server -> Database -> Certificate -> Symmetric Key
which seems pretty tight to me.
Let's not include the obvious answer of "get the system administrator's username and password by drugging and sleeping with him", which is definitely relevant but not what I'm after.
Here is a potential attack. It assumes you already have a way to run arbitrary code as the service account. For example, you might exercise a remote code execution bug to get. Having done so, it is relatively trivial to use DPAPI to get the server key. Having done that, you can get the master database key, although you'd need some brute force method to break the password.
It sounds like it would be pretty difficult to do, depending on the strength of the password maybe impossible. Is the service account low or high privileged? If it is an admin account, you could maybe use that (assuming it was broken) to install a keylogger to get the password.
K. Brian Kelley specializes in SQL Server security, and he's written several good articles about how encryption gets bypassed in SQL Server environments, like these:
http://www.sqlservercentral.com/blogs/brian_kelley/archive/2009/02/20/you-must-trust-someone.aspx
http://www.sqlservercentral.com/blogs/brian_kelley/archive/2009/02/27/a-security-control-inconsistently-applied-is-not-a-control.aspx
http://www.sqlservercentral.com/blogs/brian_kelley/archive/2009/02/20/you-must-trust-your-dbas.aspx
If you're really into security, I'd highly recommend subscribing to his blog. He's also available on Twitter at http://twitter.com/kbriankelley.
Somewhere in memory this un-encrypted key is stored to be able to encrypt against it, is there a way for an attacker to gain access to SYSTEM level to then be able to basically scan memory, or attach an extra thread to MSSQL.
Also, these encrypted fields, are they used in any front-end applications? Are they visible when you SELECT * FROM table? For example, you can have as much security on your database and fields as you want but if someone is able to use an SQL injection to write their own SQL queries and thus view the value of the fields you are still back at square one.
Assuming no human-engineering attacks are possible I would try to attach a debugger to the program reading it, obtain a snapshot of it's memory and try every set of bytes in a brute-force attack.
Even if I couldn't obtain the memory image I would try the same thing with the source file in case the key is in there.
Realistically, you have to ensure the key never appears intact anywhere to defeat such attacks.
I have an existing SQL Server 2005 database that contains data encrypted using a Symmetric key. The symmetric key is opened using a password. I am working on an upgrade to the front end applications that use this database, which include adding dozens of new tables, stored procedures, UDFs, etc. and dozens of modifications to existing tables and database objects. To that end I am making a copy of the existing development database, so that the current system can be independently supported, maintained, and updated while new development takes place.
What is a good way to go about copying the database? Normally, I'd take a backup of the existing database, and then restore it to the new database. However, will this be feasible given the encrypted data? Will I still be able to encrypt and more importantly decrypt data in the new database using the existing symmetric key and password?
Might I instead want to use DTS to transfer the existing schema only. Create a new symmetric key/password in the new database. Then write ad hoc queries to transfer the data, decrypting using existing key/password, and encrypting using new key/password in new database.
I guess at the heart of this is, are symmetric keys good for encrypting/decrypting data in a single database or in many databases on the same server?
The Symmetric keys you are referring to are Database Master Keys (DMKs). They are held at the Database level, so a backup/restore to another SQL server should work OK (with the caveat of differing service accounts, which this thread alludes to)
Before you do anything make sure you have a backup of your keys (presumably you've already done this):
USE myDB
GO
BACKUP MASTER KEY TO FILE = 'path_to_file'
ENCRYPTION BY PASSWORD = 'password'
GO
From this article:
When you create a Database Master Key,
a copy is encrypted with the supplied
password and stored in the current
database. A copy is also encrypted
with the Service Master Key and stored
in the master database. The copy of
the DMK allows the server to
automatically decrypt the DMK, a
feature known as "automatic key
management." Without automatic key
management, you must use the OPEN
MASTER KEY statement and supply a
password every time you wish to
encrypt and/or decrypt data using
certificates and keys that rely on the
DMK for security. With automatic key
management, the OPEN MASTER KEY
statement and password are not
required.