Mark Allyn wrote:
>
> Best solution is to use the secure socket layor (SSL) that Netscape
> has allready built into their web browsers. You would need the
> domestically available 128 bit key version; not the exportable
> 40 bit key version that has been decrypted via brute force
[snip]
>
> Then set up password authentication on your web server. Since you
> will be using SSL, the username and password will be passed under
> cover over the net and cannot be sniffed.
How will you maintain a "session" for the user. Remember http is
stateless. I've heard of people using cookies or hidden fields
for this type of session maintenance, does anybody know the details of how
this is done and whether or not it is secure?
What about spoofing the remote host via DNS hacks. If I can divert
the users browser to a mirror site and trick them into revealing their
password, then the game is up. End-to-end encryption doesn't defeat
man-in-the-middle (or wrong-man-to-start-with) unless you use some
form of strong authentication.
Does the current generation of SSL support public certificates of the
servers to prevent such? I skipped ahead to the SSL 3.0 docs and it
does support certificates and sessions. Guess I'll have to go back
and read the 2.0 docs.
The Open Market product maintains sessions by passing the user a
"ticket" embedded in the URL. Its really a pretty slick scheme that
works with unmodifed browsers. However I'm not sure whether or not
the industry will rally around that type of approach or go for
something else.
How do you see password schemes w.r.t client certificates? The
password has the advantage of travelling with the user so that s/he
can gain access from any site. However passwords may be guessable.
The SSL encryption at least prevents sniffing the password, but the
password still has the undesirable quality that it has to be given away
to be used.
>
> On this server, along with the SSL capable web server, install
> the Oracle SQL Net client software. Don't install the database
> itself here. That should be installed on another machine on
> the company's internal network. Actually, best here to install the
> newer Oracle Secure SQL Net on both the web server and the internal
> machine with the Oracle database. Be carefull though, the Oracle
> database must be of a certain revision (7.3, I believe), in order
> for secure SQL net to work.
Is there an open solution that would work with any database?
>
> Install this secure dedicated web server on its own lan segment
> segment between two filters. The outer filter should allow only
> http traffic from the outside to touch the web server. No mail,
> telnet, ftp, or anything else. The inside filter should allow only
> SQL Net traffic to go from the web server to the inside network
> and only to the one machine that has the database. Nothing
> else should be allowed through the inside filter except for
> possibly telnet FROM the INSIDE to the web server to facilitate
> maintenace on it, although best is to do all maintenance on
> the box itself from the console. Probably best to have both
> boxes in the same (secured) physical location to facilitate
> maintenance.
Good ideas. One problem: Host security. The SQL/Web server is still
an attack point. If the host becomes compromised, then the attacker
could launch bogus SQL requests. I think that client certificates
are part of the answer here. Of course they only force the attacker
to be customer of the financial firm (or compromise the users PC), but
that's a step forward. Another approach is to use intrusion detection
software on the host to monitor the SQL and Http servers.
Mark Riggins
Secure Systems Engineering
AT&T Bell Labs
References:
|
|
