June 30, 2006
Integrating strong authentication into Microsoft technologies
One of the interesting parts of blogging is that when you aren't blogging on a consistant basis, regular readers sometimes check in to see that everything is alright. I appreciate such emails, and just want to say thanks to the people that have asked if I am alive or not in one form or another.
Don't fret, I am indeed alive. Just extremely busy working on some stuff in the strong authentication field, and researching how strong authentication can be part of identity management solutions. Learning more about things like InfoCard, it is becoming more clear to me that as we move to the next generation of identity management we are still thinking 30 years back on how the passwords associated with those credentials are used and managed.
In the world we live in today, normal username/password credentials are just not enough. We all know that. Hell, even Bill Gates knows that, stating passwords would be dead in the coming years. Yet we still hang our 'assets' on the line using it. As a SBSer I am in LOVE with the one unique Microsoft killer feature... Remote Web Workplace (RWW). But using RWW shows me there is some unnecessary risk that can be plugged with strong authentication.
If you don't know, RWW allows a user on a SBS domain to access email (OWA/Exchange), the corporate intranet and databases (sharepoint) and corporate desktops and Terminal Servers (proxied Remote Desktop) from external computers outside of the network via a browser. Thats right, they can access all office resources from home via their browser. Or the computer at their inlaws. Or that Internet cafe while on vacation in Europe. As long as they know their Active Directory username and password, they can access all the corporate resources they are authorized to access. Wow... what amazing productivity enhancements this can provide. Access whenever, and whereever you need it.
One flaw with that thinking. It also means that an adversary that can capture those credentials can also access the same things. There is no way to associate that the person (or automated machine!) that is entering those credentials is really Bob or Alice. It could be Gregor, the pesky Russian hacker that installed that software keylogger via his Trojan botnet. Or Stephen the slimeball, who shoulder surfs passwords while you check email at the airport kiosk. Point is... if someone can get or guess your username and password... it is all over. And the attacks to this can be low tech social engineering, which is quite easy to do.
This is something that has bothered me for some time. As great as RWW is, you have to have ABSOLUTE trust of the machine you are at, or you simply shouldn't consider connecting to your corporate network in this way. The risks just aren't worth it. At least on my network. Your risk tolerence is probably different than mine.
But what if we could add another form of authentication that would ensure that the person at the computer connecting in is actually Bob or Alice? Or at the very least, that the user on the other end has more than just the AD credentials? If we could do that, we could significantly reduce the risks of such attack vectors. And that gives me a lot of comfort.
So knowing RWW couldn't do that, I went and wrote an authentication and login system for RWW that DOES do this. By using RADIUS to communicate with a strong two-factor authentication server, we can add two-factor auth on top of the regular AD credential login for RWW. From a login perspective, its not very disruptive... you simply have to add your passcode coming from your two-factor authentication token. The login page for RWW now looks like this:
One of the benefits of the approach I used was the fact you can use the same auth token for other accounts. As such, although you would normally associate the token with your normal login account, you could ALSO use it verify the Administrator account (if you configure it that way). In one environment where this is installed, the SBS admin decided they didn't want ANY of the normal users to have to use two-factor auth, but that the Administrator HAD to. Using their RSA SecurID token associated with a user NOT named Administrator, this was easily done. The advanced login looks like this:
I love doing this stuff.Posted by SilverStr at June 30, 2006 09:13 AM | TrackBack