Again, I am using an open algorithm. You can break it. It's a speed bump.
>Your techniques do not give people less to go on. You just give them a
different set of things to go on.
It also makes it more difficult to get something to go on, and makes it take
more time. Hopefully enough that they will go after a softer target.
>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.
I do grant that I was a bit extreme in saying you have nothing. What I
meant was simply accessing my source code isn't in and of it self that big
of a deal. Obviously if you get execute permissions on one of my servers
it's a huge deal.
>How is that different than any other setup?
Because the user name and password are not stored in anyway on the web
server. Ok, I grant you IP addresses can be spoofed, as can mac addresses,
so how do you rectify this issue?
>Again, another user could access the schema.
Yes and if you can guess my sysdba account I am screwed. However I will be
alerted by my server long before any brute force hack would work. Is it
perfect? No, but remember security is about risk mitigation. Nothing can
be 100% secure.
>I just hope you aren't protecting something I depend on.
Don't worry Matt, they wouldn't even let you inside some of the buildings I
work in.
Again, I say, I am not saying that this is the only control you should be
using. Obviously you should have many different approaches to security in
place. From network specific controls, access controls, physical controls,
ids systems. I mean around here the list goes on and on. Auditing, user
interviews, it's a lot to take in in one email thread.
--
Timothy Heald
Web Portfolio Manager
Overseas Security Advisory Council
U.S. Department of State
571.345.2319
The opinions expressed here do not necessarily reflect those of the U.S.
Department of State or any affiliated organization(s). Nor have these
opinions been approved or sanctioned by these organizations. This e-mail is
unclassified based on the definitions in E.O. 12958.
-----Original Message-----
From: Matt Liotta [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 23, 2004 6:06 PM
To: CF-Talk
Subject: Re: Securing CF Apps.
> 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]
