Posted by Jerry Stuckle on 09/04/05 22:24

Andrew DeFaria wrote:
> 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? ;-)
>

Small and medium sized businesses and U.S. Government, mainly.

>
> 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.
>

But weak passwords are often how these things are hacked.

>> 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.
>

No, but we ARE talking about protecting data.

>> 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's all part of protecting data. If you can't understand that data
that isn't there can't be hacked, then you have more than a little problem.

>> 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.
>

You indicated it was unnecessary work. It adds very little complexity
to the system. But a large step in security.

>> 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.
>

Sure it is. For instance - the FCC has my SSN in its database. But you
won't be able to hack it through the web because that data is protected.

Remember - YOU brought up the subject of government systems. I just
gave you a real-life example of YOUR subject.

>> 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?
>

That is the situation.

In case you're wondering - I do live in the D.C. area - and do a fair
amount of government work. And although I didn't work on this
particular system, I know some of the programmers who did.

It really looks like you have no idea of what security is. So - please
don't work on any of my customers systems. And let me know which ones
you do work on - I don't want ANY of my personal data on them!

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[Back to original message]