I would agree that you're in serious trouble if those three criteria are met.
There are methods that are effective as long as:
1) No-one malicious has the aforementioned level of access.
2) No-one can snoop every packet between a valid user and the server.
You could use a stored procedure which you feed the user's login information,
then it creates a session with a timeout, and returns the session number.
The session number could be used to access another stored procedure which alters
data.
If more flexibility is required, it could just return a username and password,
but you could not time it out.
Of course you would want to encrypt the template which accesses the stored
procedures, and store the password for accessing them in the Administrator.
David Cummins
Zachary Bedell wrote:
>
> > some level at which you trust your software & hardware. If you can't
> > trust your own code,
>
> It's not a matter of trusting code - it's a matter of not trusting hostile
> programmers...
>
> Then... I hate to say it, friend, but you really are screwed.... If there
> are individuals who meet the following:
> 1) They have access to your source.
> 2) They have access to execute their own code on the same server.
> 3) The have any desire to see what's in the database in question.
>
> It is impossible for you to prevent them from getting in given your
> situation. There's just no way. You can certainly obfuscate to your
> heart's content & make it more difficult, but there is literally nothing you
> can do to prevent them from getting at your data. Even scenarios that store
> the DB password off server won't work -- your hostile programmers can get
> the code that retrieves that password, they can execute that code for
> themselves, and they now have the password.
>
> If the security of the data in question is indeed that important to you
> and/or your clients, bosses, etc., then you need another computer. Setup
> another CF machine that access the database and to which your hostile
> programmers will have no access. There's literally nothing else that will
> work. If you're into false senses of security, then you can certainly make
> things look nice & secure, but you can't do a thing to stop your programmers
> from getting at whatever they want to get at. I mentioned trusting software
> & hardware above, but I did forget to mention the one thing you REALLY need
> to be able to trust -- your programmers. If you can't trust the people that
> write your code, then you certainly can't trust the code they write, ya
> know?
>
> Sorry to bear bad tidings, but... Reality has a way of asserting itself at
> times.
>
> Best regards,
> Zac Bedell
>
>------------------------------------------------------------------------------------------------
> Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
> Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message
>with 'unsubscribe' in the body to [EMAIL PROTECTED]
------------------------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message
with 'unsubscribe' in the body to [EMAIL PROTECTED]
