Problem: I cannot use Netscape 6 to manage my Wells Fargo Online account. I submitted a complaint to the Wells Fargo site six weeks ago and got a "Wait two weeks after the official release date for testing" response. Now that it has been six weeks and I have resorted to user agent spoofing to use N6 at Wells, I submitted a second request. This was the response I received: ----------------------------- (#7482-000381-7036\3817036) Dear Eric Pollmann: Thank you for writing Wells Fargo. We understand that you cannot access your account information using Netscape 6.0. Unfortunately, at this time, this browser does not meet our strict security guidelines. We are concerned with the security of your accounts because Netscape 6.0 stores passwords locally on your hard drive. This means once you log off of a banking session, anyone else (using the same computer) could log on to Wells Fargo Online(r) and access your information. We are currently working with Netscape to resolve this issue. Until a solution is found, we suggest using another browser, such as Microsoft's Internet Explorer or an earlier version of Netscape. For a list of supported browsers and download links, please visit: http://www.wellsfargo.com/browser/browsers.jhtml. We apologize for any inconvenience. If you have further questions please contact us by email or by calling 800-956-4442. Sincerely, Online Customer Service ----------------------------- I responded with a hack they can use to fool Password Manager (add an extra <input type=password style=display:hidden> to the form), but this is a huge hack. What we really need is some way for security paranoid sites like Wells Fargo to disable the Password Manager. IE allows their Autocomplete feature to be disabled like this, which seems like a somewhat sane solution: <INPUT TYPE=PASSWORD NAME=password AUTOCOMPLETE="OFF">

This issue was discussed in a comment in bug 48860 (my comment of 2000-12-12). My reply is repeated below. We should not allow the site to opt out of a feature that the user wants to use. However, if the site chooses to be vindictive and not qualify the browser because of it, then we have a problem. --- comment from bug report 48860 -- The issue here boils down to whose browser is it anyway -- the user's or the website's. Shouldn't the user be the one to decide what convenience features he would like to use rather than have a website dictate that to him. As a user I want to be able to save username/passwords from whatever website I chose and not allow particular websites to opt out on me.

One way to make everybody happy might be the following. Add the ability for a site to exclude itself from password-manager but have this controlled by a pref. And the pref is enabled by default (i.e., default behavior is what the site wants). Then a user who wants to be able to use password-manager on *all* sites can go and change the pref setting. Would such a solution be acceptable to Wells Fargo? Or would they take the (IMO unreasonable) position that there must be no way for the user to save his Wells Fargo password even if he really wants to.

I received an identical reply from wellsfargo this morning about not being able to use Netscape 6 on their site. I've emailed off morse's last comment to wellsfargo in a reply. I'll attach any future replies here.

The Citibank group that develops their Web Banking app ('Direct Access') will also pull support for Netscape 6 unless we can provide a way to prevent usage of the password manager against their site. I'm ambivalent about this: I understand the concern that users should have full control over their environment. But the concern of the Web Developers for these financial apps is also valid. The reality is: - Workstations are very often not physically secure. - A great many users wouldn't be aware of how easy it is for someone else to get into their Web Banking or brokerage account. - These sites make it very easy to manipulate large amounts of money. - The financial sites are rightly worried that if a number of people had their accounts tampered with, it wouldn't look good for them (or Netscape 6). The other side of this is that for sites with non-sensitive information, they wouldn't be as concerned preventing password manager from working, so it shouldn't be much of an issue. The solution in 48860 might be acceptable: Have a pref that allows an HTML attribute to block password manager by default. Then, savvy users who dont want this protection can change that pref and allow password manager to work for all sites.

Please let us know when any decision is made on how this will be addressed. Customers are pinging us regularly. Thanks, Mark

I only received a form reply saying they'd forward the suggestions to customer service. Is there someone actually communicating with these people?

Corporate customers with an enterprise support contract are still getting support from the iPlanet support team. Citibank is waiting for feedback from a couple of TechSupport Engineers (including myself) and Wells Fargo is waiting for an answer from another TSE. Any feedback is appreciated.

This qualifies for the new interpretation of the dogfood keyword. marking dogfood.

I worked at Wells for the last 2 years in the web banking group. If the bank cannot control security for the browser then there is the potential for very bad press. To the Wells web banking group bad press means "Wells is out of the web banking business". If the user wants to write their login and password on a slip of paper and leave it on their desk that is their business. Caching their login info on the local system is *not-an-option* from the banks point of view. You may not like it but banks are very serious about security.

what's the html look like?

Take a look a http://people.netscape.com/morse/password2.htm for the html that shows the autocapture attribute. Warning -- that file will not get moved to outside the netscape firewall until late tonight. If you want to view it immediately and are inside the firewall, you can look at http://peoplestage/morse/password2.htm

note that morse's page doesn't demo all the autocomplete=off attributes. The FORM tag can also set autocomplete=off. IE will recognize <FORM autocomplete=off></FORM> also.

We don't have to recognize all the variances that IE does -- just as long as we recognize the ones that are used by the sites we are interested in. I had checked the wells fargo site and they put the attribute on the password field itself. Do you know of any significant sites that do it on the form tag?

mail.yahoo.com puts it in the form field - but they don't block our browser because of it.

I've just received a statement from Citi outlining their position on this. It's a little lengthy to add here (and here is perhaps a little too public). Look here: http://spiderman.mcom.com/~mfranks/citi.html

Based on the latest response from CitiBank, it is clear that having a pref to override the caching will not be acceptable. So we are between a rock and a hard place in trying to please the valid concerns of the financial institutions and please the desire of the user who wants to save *all* his passwords for his own convenience. So I will update my patch to support the autocomplete=off feature but will have it under control of an #ifdef. Then there will be no way for a hacker to walk up to a machine in a cybercafe and override the autocomplete=off feature. But someone who really wants to cache all his passwords on his own machine can build his own version of the browser that does so. Will post a new patch later today.

How will we help financial institutions distinguish between the versions of NS6 with/without the server control of autocomplete?

Let's make that question more general and ask "How can financial institutions destinguish between the real NS6 and a home-brew version that someone built from the open source that puts out the same user-agent string?" Of course the answer is they can't. Anybody can build their own flavor of the mozilla browser and fool any website they want. They can even build a mozilla browser and have it give out the IE user agent string so it can work with citibank's website right now.

The question is not: "How do we stop advanced users from spoofing the user agent string?" We can't. Advanced users can (and do) do this on any browser. The interesting question is: "Now that we have a fix that the financial institutions will accept how do we let them which versions of NS6 to allow?"

r=jelwell I tested on win2000, looks great.

>> "Now that we have a fix that the financial institutions will >> accept how do we let them which versions of NS6 to allow?" User agent string? Netscape 6.5 and Mozilla 0.8.1. They sniff anyway.

Sorry, I misunderstood the question you were asking. I have no idea how the financial institutions will be able to tell the difference between N6.0 and N6.5 unless we change the user-agent string. But that's a whole other problem, outside the scope of this bug report. cc'ing alecf for a super review of this patch.

more liberal use of NS_LITERAL_STRING please... such as foo->GetAttribute(NS_LITERAL_STRING("autocomplete), val); if (val.Equals(NS_LITERAL_STRING("off")) etc

Unfortunately I'm doing EqualsIgnoreCase and not Equals. With IgnoreCase you can't use nsLiteralString. So I can change the "autocomplete" (in the GetAttribute call) to a literal string but I can't change the "off" to a literal string. Attaching new patch which uses literal string for "autocomplete".

sounds good! sr=alecf

Fix checked in.

I have to say that I'm pretty saddened by this bug, but not all that surprised. I use the encrypt-storage options to keep my passwords from being in the clear, but apparently that's not enough for WF. I wonder if they'd be happy with an AUTOCOMPLETE="secure" setting, which would only permit the user agent to capture the password if they had selected to encrypt the password store. Probably not, and besides, IE doesn't support it. I think we'll see the Mozilla tree sprout a perf for this ``server knows best'' behaviour at some point, though probably not in the UI. Banks suck.

Shaver, I share your sentiments exactly. Note my earlier postings to this bug report. It was with great reluctance that I finally created this patch and checked it in. I also thought the possibility of having this blockage in the commercial tree only. We'd probably need to move the test for the autocomplete attribute into a separate file and have separate versions of that file for each tree. If you are interested in making that change, you have my blessings.

Can't we change the UA string at run time? Perhpas a thingy which does just that for bank sites? Naaa....

yes we can :) but unfortunately because of what morse implemented we'd need something to disable that. Banks suck.

Oops, typo in my above comments - hope I sent the right comments to Wells Fargo and the typo is why I was completely ignored: "I responded with a hack they can use to fool Password Manager (add an extra <input type=password style=display:hidden> to the form), but this is a huge hack." should read: "I responded with a hack they can use to fool Password Manager (add an extra <input type=password style=display:none> to the form), but this is a huge hack." Note that "display:none" will cause the password input to not display, but "display:hidden" will do nothing.

Weak security is the *worst* kind of security. This kind of security only works to blind the user to the danger.

Steve, you just marked this Netscape-confidentail without any comment. Why is there a need for this to be confidental?

Chris Nalls was concerned because this report mentions 6.5 explicitly.

There are dozens of mentions in the newsgroups, many more in bugzilla and I think there are even mentions in status updates at www.mozilla.org. The damn Talkback exe calls itself 6.5 There's no secret here anymore.

I knew that. There are in fact over 100 such references in bugzilla alone. But Chris was still concerned which is why I hid this one. If you want to unhide it, go right ahead.

Please don't abuse the Netscape confidential setting, or it will go away fast. It's not enough to say "go ahead and unhide it" in a case where someone noticed the abuse, because we can't police all such settings (maybe we should?). Better to use it only after establishing that something truly confidential is *about to be entered* into the bug report. If a comment has already been entered, it's probably too late. /be

*** Bug 83923 has been marked as a duplicate of this bug. ***

Verified. Here is the sample code. <HTML> <BODY> <CENTER> <FORM> <TABLE> <TR> <TD>User Name</TD> <TD><INPUT TYPE="TEXT" NAME="name"></TD> </TR> <TR> <TD>Password</TD> <TD><INPUT TYPE="PASSWORD" NAME="pswd" AutoComplete=off></TD> </TR> <TR> <TD><INPUT TYPE="SUBMIT" VALUE="ENTER"></TD> </TR> </TABLE> </FORM> </CENTER> </BODY> </HTML>