Closed Bug 63961 Opened 24 years ago Closed 23 years ago

Server can't turn off Password Manager || WellsFargo won't allow Moz/N6 || autocomplete=off not supported

Categories

(SeaMonkey :: Passwords & Permissions, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.8.1

People

(Reporter: pollmann, Assigned: morse)

References

()

Details

Attachments

(3 files)

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.
Blocks: 57537
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.
Keywords: dogfood
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
Keywords: dogfoodnsdogfood
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. 
Target Milestone: mozilla1.0 → mozilla0.8.1
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.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
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.
Group: netscapeconfidential?
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. 
Group: netscapeconfidential?
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>
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.