Home page logo

pen-test logo Penetration Testing mailing list archives

Re: [PEN-TEST] Your opinions are solicited ...
From: Thomas Reinke <reinke () E-SOFTINC COM>
Date: Mon, 30 Oct 2000 23:32:41 -0500

Jim Miller wrote:

.. on the configuration of security for an Internet application to be deployed.  The bank that I work for is planning 
to deploy a cash mgt application on the internet.  They propose to secure the application and its face on the Net 
with SSL and MS Certificate Server.

The sessions will be protected from Net snooping by SSL's 132 bit encryption, " as strong as IP tunnelling".

Access will be controlled by installing a certificate on each remote client.  The installation is done via download 
from the Certificate Server,  but is a manual process:  the remote will request the certificate and the server will 
download only after a process is started by support.

The IT staff is unsure where the certificate resides on the client.  They suppose it to be both file based and in the 
Registry.  They have tried the "certificate export" process in IE and found that it will not export, so they are 
satisfied that it provides the level of security required to secure a cash mgt application.  They note that the HTML 
page presented to IE without the certificate is an error page.  There is no way to get at the certiciate on the Net 

The cash mgt application has its own security, but I note that it is application level security, and that using only 
logonid / password authentication across the Net is generally held to be a mistake.

Why is it generally held to be a mistake?  This combination is used by
banks world-wide
with great success. I've seen no such statements.  Are there stronger
solutions? Yes. But, they come with their own problems.  Are the
stronger solutions
guaranteed to be stronger? No - buggy applications can STILL violate the
of data at the back-end.

I have recommended using VPN, now readily available in Win2000, but have been rejected.  "A support nightmare." was 
the reason given.

What do you think of the security schema planned?

1) It is difficult to make us of. Users are not ready to go out of the
   Since most users do NOT understand what a certificate is,
   asking them to import a certificate will be prone to many support
hours to deal
   with stumbling problems (unless well laid out).  Plus, the extra
steps may scare
   away users. For what its worth, in Canada, all the major banks are
   (That's 5 of them - we are less fractured in the market place than in
the US,
   serving I believe approximately 20 million consumers).  1 bank uses a
   based solutions. The others all use userid/password solutions, afaik.

2) It is by no means secure.  Does the user have a trojan on their
machine? Then
   your certificate is basically useless, since hackers can now install
keyboard sniffers,
   etc. on the box. SSL ensures data is protected while in transit.
Client side
   certs authenticate user (supposedly), but don't work as well as they
ought to
   in practice because of the impossibility of guaranteeing that you
know the user
   at the remote end hasn't been compromised.

3) Are an operational headache.  Managing certificates is MUCH more
difficult than
   managing a Userid/Password db on an application back-end.  You need
to worry
   about certificate revocation, multiple certificates per user (or do
you only
   allow them to access their bank account from a single, fixed PC?),
and worry
   about re-issuing certificates that expire.

What schema would you use?

Userid and password on controlled at the application back-end.  I would
consider going to client side certificate schemes once smartcard
(or equivalent) is in place, where the certificates are

    a) Automatically distributed without requiring user interaction
       (in the same fashion that a bank/cc company distributes cards)
    b) Are portable from one device to the next while protecting the
       integrity of the public key (requires that the smart card
       reading hw be common place - at least 4-5 years away).

What do you think of the reason given for not using VPN?

Absolutely accurate. Setting up a VPN would be awful - VPN's are
destined to
provide elevated access to a sub-network under a set of special
(such as proper provision of certificates, IP addresses, etc.)  The
problem is
that a compromised machine on the VPN also on the internet as a whole
can now become an unwitting bridge to the entire VPN.  Plus, you need
software your customers do not have sitting on their machines today,
using only a browser removes the bank from the s/w distribution

Cheers, Thomas

Thomas Reinke                            Tel: (905) 331-2260
Director of Technology                   Fax: (905) 331-2504
E-Soft Inc.                         http://www.e-softinc.com
Publishers of SecuritySpace     http://www.securityspace.com

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]