Re: Bank transactions on Internet

At 04:31 PM 4/8/96 -0700, you wrote:
>I agree with Jim at SFNB that the encryption made possible by VeriSign
>server certificates is an integral part of remote banking on the Web.
>However, I would encourage Security First and other banks looking at the Web
>to focus increased attention on client certificates AND to migrate away from
>their dependence on user passwords.

        I brought this up with SFNB a month or so ago (when I opened my
account) and the word then was that client side certificates would be
avaible within a month or so, my time guestimate (based on what they were
saying) was half-a-year.

>Admittedly, client certificate
>functionality has not yet been available but it will probably be standard by
>mid-1996.

        Let's hope so, I am not keeping significant funds in that account
until I have a certificate.

>Yes---it is true that security is never absolute.

        I hope Eric Young does attempt to crack a 40-bit SFNB session as he
mentioned on cpx today.

>As Michael Karlin of SFNB noted and subsequently corrected, Netscape caches
>passwords.

        I suspected this, and was further exposed because of a common
problem with using Netscape and the like from student accounts (with a big
10M quota), say on MIT's athena, where I like my disk cache to reside in the
workstations /tmp . I wipe(d) it whenever I log out, but I'm sure others
sprinkled their passwords in a million "public" cache's before SFNB stuck
the tag no-cache tag in. 

OBJava: do java applets have access to the cache, would it be possible to
write one of the little nasties that keep an eye on the cache?

>Additionally, people tend to use a single password for 10 or more of their
>relationships and one compromise, compromises all.

        Indeed! How many people use their easily crack "ftp:/etc/passwds"
password for SFNB?

_______________________
Regards,            The best way to have a good 
                    idea is to have lots of ideas. - Linus Pauling
Joseph  Reagle      http://farnsworth.mit.edu/~reagle/home.html
reagle@mit.edu      E0 D5 B2 05 B6 12 DA 65  BE 4D E3 C1 6A 66 25 4E

Joseph M. Reagle Jr. wrote:
> 
> At 04:31 PM 4/8/96 -0700, you wrote:
> >I agree with Jim at SFNB that the encryption made possible by VeriSign
> >server certificates is an integral part of remote banking on the Web.
> >However, I would encourage Security First and other banks looking at the Web
> >to focus increased attention on client certificates AND to migrate away from
> >their dependence on user passwords.
> 
>         I brought this up with SFNB a month or so ago (when I opened my
> account) and the word then was that client side certificates would be
> avaible within a month or so, my time guestimate (based on what they were
> saying) was half-a-year.
> 
> >Admittedly, client certificate
> >functionality has not yet been available but it will probably be standard by
> >mid-1996.
> 
>         Let's hope so, I am not keeping significant funds in that account
> until I have a certificate.

  The release of Netscape Navigator that just started early beta, marketing
named "Atlas", has support for client certificates.  A spec detailing
how to interoperate with it, similar to the one I wrote on SSL 2 server
certificates, should be available before the final release of the product.

> >As Michael Karlin of SFNB noted and subsequently corrected, Netscape caches
> >passwords.
> 
>         I suspected this, and was further exposed because of a common
> problem with using Netscape and the like from student accounts (with a big
> 10M quota), say on MIT's athena, where I like my disk cache to reside in the
> workstations /tmp . I wipe(d) it whenever I log out, but I'm sure others
> sprinkled their passwords in a million "public" cache's before SFNB stuck
> the tag no-cache tag in.

  The statement that "Netscape caches passwords" is not in itself true.
It is true that if the no-cache header is not present, AND the site
is using forms to enter passwords rather than HTTP auth, then the
form post data(including password) will be cached.  I've said here
before that this bug is being fixed in the next beta of the
upcoming release.  The default for SSL pages will be not to cache
at all.  If they used HTTP auth, their passwords would not
have gone into the cache.

> OBJava: do java applets have access to the cache, would it be possible to
> write one of the little nasties that keep an eye on the cache?

  No, Java does not have access to the cache, or any other file.

	--Jeff

-- 
Jeff Weinstein - Electronic Munitions Specialist
Netscape Communication Corporation
jsw@netscape.com - http://home.netscape.com/people/jsw
Any opinions expressed above are mine.