I'd like to securely store an encryption key somewhere in an SQL Server database that is only readable by internal functions and SP's. Is there a way to achieve this without it being visible to any user accessing the database (no matter what the role).
What i'm trying to do:
I need to have a simple sort of "license key" as a new column for my individual users. The plan is to hash their usernames using a client-specific key (which is a concatenation of the above mentioned key and a product key).
A function would be created that:
Takes the product half-key as a parameter
Fetches the secure client half-key in the database
Combines them together into a complete client-specific key
Uses this key to hash the username into a final output
Ultimately what i'm trying to do is give specific database users "licence keys". Since the customer has access to the database, i don't want them to be able to do add licence keys to other users as well. If the above doesn't work, i'm also open to other suggestions to achieve this.
Related
I am new on bigquery my task is to encrypt only email column in bigquery. I can not use udf there so with query itself i need to implement that but i am not getting any buildin function for doing the same.
You could encrypt the email column on the client before storing it in BigQuery. You can then keep your key safely stored elsewhere and never expose plain-text email in the database. This still allows you to look up rows with a particular email address, you just have to send the encrypted blob as part of any query that you want to run.
Note that this still allows someone with access to your database to know which rows had the same email address. This may or may not be an issue for you (as I don't know why you need to encrypt the addresses).
If you don't need to be able to reverse the stored email addresses, but just want to be able to compare them, consider storing hashes instead -- you can use the SHA256() function to do this. If you want to make this even more difficult to reverse with a pre-computed lookup table, you might consider salting the hashes as well.
See:
https://en.wikipedia.org/wiki/Salt_(cryptography)
There is currently no way to encrypt your database (or individual columns) with a user-specified key, but you could open a feature request for such a thing on the BigQuery public issue tracker.
I am working on company's confidential data. Is there any way we can hide this data from back-end and still can see from front-end application? User will have access to database and tables but can't see the data.
Some hints:
Handle permissions by restricting the access to the sensitive data to a single user.
Add encryption.
Note that some information, such as the passwords of the users, should be salted and hashed, instead of being simply encrypted. The difference is that en encrypted piece of data can be decrypted using a private key or a password. Data which is salted and hashed cannot be decrypted (while is still sensitive to brute force attacks).
Handle permissions and add encryption.
Remove the data from the database machine and move it to a safer place (for example if the SQL server is collocated for several projects and is accessed by many developers, while the app server is only accessed by a few trusted persons, moving the data to the app server might improve the security a little). This shouldn't prevent you to add permissions and encryption.
Don't store the data in the first place.
For example, instead of storing passwords of the users, you may use OpenID, and let Google and other companies deal with security. Instead of storing credit card information of your customers, you can use services of other companies such as PayPal in order to be sure that you never get credit card numbers in the first place.
Yes, there are many tips to hide data in SQL Server.
One of them is Database Views.
Create different views on different table base on your limited column of table and assign only select permission on that particular views.
Don’t provide a any grant on any tables.
I hope, this is helpful for you.
You can encode the sensitive data, so it will be stored in the database in an encoded form and being decoded upon retrieval.
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.
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
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.