The answer mainly depends on the architecture of the application. Will it be used by many different users that aren't on the same network, or within a local Intranet? What resources will be available to your application to hold that data? You'll have to take those considerations into account in order to determine what is the best option for persisting the data. Regardless of your choice, you are going to need persistent storage of some format to hold the data. Whatever option you decide to go with make sure you store a hash of password values. Personally, I use the .NET MD5 implementation (MD5CryptoServiceProvider) to hash passwords, but the .NET Framework includes a number of hash algorithm implementations. In practice, you should persist the hash rather than the actual password and when authenticating, you take the hash of whatever the user enters and compare it against the hash that was persisted; if it matches then they entered the correct password. It's not mathematically possible to get the original value from a hash. If you need to secure other data you can use some of the other .NET Cryptography classes to encrypt the data. Either way a number of Symmetric encryption algorithms (aka Secret Key) are included in the .NET framework (the .NET Rijndael implementation is what I usually use). You'll generally need to create your own binary Key and Initialization Vector (IV, for short and commonly referred to as the 'Salt'). The Key and IV lengths vary somewhat for the different algorithms so you'll need to read up on that as you decide on an encryption scheme that works for you. Symmetric encryption requires the same Key and IV be used for decryption as was used to encrypt the data, so it's common to choose a Key and IV for your application that are pretty much static. If you need more flexibility than that you can look into the Asymmetric encryption (aka Public key/Private key) but those generally require more complexity, however there are certainly situations that call for it.
Keep It Simple Stupid! (KISS)