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
with great success. I've seen no such statements. Are there stronger
solutions? Yes. But, they come with their own problems. Are the
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
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
your certificate is basically useless, since hackers can now install
etc. on the box. SSL ensures data is protected while in transit.
certs authenticate user (supposedly), but don't work as well as they
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
managing a Userid/Password db on an application back-end. You need
about certificate revocation, multiple certificates per user (or do
allow them to access their bank account from a single, fixed PC?),
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
provide elevated access to a sub-network under a set of special
(such as proper provision of certificates, IP addresses, etc.) The
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
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