The difficulty of validating systems and users
How to do it accurately?
One of the issues plaguing identity management and online authentication systems is how to accurately validate the identity of the system or user connecting to a service.
One possible means for identification that has attracted attention recently is finding and identifying a "MachineID", some form of unique identifier that is specific to a particular physical system and which is difficult to reliably fake. This might take the form of tracking internal network IP addresses, end user system patch levels and browser configuration, and even tracking of end user system hardware configuration.
A problem that is then encountered is how to reliably identify when more than one user is using an authenticated system - how is the mechanism to handle seemingly identical requests that originate from distinct users.
If the authentication system to be used is to be installed alongside other software then this is a problem that has already been solved and dismissed from all but casual usage.
Many anti-copying software and hardware efforts come in such a format - additional code that forms part of an installed product, for the purpose of ensuring only legitimate copies of the software are in use.
These methods could have modified key software based on how the system identified itself, required the use of a hardware "dongle" for authentication, looked for the presence of hidden system files or the physical presence of removable media, or even looked for the presence of intentionally-corrupted space on original installation media.
With every effort to prevent people from copying or using software in any way they want to comes a dedicated effort to overcome and neutralise the above listed means of preventing non-authorised usage. Going back to the first concept raised in this article - the development and introduction of some equivalent system for use online, the motivation to bypass or trick it increases rapidly alongside the financial incentive to break it, and the increased anonymity afforded to those trying to bypass the authentication.
Even when there is little obvious financial benefit to bypassing the system, it can fail on its own. The problems encountered by legitimate system users when Windows Genuine Advantage and the Windows XP activation tools fail to properly work have been well documented. If the system can fail completely without user interaction, what benefit is it to those it is trying to protect?
Introducing this sort of mechanism into the online environment is much more difficult than merely allowing it to exist on the end user's system. Developers and administrators need to be cogniscent of the problems posed by a stateless protocol that can serve consecutive requests from seemingly different sources as well as the wide variety of end systems that might be in use to reach the online service, not only in terms of different operating system types, but also the use of screen readers, mobile phones, kiosks, and any other of internet-capable devices.
MAC addresses and hard drive serial numbers can provide information to local applications, but they are more difficult to reach via networked systems. Use of platform-dependent technology like ActiveX can simplify this process, but it then leads to security concerns and problems for users of other platforms (OS X and Linux).
There are a number of methods available for basic authentication and tracking of state across a site, but these all have drawbacks and issues that become apparent when systems are scaled up and spread across load balancing and the use of caching proxies.
Even the current "best of breed" solutions have critical flaws where users can force the system to a "fallback" position and force it into a remedial mode where the level of added security and authentication is negligible (back to a simple question in some cases).
Some of the theories being put forward for implementation of one of these systems include browser identification, username in use, system patch levels, though each can be spoofed or hidden from the networked application. At the end of the day, these approaches don?t really tie down to a specific system in use.
Part of the difficulty comes in creating a system that is rigid enough to identify and alert to changes in hardware or end user system configuration, yet flexible enough to allow and identify multiple users from the same machine or a reasonable level of system changes, such as those that might occur from replacing a hard drive, applying system patches, or other routine changes. As a result, many of the systems that come close to achieving these goals don't really add much overall to the security situation faced by the application or primary system.
From a holistic viewpoint, addition of a system designed to identify specific systems can cause problems by actually weakening overall security (thus highlighting problems exist in the overall system design).
There are solutions, however.
One of the products in our testing lab is a platform independent mechanism for attaining this goal. With nothing to install on the user side, complete platform and system independence, it appears that Nabu (the product under testing) is close to achieving the goal of allowing users to safely interact with online services (and vice versa) even when end systems and the joining network are completely compromised. If using a web kiosk or heavily infected system could be made as safe for online account interaction as a heavily locked down readonly system, it would go a long way towards addressing one of the key problems facing Information Security researchers today.
This article originally appeared at Sûnnet Beskerming
© 2007 Sûnnet Beskerming Pty. Ltd
Sûnnet Beskerming is an independent Information Security firm operating from the antipodes. Specialising in the gap between threat emergence and vendor response, Sûnnet Beskerming provides global reach with a local touch.
Sponsored: DevOps and continuous delivery