Develop Reference

How to encrypt C# configuration file with a predefined key

I had a look on
configSection.SectionInformation.ProtectSection("DataProtectionConfigurationProvider");
but I had two questions:
Is there a way to encrypt config file with a key, because any one can decrypt my file if he knows this method, right?
Does the decryption done automatically when retrieving the connection string at run-time? (in any class, or in data-sets)?
thanks

Yes, Encrypting config file is common. DPAPI way uses symmetric key and therefore, if someone gets the key, he can decrypt.
In my case I used an RSA asymmetric key. That way encryption with public key is performed. Decryption can be performed only with private key protected and held by server in SQL database. On application side, users and application don't need the decrypted secret but need to stay encrypted. Simply, public key is to encrypt and private key is to decrypt. And nobody can easily get the private key.
Furthermore, when it comes to cloud platform like Microsoft Azure, we have to use certificate way which is of also RSA.
My case took almost 1 month to understand the complexity. I completed this task just recently.
The decryption is performed automatically by indicating the thumbprint of private key in the config file.

Where should we store our hashed username\password?

I'm developing a desktop application in C#. In my application user should login before using my application. Now I want to save my username and password securely.
I know about hashing my username\password and adding salt to my password and saving hashed data in a file; but in this case user can replace this file with previous one. And I know we can't prevent this completely but I want make it hard.
One solution is storing hash of file in registry to prevent changing this file; but I think there should be a better solution.
Edit: I don't use database and I'm using windows 7.

You can follow this tutorial: http://msdn.microsoft.com/en-us/library/aa302402.aspx
It uses CryptProtectDataAPI, that provides the following:
The CryptProtectData function performs encryption on the data in a DATA_BLOB structure. Typically, only a user with the same logon credential as the user who encrypted the data can decrypt the data. In addition, the encryption and decryption usually must be done on the same computer.
Check more info here: http://msdn.microsoft.com/en-us/library/windows/desktop/aa380261(v=vs.85).aspx

Encryption in asp.net

I'm creating some encryption in my asp.net webform, using the AES and the built in RijndaelManaged.
I'm wondering what kind of key system I should use. I want the SSN to be encrypted in the database, and to only be decryptable by either the owner of the ssn, or an authorized admin.
What I'm wondering is, if the encryption key is created during the application, then won't I no longer be able to use it once the application is closed? Would I have to store the key in the database? That seems to ruin the point of the encryption. Is there a way to get the same key every time based on perhaps a seed number? Probably not, that seems like it would make it very easy to crack. How do I approach this problem?

In the end, the web application has to be able to read the data and present it to authorized users. If you want more than a single user to access the data, then you need some way to get at the data with a method that is not unique to a specific user. This means having to trust the app to give it to the right person.
What this means is that you should likely just encrypt the value in the database using database level encryption, assuming you're using a database that offers this. Then your app can determine whether or not to show the data to someone, based on whatever authorization mechanism you have in place.

Well, with encryption you will always end up with this problem - what to do with the keys? Key storage and management is its own field.
Some approaches for you to evaluate:
Use DPAPI to encrypt. With DPAPI Windows handles key storage under the credentials of the user your ASP.NET app runs as.
If you are authenticating the user yourself using some secret (a password), you can derive the key from the password and a salt. Remember to re-encrypt the data if the user changes his password! The salt can be stored in cleartext alongside user information. You can derive a cryptographic key from a password doing something like this:
public static KeyIV GetKeyBytesFromPassword(string password, byte[] salt) {
using (var aes = new AesCryptoServiceProvider()) {
using (var deriveBytes = new Rfc2898DeriveBytes(password, salt)) {
var res = new KeyIV {
Key = deriveBytes.GetBytes(aes.KeySize / 8),
IV = deriveBytes.GetBytes(aes.BlockSize / 8)
};
return res;
}
}
}
If you really need top-notch security you can use a Hardware Security Module (HSM), which can be an independent piece of hardware (see for example Thales) or a board for your computer (see for example the IBM 4764 PCI-X Cryptographic Coprocessor or similar). In this case you are using specialized tamper proof hardware which will handle key storage and management for you.
Some database products have what is called Transparent Data Encryption which basically will encrypt a whole database table for you transparently. It's very expensive though. Oracle and SQL Server both have it.

lot has been discussed here: What is the best way to encrypt SSNs in SQL Server 2008? .. I have encrypted password using RinadaelManaged and stored Key and IV along with encrypted password for description. The key and IV is different for every record.
http://msdn.microsoft.com/en-us/library/system.security.cryptography.rijndaelmanaged.aspx

Encrypt from server, decrypt on client (but not encrypt on client)?

Is there a way that my server can provide an encrypted string that can be decrypted on the client, but NOT re-encrypted on the client? I know this seems kind of backwards... here's what my need is.
I have a software key that needs to be activated against our remote server. The server needs to provide something back to the client that says "You are active" and contain info such as a date that it's valid until, how many licenses, etc. However, I need to prevent it from being easily tampered with to increase license count or the dates (i.e, re-encrypt the value with a new date using a key found in the de-compiled binary or w/e).
Is such a thing possible using public/private keys? Or perhaps hashes?
EDIT
Alternatively, can the server provide a hash that the client can validate is really from the server without giving the client the ability to spoof or generate a hash on it's own?
Thanks in advance.

Public/private key encryption should do what you need. Hashes are one way functions; a good hash function will make it impossible to retrieve the original value.
In this case, the server has a public/private key pair and the client has a public/private key pair. The server's public key is embedded into the client, and the server has the client's public key as well. The server can now encrypt your payload using it's private key and the client's public key. When the client wants to decrypt the payload, it uses it's private key and the server's public key. The client cannot re-encrypt the data without access to the server's private key.
http://en.wikipedia.org/wiki/Public-key_cryptography - for an explanation of how it all works
http://msdn.microsoft.com/en-us/library/e970bs09.aspx - as a starting point for .Net classes to make it easier

Sure. Use an asymmetric-key algorithm like RSA. Both keys are required to go from cleartext to cleartext; one will encrypt, the other will decrypt. You cannot use the same key you encrypted with to decrypt, and vice-versa. So, the client could not get ciphertext, decrypt it, then use any of the information it has to come up with the same ciphertext.
HOWEVER, asymmetric-key algorithms do not differentiate between the encryption and decryption keys until one is used to encrypt. They only require that the other key is used to decrypt a message encrypted by the first. So, theoretically, your client could "re-encrypt" a message using its "decryption" key that would be decrypt-able by the server using its "encryption key". I don't know of an algorithm that would disallow this; you'd simply have to build it into your communication library by omitting any way to use the decryption key for anything but decrypting.

How to Manage Key in a Symmetric Algorithm

I am doing an AES encryption in my C# code, using a key which is generated using PasswordDerivedKey function by passing a password and a salt of 12 byte. I have implemented the logic in my application code and the "password" is the username of the logged in user and the salt is a static byte aray.
What is the best way of storing the password and the salt, as someone can easliy determine the salt (by reflecting my code) and the username of a person.
What are the alternatives I can adopt to store the password and the salt in a secure way. I dont think storing them in my application code is the best way of doing it.
Edit: By password, i meant the passkey used in the PBKDF function (to derive an encryption key) and its not the password provided by the user. I am using Windows Authentication

Why would you need to store password if it is merely an encrypted version of the windows username?
Anytime you need to encrypt/decrypt you know name of user thus can generate key dynamically.
Salt should never be considered a secure asset. No need to hide it. You should always assume attacker knows the salt. Salt is simply a mechanism to defeat rainbow tables and other fast lookups.
Is there something I am not seeing?
On Edit
The issue is misstated in the question. The issue isn't what/how should be stored. That answer is simple. Never store any of the cryptographic data (except salt).
The current implementation creates an encryption key from the username of logged in user. The problem is that is insecure as determining username is rather easy. To get around this one would need to either:
a) accept the implementation is insecure to someone willing to decompile app.
b) ... not a good idea ... hash can change based on groups/roles
c) use a unique secret password for each user.
c is the only secure implementation however it requires prompting the user for a passphrase when encrypting or decrypting.

Against whom must be the data be secure? If the currently logged in user is allowed access to the data, but other Windows Authentication users are not allowed access, what you really want is for the data to be encrypted for the particular logged in user. If you have access rights to configure the PC, you might be able to create an Encrypted folder with permissions only for the desired user. This is not 100% secure (you can still intercept the data at various places if you have root access), but your only other reasonable alternative is to add another password.
Alternately, you can simply accept that the protection is weak and provide minimal obfuscation. It depends on the value of the data and the capabilities of your possible attackers. If your attackers have sufficient privileges to Reflect over your assembly on the actual machine, then it's highly likely that they're also Administrator, which means you're pretty much screwed no matter what you do. There are tools that can connect to a running process and monitor its memory, which means they could simply wait until you've decrypted the data and read it from memory.

Best way to keep the salt is to generate it on runtime and keep it per session along with other user stuff such as username and password:
use signs in and provide username/password
hash with stored salt and check against password hash
create new salt and store it along with the hash
Symmetric encryption (or even asymmetric) is not at all recommended for passwords. You not to hash it which is just one-way.

I added this as an second answer because it is a different solution. I just thought of it tonight because I am working with this class (trying to reverse engineer kindle encryption).
You may want to look into the Protected Data Class
http://msdn.microsoft.com/en-us/library/2c64xe0y(v=VS.90).aspx
This is a class that allows you to store data in the windows cryptographic store.
By using the Protect and Unprotect function you can pass data into and pull data from the cryptographic store.
If you didn't want to force the user to create (and remember) an encryption key you could.
1) Check to see if current user has encryption key in the store.
1a) If not then create a random encryption key
2) Use key to encrypt file and store
3) To decrypt retrieve key from store.
4) Another user may be able to access the file but will be unable to get a copy of the key from the store.
A couple caveats. Only the windows user who stored the key can retreive the key. However this can be bypassed depending on environment. If the user has no windows password (or weak windows password) anyone w/ access to machine can run as the user and windows will gladly hand over the key. In a domain environment anyone (admin) who can impersonate the user and modify password can access they key. If user's windows profile is trashed so is the only copy of your encryption key.