Tuesday, August 13, 2013

TOTP for ASP.Net Web Forms

Ok, so following my previous post (Two-Factor Authentication - What's the right way) I decided to go on and create a Proof of Concept on how to implement RFC 422 (the way a lot of web services implement 2 Factor Authentication, including Google, Microsoft, DropBox, LastPass etc) using ASP.Net with the Membership Provider.

Although I managed to find a lot of sample code to implement the RFC in .Net code, I failed to find anything that implements this using ASP.Net Membership Provider (MP). In just a few words, MP is a solution built in to .Net Framework that allows for user and credential management in .Net applications (more here). Please note that the same concept can be applied in different frameworks.

Monday, June 3, 2013

Two-Factor Authenication - What's the right way

Following the numerous compromises of accounts to various online services (with the most news-covered being the Twitter account compromises), more and more online services are providing means for Two-Factor Authentication (2FA).

Just as a short primer, authentication is the procedure a service has in order to verify that the user claiming to want to authenticate is actually the user which holds the account. A good simple example (of one-factor authentication) is a username/password combination. I authenticate to the service by providing my username/password combination, and since I am the only on that should know this, I am authenticated as being the owner of the account.

The big problem with the above is what happens if my credentials are stolen or compromised? Well, the service can be tricked by a third person, which can provide the valid username/password combination, into thinking that the third person is me! Granted, there are cases where this is actually desirable (such as shared accounts) but in the end, the result is the same; the service has no way to identify that the person between the chair and the keyboard (or behind the touchscreen nowadays) is the account holder.

Thursday, January 3, 2013

Give your Hyper-V Guest OS's Wireless Internet

I was playing around with creating a virtual lab for a Microsoft Certification I had to do, using Hyper-V on Windows Server 2008 R2. This involved setting up several VMs, which would need updates etc. 

Since my desktop computer uses a wireless USB card for internet connection (my home router is quite a ways away for an ethernet cable and I am too lazy to route one through the wall :) ), I had to figure out how to do this. 

First step, of course, is to make sure that the Hyper-V host can actually utilize the USB wireless dongle. Apart from drivers, you will need to install the "Wireless LAN Service" feature (or you might get stuck for a couple of days trying to figure out why the dongle doesn't work when it should - like I did :) ). 

Next you will need to do a couple of things; Ken Schaefer's blog post was the starting point. Though mostly text based, he links to a blog post by John Paul Cook which provides an illustrated version of Ken's post (as well as an alternative method). Basically, you leverage the Windows Server RRAS role, namely NAT, to route traffic from your Hyper-V Internal network (it needs to be internal - external binds the network to a physical NIC, whereas private does not allow access to the host machine) to the Wireless interface.

What the above blogs failed to mention was a small but important detail: when assigning an IP address to the internal network interface, that address needs to be in the range of the IP addresses used by the VMs. So, if your Hyper-V internal network uses a network, you should allocate an IP within that range (as an example,

Once that is done (assuming the VMs are server OSs and are assigned a static IP address), you need to make sure you can both communicate with the Internet and with any Domain Controllers you may have as a VM (at least, in my case - remember, this is my lab setup). So, the final step is re-configuring the NICs in the VMs to have as a Gateway the IP you assigned to the Internal network NIC (i.e. and the DNS servers should be your Domain Controller's IP as primary, and the Internal network's IP address.

The above allowed me to access the internet from the Hyper-V VMs, and do what was needed. Cheers :)