By: Kurt Seifried, [email protected], Copyright Kurt Seifried, 2001
Another option is to move some of the authentication mechanism to the client side (although I am not sure why you would want to do this). A variety of languages exist that allow you to write applications that run on the client side. One option would be to write a client side application that behaves like a hardware token, that is a user inputs a secret to activate it, and then you can use challenge response authentication. The problem with this is that the users secret would be shipped to the client machine (which is potentially hostile), and they would be inputting their password into it as well (so if the machine were running a keyboard sniffer/etc it would then have all the info it needs to impersonate the user).
Java is supported on most platforms and browsers, however not all support it properly, and in many cases users will have disabled it (so relying on it might not always work). Java is an excellent option if you control the client side, or can encourage the availability of Java (or are willing to take the chance it might not be available, which is an increasingly minor problem).
One example of this technology in usage is at Hushmail, Hushmail provides free, secure, web based email. You generate a public / private key pair when you sign up for an account with them, and the private key is protected by a passphrase. When you log in to the service a Java applet is downloaded to your PC and this program accepts your passphrase and so on which is partially used to help validate your account, at which point your public and private key are downloaded to the client. Generally speaking this is about as secure as you can make email and still have people accessing it from PC's not under their control. One security concern, over which Hushmail and the user can have little to no control in cases is the possibility of a keyboard sniffer logging the users passphrase for their Hushmail account / private key.
Another possibility is Guardbot, which password protects www pages. Essentially there are two components, an applet that encrypts the data, using DES (56 bit keyspace), and an applet that will decrypt the data with the password you provide. The advantage of this over traditional server based methods of control (such as htaccess in Apache) is that the user manages it fully, and can protect each file individually without much setup. To fully take advantage of the keyspace available your password must contain upper and lower case letters, numbers (and punctuation marks, but this can confuse users) of around 10 letters, however since people tend to choose less then random passwords a longer password then this is advisable.
ActiveX is only supported on Windows platforms running Internet Explorer (it will not work with Netscape) so choosing ActiveX severely limits your browser and OS options.
InnerDynamics makes a variety of Java and ActiveX components that include encryption:
[ Index | Back | Next ]