Assume that app.config is, for whatever reason, not an option.
How is possible to store an encrypted connection string, either in the assembly itself or another app.config like XML file?
(I don't think it matters, but this is for an COM add-in for Excel 2003.)
This can be good application of isolated storage.
http://msdn.microsoft.com/en-us/library/3ak841sy(VS.80).aspx
You can use the classes in the System.Security.Cryptography namespace to
encrypt/decrypt a file. However, you run into another problem, where will
you store the key? If you store it in the assembly, the assembly can be
browsed to find the key and then someone else can use it to decrypt your
data.
do check out
http://www.codeproject.com/KB/security/encryptstrings.aspx
and
http://sharpertutorials.com/simple-string-encryption-and-decryption/
Sounds like a good use for ProtectedData class.
http://msdn.microsoft.com/en-us/library/system.security.cryptography.protecteddata.aspx
Calling Protect and passing in a byte array containing your connection string will return a byte array of encrypted data (which can then be converted to base64 and stored in a local file.
Calling Unprotect and passing in a byte array containing encrypted connection string will return a byte array containing the plaintext connection string. Then simply use Convert to ASCII or UTF-8 etc.
Obviously if the attacker gains access to the user account running the app they will be able to recover the string but it provides a little more security than storing encryption string in assembly (which can allow recovery without gaining access to user account).
Related
I've just started to read about viewstate in asp.net. I know it is serialized data encoded with base64 and I know it can also be encrypted using a key[which is Auto-generated every time if we don't change the default in web.config in case of server farm or etc.]
but my problem is that how this key is shared with the client [so that the client could read it] that ensures the safety of data?
does it have to do anything with HTTPS protocols and shared keys or they are completely something else?
if it is something else, so how the keys are transferred throw the web?
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)
I have an .Net Application and i want to this application which has some features. Depending client's domain and what features he wants i want to provide him a string which he will store it a file and will be accessible from the application.
I will create a second application which will get as parameters the domain and the features and it will produce the string.
Is there any way to encrypt this string with a key and my application (the first one mentioned) to decrypt it?
I have in mind something like private/public key but reversing the logic. I mean, to encrypt the string from my second application wit the private key and the first application to decrypt it with the public key.
The purpose is the customer to not be able to change the string so that to change the available features.
PS i have an idea to use digital signature, but i dont know if i can have the public/private keys stored at xmlstrings. I think i have seen it somewhere (exporting/importing) but i am not sure
Yes, digital signatures are the correct tool to use for this.
Storing the keys is a minor implementation detail. Typically, such keys are natively represented as binary strings, possibly in ASN.1 or a similar encoding. If you need to store the keys in some format that cannot handle arbitrary binary data, you can always e.g. base64-encode them first.
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
I was reading this:
http://msdn.microsoft.com/en-us/library/tswxhw92(VS.80).aspx
The first sentence says: "Asymmetric private keys should never be stored verbatim or in plain text on the local computer."
What's the problem with this? And how does a key container solve it.
The reason I'm asking is that I want to generate an asymmetric key pair. The application I'm writing will encrypt information it sends back to me with the public key. I was thinking of storing the public/private key pair in our source control system so that it gets backed up. Shouldn't I be doing that? If not, how should I store the private key so that it can be reliably backed up?
Thanks.
-scott
Update: Does 'never' in the quoted sentence really mean never. Or does it mean I shouldn't be storing keys to source control unless I'm not prepared to take the risk that a hacker could potentially retrieve the keys from our source control system or from a backup taken from it.
Yes, the "never" in the quoted sentence really does mean never.
If the key is stored in plaintext, then anyone with access to that file can read or duplicate your key, then use it to impersonate you. If you display that file on-screen for whatever reason (looking up the key, open the wrong file, editing other information in the file, etc.), then anyone walking past can see it, potentially memorize it, and use it to impersonate you.
A private crypto key is a non-shared secret. If you don't keep it non-shared and secret, it can't do its job properly.
A common solution is to encrypt private keys in the keychain e.g. by using some password-based encryption scheme.
The private key is needed in order to decrypt bits encrypted with the public key, and vice versa. Since the public key is public by definition, you want to keep its private counterpart secret.
Especially when public key crypto is used for digital signatures, it's important to keep the private key secret. Being able to produce digital signatures that can be verified with your public key essentially proves that whoever made the signature had access to your private key.
If you can guarantee that no one but you, or software you trust, can access files on your computer, you don't need to encrypt your private keys. But these are tough assumptions to make.
Because a malicious user can read your key, if he/she gets a hold of your files. Not sure, what the key container does, but I would guess that it encrypts the keys before writing them to a file.