I am using MS SQL Server compact edition within a project. The client has requested for all data contained in the database to be encrypted. The key for the encryption may be installation-specific or even a global key for all installations, it is more intended as minimal barrier for people that have taken a copy of the sdf and try to read the data contained in it.
Is there a setting within SQL Server CE that enables encryption on the DB or is there no mechanism like that and the application has to take care of encryption of the data on its own?
Thx!
i find that (source)
Use the SQL Server Compact File Encryption Within the SQL Server
Compact Connection String you can tell the engine to encrypt the
datafile with a password. By simply specifying a password, the
database is automatically encrypted. We used to support an encrypt =
true name/value pair, but it was sort of silly to have a password
without encryption, and encryption without a password is about as
useful as putting a lock on a door but leaving the key in the lock (on
the outside of the door). So, we no longer use this name/value pair
and will likely throw an error in a future release if the engine sees
it. Today Compact just ignores it.
To turn on Encryption, simply set the Password like the following:
Data Source=|DataDirectory|\Localdatabase.sdf;Password=Foo
Related
I have been tasked with finding a solution to encrypting DB2 table data while at rest (DAR)
My environments:
Note: all environments using SSL to encrypt DB2 data while in transit
1) I have two z/os environments with two tables in scope. My client request a specific column have its data encrypted while at reset.
-- One of the tables utilizes SQL replication and is not only dependent on two z/os environments but two DB2 z/linux based db2 instances and tables
2) DB2 LUW is deprecating DB2 table column encryption and advocating the use of Native database encryption.
Does anyone have any suggestions on how to encrypt DB2 data while at rest that is compatible between z/os and luw (In my case I am using z/linux). Ideally any solution would be transparent to applications.
As mentioned in comments, Db2 encryption is transparent to applications, including yours. Once data leaves "rest" (storage) it is decrypted, then re-encrypted when it comes to "rest" again.
Encryption implementation details are platform-specific. In your case the entire databases on z/Linux must be encrypted to protect your single column. Given that you are using SQL replication, no other changes are necessary.
You may look at the Row and column access control (RCAC) feature.
You may encrypt the column values for users which don't have an appropriate authorization, but allow to see actual values for others (including the replication user).
But column data on disk and in a backup are not encrypted with RCAC.
Use native encryption to encrypt entore database on disk. You don't have an ability to use native encryption just for particular columns and tables.
I agree with Mustaccio and Mark. Yet another possible choice is federation, i.e. you don't use replication at all but rather leave the data in their respective places and let the databases sort out data access for consumers, e.g. via DRDA or Data Virtualization Manager for z/OS.
I have a Pascal Script code in Inno Setup script to get the DBURI from user inputs, and save it to file, so the application can read this string and connect to database.
DBURI :=
'Databaseserver//'+DatabaseUserName+':'+DatabasePassword+'#'+
Host+':'+Port+'/'+DatabaseName+'"';
SaveStringToFile(dbconf, DBURI, True);
It works perfectly. But the problem the string not encrypted, and anyone who browses to the file can get the database password. I want to use an encryption method with a predefined key within Pascal Script code, and write the output value (encrypted string) to the file.
So, I can include the encryption method and key in my application code to decrypt value and start using DBURI string.
So, my question how to use an encryption method (anyone) with a predefined key within Pascal Script code?
I found many articles in Pascal documentations but I didn't know how to use?
Your question is rather broad, so I will answer it broadly too.
Some facts:
In general, there's no really safe way to encrypt data (the DB password), so that they can be used automatically. Even if you use an encryption key. It's not that difficult to retrieve the key from the binaries. Particularly Inno Setup code is easy to disassemble. See Disassembling strings from Inno Setup [Code]. Though as you seem to be willing to accept even plain key-less Base64 encoding, your security needs are probably not that high.
There's no support for encryption in Inno Setup (or its Pascal Script code). You have to use external functions or applications. Though some simple encoding (not encryption), like Base64, can be implemented in Pascal Script code.
What you can do:
If you will be decrypting the data using the same local account as encrypting them (the same user installs and uses the software), use Windows CryptoAPI. This is really secure, as it uses a key that associated with the local account and protected by accounts password. But that limits the use, as mentioned.
See Simple AES encryption using WinAPI.
I didn't try to implement this in Pascal Script, but I believe it should be possible.
I believe you can use CryptoAPI even with a known key (shared between the installer and the application), but I do not know details.
Another way to encrypt data with a known key is by invoking an external application for that. You can use PowerShell and .NET classes for implementing encryption. Or you can add a hidden feature to your own application, that you will call from Inno Setup to encrypt and store the data.
If you are happy with Base64 (or maybe hex) encoding, see:
Encode string to Base64 in Inno Setup (Unicode Version of Inno Setup)
Can anyone explain how this string has likely been encrypted at all?
AES256:29://(Hex://5B18C3AD8CFR4D38)
I've never seen an encryption has like this before in my life. Would it be possible to replicate with PHP? (Providing I can get what salts etc may have been used etc).
This is for a migration of data from one website to another - currently this data is stored in a MSSQL DB but will be used in MySQL if PHP can handle the encryption.
It appears to be part of a 256bit hash with some metadata around it. I'm not familiar with the php libraries for encryption but know that you can create a 256bit sha with php and there should be a toHex() method.
To check a password, encrypt the users entry with sha256 and check its hex value against the one stored. Have you checked to see if its the first 1/4 of a sha? Maybe they just truncate for lack of security?
If I had the guess, the 29 is probably userid, but could be a salt or something.
We're designing a database system to store encrypted strings of information, with encryption and decryption performed client side using public-key cryptography.
If the key was ever changed though, this would necessitate reencrypting all the records client side, which is very impractical.
Is there any way this could be performed server side without exposing either the original (old) decryption key, or the message text?
I guess what I'm after is an associative cipher, something like this:
T( Eo(m) ) = En( Do(Eo(m) ))
where Eo(m) is the cipher text, Eo/Do the old pub/priv key pair, En the new pub key, m the message text and T the magical reencryption function.
Edit: T is calculated clientside and then sent to the server to be used.
You can't retroactively disable the old key anyway. Anyone who has access to the old data and the old key can decrypt the data no matter what you do.
I would suggest simply keeping a ring of keys. Add the new key to the ring and mark it active. Mark the old key expired. Code the client so that if it finds any data that's encrypted with an expired key, it re-encrypts it with the active key. (Or don't. What's needed depends on details of your implementation requirements.)
If desired, after a period of time, you can sweep for any data still encrypted with the old key and re-encrypt it.
You can't eliminate the exposure of the old key anyway, ever -- anyone who can find a backup or copy of data encrypted with the old key can decrypt it if they have the old key. Encryption keys must be protected forever or you get the fiasco that released the Wikileaks diplomatic cables to the public with the names of informants intact.
Think about your security perimeters. If you're worried about the server being compromised, consider building a harder-to-break subsystem which carried out the transcryption. You could do this with a non-network-attached server which was contacted only over a very tightly verified link protocol (over, say, a serial line), or a dedicated hardware security module. However, if you do something like this, you must think about how your keys are protected; if an attacker could steal the transient plaintext from your server, could they also steal the keys protecting it?
A few years ago, when first being introduced to ASP.net and the .NET Framework, I built a very simple online file storage system.
This system used Rijndael encryption for storing the files encrypted on the server's hard drive, and an HttpHandler to decrypt and send those files to the client.
Being one of my first project with ASP.net and databases, not understanding much about how the whole thing works (as well as falling to the same trap described by Jeff Atwood on this subject), I decided to store freshly generated keys and IVs together with each file entry in the database.
To make things a bit clearer, encryption was only to protect files from direct access to the server, and keys were not generated by user-entered passwords.
My question is, assuming I don't want to keep one key for all files, how should I store encryption keys for best security? What is considered best practice? (i.e: On a different server, on a plain-text file, encrypted).
Also, what is the initialization vector used for in this type of encryption algorithm? Should it be constant in a system?
Keys should be protected and kept secret, simple as that. The implementation is not. Key Management Systems get sold for large amounts of money by trusted vendors because solving the problem is hard.
You certainly don't want to use the same key for each user, the more a key is used the "easier" it comes to break it, or at least have some information leaks. AES is a block cipher, it splits the data into blocks and feeds the results of the last block encryption into the next block. An initialization vector is the initial feed into the algorithm, because at the starting point there is nothing to start with. Using random IVs with the same key lowers the risk of information leaks - it should be different for every single piece of data encrypted.
How you store the keys depends on how your system is architected. I've just finished a KMS where the keys are kept away from the main system and functions to encrypt and decrypt are exposed via WCF. You send in plain text and get a reference to a key and the ciphered text back - that way the KMS is responsible for all cryptography in the system. This may be overkill in your case. If the user enters a password into your system then you could use that to generate a key pair. This keypair could then be used to encrypt a key store for that user - XML, SQL, whatever, and used to decrypt each key which is used to protect data.
Without knowing more about how your system is configured, or it's purpose it's hard to recommend anything other than "Keys must be protected, keys and IVs must not be reused."
There's a very good article on this one at http://web.archive.org/web/20121017062956/http://www.di-mgt.com.au/cryptoCreditcard.html which covers the both the IV and salting issues and the problems with ECB referred to above.
It still doesn't quite cover "where do I store the key", admittedly, but after reading and digesting it, it won't be a huge leap to a solution hopefully....
As a pretty good soltution, you could store your Key/IV pair in a table:
ID Key IV
skjsh-38798-1298-hjj FHDJK398720== HFkjdf87923==
When you save an encrypted value, save the ID and a random Salt value along with it.
Then, when you need to decrypt the value, lookup the key/iv pair using the id and the salt stored with the data.
You'd want to make sure you have a good security model around the key storage. If you went with SQL server, don't grant SELECT rights to the user that accesses the database from the application. You wouldn't want to give someone access to the whole table.
What if, you simply just generated a key for each user, then encrypted it with a "master key"? Then, make sure to have random ivs and as long as you keep the master key secret, no one should be able to make much use of any amount of keys. Of course, the encryption and decryption functions would have to be server-side, as well as the master key not being exposed at all, not even to the rest of the server. This would be a decent way to go about it, but obviously, there are some issues, namely, if you have stored your master key unsafely, well there goes your security. Of course, you could encrypt the master key, but then your just kicking the can down the road. Maybe, you could have an AES key, encrypted with a RSA key, and the RSA key is then secured by a secret passprase. This would mitigate the problem, as if you have a decent sized RSA key, you should be good, and then you could expose the encryption functions to the client (though still probably shouldn't) and since the key encryption uses a public key, you can have that taken. For added security, you could cycle the RSA key every few months or even weeks if need be. These are just a few ideas, and I know that it isn't bulletproof, but is more secure than just stuffing it in a sql database.