I am a first time poster but have been devouring most of this site for about 6 months. No need to say I love this site.
After all these internet years the legal aspects regarding password security still seems to be unclear at best. Webmasters have several options regarding password security at their disposal, none of which seem to be a clearcut choice for tiny startup websites that need to operate under a small budget constraint (perhaps at first just to test the waters). There are many commercial websites which require password security not for collecting visa numbers and there is no risk of direct financial losses, but rather for protecting their users for various reasons. Some examples: EBay could use it to protect user bids, Yahoo could use it for access to email, Webmasterworld.com could use it for authenticating users before posting).
I have come up with the following 5 options and wonder what others opinions are on this:
1) Encrypt the login session using SSL.
At first glance this seems the most obvious solution, however the big drawback is the cost of $300+ which to a tiny business just starting and looking to test the water first is a significant cost. Additionally, for each website add another $300+. An ideal solution would not carry an additional $300+ for each additional website.
Also, SSL through web browsers is not 100% safe (although the SSL vendors don't really bring up this fact). For instance, an attacker could use a combination of subverting the websitge DNS and add their own SSL server cert to the users web browser or trusted root store.
2) Password sent over the network in the clear through a POST form.
This method is extremely insecure since an attacker could simply sniff the password over the network. However, there are plenty of websites (My Yahoo [my.yahoo.com], EBay [ebay.com], WebmasterWorld.com [webmasterworld.com]) which still use this method and this fact says to me that either a) the websites feel their Terms Of Service agreements or other legal pieces would support them in a court of law or b) these websites haven't been hit by hackers. Of course it is entirely possible that hackers just aren't interested in sites that do not offer any financial rewards.
Sure Yahoo and EBay offer a secure option using SSL, but this requires the user first noticing the "login securely" link underneath the main login boxes. Then I wonder what the use of such a "secure login" option is worth since if it came down to a lawsuit the user could simply claim they were never informed they needed to use the secure login option. I suppose it helps that law enforcement is increasingly hunting down these hackers and more laws are being passed against the hackers.
Is the website owner protected if the Terms Of Service agreement mentions that the website does not protect against password sniffing?
3) RFC2617 and "Digest Authentication"
This method securely authenticates the user to the website and at no cost to the website, however it does have the drawback in that it seems only IE 5+ has implemented the protocol and supports it. A clause could be added to the Terms Of Service that informs the user if they use IE 5 or above then the website can protect their passwords (to an extent), however I wonder if this would hold up in a court of law or even worse face the possibility of turning potential customers away (the antithesis of a small company).
Also RFC2617 does have a slight hurdle in that the password needs to be communicated securely between the two parties in some fashion, but even on a large scale website this could be tackled with a simple email solution where the attacker would need to be listening for longer periods of time to gather enough information about a user - probably more effort than it's worth.
4) Java applet that gets downloaded and encrypts the password with an RSA public key.
This would use asymmetric key pair and the applet would contain the public key that the applet uses to securely encrypt the users password before it gets sent to the website. The big disadvantage to this is the differences of Java version support in various web browsers.
Also this method also has the weakness that an attacker could hijack the DNS of the website and act as a proxy where the user enters the password to the fake Java applet, then store that, and at the same time forward it on to the real website and return the response back to the user who is none the wiser. Of course this would be significant trouble for the attacker just to enter invalid data on behalf of a user and disrupt the website service.
The big advantage to this method would be that a one-script-works-for-all is highly likely possible to simplify things.
Comments from anyone with opinions or experiences on this subject? Also, does anything change from a legal perspective if a subscription fee is charged by the website? What if the Terms Of Service is somehow forced to be read?