The second big security area in the .NET framework after Authentication and Authorisation is cryptography. Again, the framework contains a lot of powerful functionality, and again there is an application block that makes it all a bit easier to use.
The classes and namespaces that deal with cryptography cover three key areas:
- Symmetric Key Encryption/Decryption
- Asymmetric Key Encryption/Decryption (Public Key Cryptography)
I don't want to get bogged down in the detail of these three topics (there's plenty of resources elsewhere on the web for that), but just highlight where, in a VB application, these technologies may be useful.
Symmetric Key Cryptography
This kind of encryption algorithm uses a single shared key that can be used to both encrypt and decrypt data. These algorithms are also relatively fast. The fundamental weakness of this approach is that both the encrypting and decrypting parties need to know the same key, and to make sure that no one else has access to the key. The framework includes implementations of a number of well known algorithms of this type such as DES, TripleDES and AES.
Where this is useful in a VB application is where the application wants to store it's own data securely - perhaps as a file, or a section of a configuration file, or a registry key. A couple of useful classes are ProtectedMemory and ProtectedData which look after all the key management issues for you.
Asymmetric Key Cryptography
While these algorithms are slower than the symmetric ones, they don't rely on a single shared key. Instead, they use a pair of keys, on public and one private, where data encrypted with one key can only be decrypted using the other. These algorithms, as well as providing encryption, also form the basis of digital signatures.
This approach is appropriate when exchanging data securely between users or systems. The HTTPS protocol is an example of the use of this approach.
You can think of hashing as a one way system, you can encrypt (hash) a piece of data to generate a unique hash code, but you can't work out from a hash code what the original piece of data was. What's the use of this then? An authentication system that verifies passwords is a good example:
You need to check that a user password is correct when they log on - so you need to keep a record of passwords somewhere and the password needs to be transmitted over the network from the client application for checking. This gives you two security loopholes - passwords stored in a database and passwords flying around on the network. If you store a hash of the password in the database, and the client application sends a hashed version of the password for checking we've avoided both problems! We just need to compare hash values to check if the password is correct.
The framework includes implementations of a number of hashing algorithms including SHA and MD5.