Posted by Andrew DeFaria on 09/04/05 19:28

Jerry Stuckle wrote:

> Yes, you are entitled to your opinion. But I hope you don't work on
> any of my customer's systems!

Who are you customers? ;-)

> This is NOT "high security". It's barely above "minimal security" -
> minimal being what most sites implement nowadays. - plain text
> passwords, usually without SSL, etc.

Ah nobody was speaking of passwords at all really? We were talking about
replicating portions of a database so that the real database we not
directly manipulated by the end user, then implementing some sort of
syncing processes back and forth. To me that's overkill. For all we know
a very good password system is also in place. In fact that was my
assumption.

> Medium security would also enforce random password rules, SSL for much
> of the data, no telnet/ssh/ftp/sftp access, email on different
> servers, etc.
>
> Now if you want high security - you're talking multiple passwords
> which change by the minute (user has a little credit card sized device
> which flashes a new password every minute) and biometric
> identification, everything ssl, access only from specific IP
> addresses, etc.

Again we were not talking about passwords and SSL - we (or at at least
I) was talking about unnecessary replication of the database.

> And no, this isn't hard to implement. Oracle's replication can be set
> up in a few minutes by someone who knows what they're doing. The
> additional scripts take maybe maybe a half-hour to an hour to write
> each, depending on their complexity. Such a system can be easily set
> up in a couple of days. But, of course, you'd save some time on the
> web site because some of the code would be moved to the server site.

Ah now you switched the argument back DB replication. Clever, but it
doesn't fool me. And I believe it was also suggested to do a subset of
the DB. Doing the whole DB is wasteful in terms of space and time. Now
doing a subset may be easy and may not - it depends on the organization
of the data.

In any event, I fail to see how subsetting a DB and putting only a part
out there will really achieve any security if the are also all kinds of
automating synchronization scripts. The intruder can still infiltrate
your exposed data then just wait for the sync to occur. This then
becomes a false sense of security.

> It takes much longer to actually create the web pages and the back end
> programming than it does to isolate the database on a different server.

Irrelevant as the creation of the web pages and back end programming
need to be done anyway. All you're doing is adding more stuff to do,
more complexity to do the replication (thus making the data less
timely), etc. Now that's fine if you really get a benefit somewhere and
if that benefit or security is indeed required. I just don't see it in
this case. It was not even mention that such a worry or a problem
existed nor that there was any requirement for such.

> And BTW - you indicated you have worked on government systems from a
> consumer POV. You may not think they are the greatest sites - but
> there is a LOT of stuff behind the pages you don't see.

BFD. To me that is not relevant to this situation.

> For instance - check http://www.fcc.gov. You can access their
> wireless license database, but not private information such as DOB's
> and SSN's. You can even update your own records. But you won't be
> able to hack the main database - it isn't on the same system.

Is that really the situation that we have here? Or is that your assumption?

--
I used to have a handle on life, then it broke.

[Back to original message]