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 site.
>
> 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
security
solutions? Yes. But, they come with their own problems. Are the
stronger solutions
guaranteed to be stronger? No - buggy applications can STILL violate the
integrity
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
gate.
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
on-line.
(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
certificate
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
only
consider going to client side certificate schemes once smartcard
technology
(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
circumstances
(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,
whereas
using only a browser removes the bank from the s/w distribution
business.
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
Received on Nov 01 2000
Intro
