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 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
Current thread:
- [PEN-TEST] Your opinions are solicited ... Jim Miller (Oct 31)
- Re: [PEN-TEST] Your opinions are solicited ... Thomas Reinke (Nov 01)
- Re: [PEN-TEST] Your opinions are solicited ... van der Kooij, Hugo (Nov 01)
- Re: [PEN-TEST] Your opinions are solicited ... krisk (Nov 01)
- Re: [PEN-TEST] Your opinions are solicited ... L.W. (Nov 01)
- Re: [PEN-TEST] Your opinions are solicited ... Paul Robinson (Nov 01)
- <Possible follow-ups>
- Re: [PEN-TEST] Your opinions are solicited ... St. Clair, James (Nov 01)
- Re: [PEN-TEST] Your opinions are solicited ... Frank Knobbe (Nov 01)
- Re: [PEN-TEST] Your opinions are solicited ... Paul Robinson (Nov 01)
- Re: [PEN-TEST] Your opinions are solicited ... Deus, Attonbitus (Nov 01)
- Re: [PEN-TEST] Your opinions are solicited ... L.W. (Nov 01)
- Re: [PEN-TEST] Your opinions are solicited ... Paul Robinson (Nov 01)
- Re: [PEN-TEST] Your opinions are solicited ... Shawn Davenport (Nov 01)
(Thread continues...)