> If my user.login is encrypted one time as kjdfljsldfl��and the user
> comes
>  back and types in kjdfljsldfl they don't get taken to that circuit,
> because
>  it's different this time.
>
Again, that provides insight into your encryption algorithm.

>  I think that with all the benefits of procedures, if you have them
>  available, you're a fool not to use them, and not just because of the
>  enhanced security.��Obviously proper error handling is important AS
> WELL.
>  This is not an either/or argument, rather a complimentary one.
>
Since I don't use stored procedures I most be a fool. Although, I
haven't seen how you have proven that statement to be true.

>  So by understanding the structure of an application, you can then
> begin to
>  analyze it's weaknesses.��In the environment in which I work we want
> to give
>  them as little as possible to go on.
>
Your techniques do not give people less to go on. You just give them a
different set of things to go on.

>  Is that so??��I disagree.��If someone gains access to my web server
> they
>  have nothing.��
No, they have your whole application and anything else that may be
useful. Just being able to change the code in your application without
anyone knowing would allow me to many bad things.

> Now my db which is on the other side of a firewall, and only
>  accepts connections from specific ips, if they got in that it could
> become
>  problematic.
Whoops, IPs can be spoofed.

> ��Why?��Because there are no user names or passwords stored on
>  my web server.��There is no way to open a direct connection into my db
>  without having a user account on the db.
How is that different than any other setup?

> ��Your rights and roles are also
>  stored in that db, not in the application, and so you would not
> really get
>  anything other than images and source code.
There are always other user accounts that can access anything.

> ��You don't even get the code of
>  the procedure calls, and so you are still blind to the schema of my
> db.
>
Again, another user could access the schema.

> But moving towards my CISSP and GSEC, having been a cyber threat
> analyst for
>  the last two years, and soon to be managing a federal CERT, I can
> tell you
>  this, there is always going to be some new exploit. It's going to be
>  something you didn't think of.��But that zero day exploit isn't going
> to be
>  the one that does all the crazy damage.��It's going to be some known
>  vulnerability that you could have prevented from putting your system
> at
>  risk. (slammer, blaster etc.)��By duplication of your efforts, by
>  overlapping your protection you're trying to create a shell around
> your
>  application and it's data.��Obscurity is just one more tool you can
> use to
>  do that.
>
I just hope you aren't protecting something I depend on.

-Matt
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]

Reply via email to