Security

Encrypting The “web.config” File of an Azure Cloud Service

Standard

The web.config file contains the configuration options for a web service, some of which could contain sensitive information that you don’t want to be kept in plain text. For example, it is very likely that you’ll connect to a database in your web service, and the connection string you use will be kept in the web.config file. The connection string includes the username and password used in the database server, so if you plan to keep your web service in a 3rd party server or if someone that you don’t want to learn the database credentials needs to work on the source code, you could add an extra layer of security by encrypting this data.

<connectionStrings>
  <add name="DatabaseConnectionString" connectionString="Data Source=blablabla.database.windows.net;Initial Catalog=BlaBlaDB;User ID=yourusername;Password=yourpassword"
    providerName="System.Data.SqlClient" />
</connectionStrings>

.NET Framework provides a feature called “protected configuration” which prevents our data from being shown like in the code above, by encrpyting the configuration data using DpapiProtectedConfigurationProvider or RsaProtectedConfigurationProvider classes. However, both of these two encryption methods need to be applied on the server that hosts the web service, because the encrpytion process uses a machine-specific key. Since we can’t do this on Azure… what can we do to encrypt the web.config of our cloud services?

Well, if we want to encrpyt our web.config files in Azure cloud services, we need to use a special “protected configuration provider”. In this article, we’ll create a .pfx certificate and use “Pkcs12 Protected Configuration Provider” which performs the encryption using a certificate and Windows Azure Certificate Store, to encrypt our web.config file.

➤ Anyone with the connection string can access your database, and you definitely do not want that…

Advertisement

Using SSL (Https) in an Azure Cloud Service – Boredom Challenge Final Day

Standard

Any person that has a basic computer knowledge can go ahead and use Microsoft Network Monitor, Fiddler or any other similar application to monitor his/her own network traffic, whereupon he/she will see that the applications which use HTTP have their data displayed plainly. And people with a little more technical knowledge can go further and use other applications (such as Cain and Abel) to sniff the whole network, which will include packages from every computer connected to it. So, someone just logged in to a website that used HTTP while you were listening to the network? Well, tough luck for him/her, because you’ve just sniffed the username and password.

For demonstration, I’ve created an Azure Cloud Service that has a method which returns the number of characters for a given string. And as you see, Fiddler directly catches my request to the web method and its response:

This is what I sent to the web method.

This is what I sent to the web method.

And this is what the web method returned.

And this is what the web method returned.

Of course, a competent developer would take precautions against this. We use hashing and salting for username – passwords so they are not displayed plainly, but still, we don’t want people to get the hashed version either, because then they could try decrypting it or use that hashed version to make calls to our service themselves. Therefore, we need more security.

This is where HTTPS comes in, which is actually the HTTP protocol with SSL on top. SSL (Secure Socket Layer) uses certificates for encryption and authorization, therefore allowing a secure communication over the network. Many applications (such as e-mail, instant messaging or voice-over-IP applications) use this to ensure security, and in this article, we’ll see how we can use it in our own Azure Cloud Service.

➤ For bonus points, use Fiddler to check other apps’ web method calls. It’s quite entertaining to see how they work. 🙂

Storing User Credentials Securely in Windows Store Apps – Boredom Challenge Day 17

Standard

It is quite common to need to store our users’ usernames and passwords (or other critical information, such as access tokens) in our apps, so our users won’t have to sign in each time they use the app. However, although I’ve said this is commonly needed, we need to be careful when storing them because we can’t afford even a slightest chance of them being exposed.

So we're talking about "Remember me" or "Keep me signed in" functionality.

So we’re talking about “Remember me” or “Keep me signed in” functionality.

In Windows Store apps, there is a small but potentially deadly pitfall when implementing this feature: Using application local settings for storing username and password. Application settings may be kept isolated from other apps and users but that isn’t enough. They are kept in the registry, and if you dig deep enough and know what you are doing, you may find a way to read them (check this link for starters). For example, in my previous blog posts where we integrated Facebook, we kept the user’s access token this way (for simplicity, of course), and if anyone were to read the application settings and find that token they could read our user’s timeline and/or post stuff on his/her behalf.

This is what will happen when your Facebook access token is exposed, at best.

This is what will happen when your Facebook access token is exposed, at best.

Anyway, joking aside, the correct way to store critical information in Windows Store Apps is to use credential lockers; namely, the PasswordVault and PasswordCredential classes under Windows.Security.Credentials workspace, and in this article we’ll make an example app that keeps the user’s username and password securely.

➤ I have a feeling that “gay” joke is going to give me some headaches when my friends see it