Welcome to WebmasterWorld Guest from 220.127.116.11
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?
1) With the SSL option, you could easily avoid paying $300 per site. The simplest thing to do is have the authentication for all your sites occur under one domain. Then set a session variable and return to the originating domain. Session variables can be made fairly secure, even if they are not encrpyted, by associating the session with a single ip address server side. If the address of the user changes, the session immediately becomes invalid and logging in another time is required. The only problem with this method is that the only item being encrpyted in the user/server interaction is the password.
Also, is it not possible to use SSL without registration through verisign/thawte? The only downside here is the warning message that pops up doesn't exactly instill customer confidence.
2) There is an argument for the POST method, especially on sites like webmasterworld. The risk is that your password is compromised and identity theft can be performed on the boards. The partial solution is to revert damages. The owner of the account and thus domain name should be able to recover a password and change it. An administrator should be able to remove messages by the identity thief.
3) User Agent detection could theoretically deliver this method of authentication invisibly to all users who support it.
4) Java is bad idea. There are compatibility issues and download time increases significantly.
USB Identity keys
The first requires you to send a physical authentication key to the user with a password encoded into the key. This method is available for IE and NS
The second requires the user to have a fingerprint scanner on their machine. This method is available for IE only as far as I know.
Regarding #2, I wonder what a site like EBay does when an invalid user enters a bid. One would think that if EBay can get away with an insecure solution like they do, then surely smaller websites could too. Is it just that they pay their lawyers enough and consider it a cost of doing business? Or is it the fact that they offer both secure and insecure methods and somehow this is enough?