Bedford, MA, Thursday, September 26, 2002 RSA Laboratories . . . announced that a coordinated team of computer programmers and enthusiasts, known as distributed.net, has solved the RC5-64 Secret-Key Challenge. The distributed.net team solved the challenge in approximately four years, using 331,252 volunteers and their machines.
| G |
Gee . . . it took four years and gazillion processor hours to find a 64-bit key to an encryption algorithm that was already known. The word is the key actually was discovered a few months ago, but the team didnt know it had cracked the nut (a 35-character plain text message). Could it be that we are getting a little obsessive about security? Is there any particular piece of information in your enterprise that would be of sufficient value to warrant that type of attack? OK, maybe senior managements unsecured loans and other perquisites need to be locked down that tight. Oops. Just kidding. In fact, most of us probably are using even stronger security than this. On our secure Web sites here at The National Underwriter Co., we use RC4 with 128-bit encryption. A 128-bit key means it is exponentially (adding 1 bit to the key doubles the number of possible keys) more difficult to crack than a 64-bit key using brute force. Maybe we need to step back and explore just what all this security is buying us.
Usually we discuss security from the end-user point of view: Is my credit card information safe? Is my personal financial data secure? These are all legitimate questions, and they have all been addressed and pretty much taken care of. HTTP using secure sockets and properly hardened Web and database servers provide reasonable security for user data. But now look at security from the server side. Who is that client banging on my box right now? Are they whom they claim to be? How can I really be sure the person on my Web site requesting a policy change is an authorized user?
Were All Dogs
I am sure you remember the famous 1993 New Yorker cartoon. Two dogs are at a computer, and the one at the keyboard says, On the Internet, nobody knows youre a dog. Thats funnybut it is true. Your browser client sends a request to a Web server that instantly responds, without any knowledge of who is making that request. You can examine the HTTP header and grab some information: IP address, browser type, encoding, referring URL (if present), etc. Any cookies associated with that domain are sent with the page request to the server, but what have you really learned? Headers can be spoofed, cookies can be modified or deleted. All you really know is that an anonymous user is knocking at the door.
How do you access your bank account online? How do you access your brokerage account? I know how I do mineuser name and password. Two little text strings entered into a Web form, and my bank says, Welcome, Paul. What can we do for you today? Anyone, anywhere, on any computer connected to the Internet could have full access to all my finances. All the secure sockets in the world dont change the fact that all it takes is those two strings to impersonate me. Why bother with all this security if anybody can be me or you?
Lets get back to that question later. For now, lets see whether there is any way to authenticate a user. For the sake of argument, we will assume there is some point in a registration process when we will accept the user is whom he claims to be. When a user account is established for online policy administration, we will accept the authentic user is creating that account. How do we know its him? Because he entered a user name and password! Well, we all know user names and passwords are just about the least secure bit of information around, so maybe we better layer on more security. How about putting a permanent (no expiration) cookie on the box from which he created the account. The cookie will have an encrypted serial number we will authenticate during the next log on. If the cookie serial number matches the user name and password, we accept authentication. That works . . . kind of. Cookies can be moved or stolen, but it seems reasonably secure. The problem is the user doesnt like this scenario. He wants to access his account from any machine. Testing for that one cookie wont work. We could always drop another permanent cookie every time he logs on, but then we have defeated the purpose of the cookie. Cookies are great for storing some unique user information, such as preferences and user name, but cannot be considered reliably secure for authentication.
Software
Web browsers are fairly limited in what they can accomplish on the computer on which they are running. We dont want them mucking about in our hard drives or our registries and returning information to a server. Cookies are just about as much as most of us are willing to allow. The Internet has opened up a whole gamut of privacy issues, and we wont tolerate our Web browsers gathering and handing out private information. Given that, we may need to resort to a software fix.
Lets say you have a corporate intranet site designed for the exclusive use of the top 10 percent of your producers. This site has proprietary company information as well as special deals and high-priced subscription content. Since this site has such a high real and perceived value, you want to ensure only your top producers can gain access. User names and passwords wont provide enough securitythat kind of information is too easy to share. Dropping a permanent cookie on the users computer also wont work because that cookie can be copied to another computer.
You could create a small piece of software that would be required to successfully link to the site you want secured. This solution will work but is a little clunky and has its own drawbacks. Software can be moved from one computer to another if you know what you are doing. Setup CDs can be easily shared. Perhaps you could set up an Internet-only installation that could be used just one time per user. Once again, a little clunky. Why not create a signed JavaScript that would produce a cookie that really could provide unique identification for a particular computer? I say signed because Java- Script in a browser is not a trusted agent and therefore does not have rights to poke about your computer. Users would receive a security warning that this script is authenticated to be from XYZ Insurance. They would then grant permission for this script to execute. The script would find a unique identifier like the MAC address (short for Media Access Control, a hardware address that uniquely identifies each node of a network). That identifier would be forever linked with the user. Access to the controlled site would then be verified by user and machine. That should be enough security for all but the pathologically paranoid.
Do you remember the Pentium III identification number fiasco? Intel proposed each processor be stamped with a distinct identification number. Users could then use the number as a form of identification, similar to a password, to enter protected Web sites. Unfortunately (or fortunately depending on your point of view) the computing public totally rejected the idea because of the fear the identification numbers would be used to track computer use. It didnt matter most of the arguments regarding privacy issues and the serial number were fallacious or irrelevantIntel knew when to run away from a public relations disaster and quickly killed the Pentium serial numbers.
Hardware?
OK, so there is a way to kind of control access to a particular site using software. You could provide hardware authenticationone of those dongle things that plug into a USB or serial port. The dongle is uniquely related to a particular user and can be used as a digital signature for that user. Theoretically the authorized user could carry that piece of hardware around and then gain access to the site from any computerright? Not really. You still need some sort of software or script that will read and authenticate the dongle.
What About the User?
Do we care about the user? To most people the Internet is synonymous with easy access to information. I like the fact I can check e-mail on any of my accounts from anywhere I can grab a computer. Is it possible that placing too many restrictions on site use under the badge of security will drive users away instead of welcome them? Does it really make sense to limit access from only one piece of hardware when most of us have multiple computers at home, at work, and on the road? I dont know. These are business decisions we are all going to need to make and learn from.
No Final Solution
Where does all this leave us? When it comes right down to it, trying to enforce security on the Internet will lead to multiple contradictions. Can we ever really ascertain with any certainty the person behind the browser is whom he says he is? I think not. It seems to me we have become so enamored of the elegant ways we can apparently enforce electronic security that we really begin to believe security equals trust. Nothing can be further from the truth. Most of what we deal with in our day-to-day existence involves a kind of blind faith. When I flash my drivers license at the airport, the cursory glance from the skycap doesnt prove I am who I am. Maybe we should apply the same sort of common sense faith to the Internet. Do we really have any choice?
© Touchpoint Markets, All Rights Reserved. Request academic re-use from www.copyright.com. All other uses, submit a request to TMSalesOperations@arc-network.com. For more information visit Asset & Logo Licensing.