Paranoid programming...

[Larry W. Virden]

Okay - bear with me here folk!

Imagine one has a database (for example Oracle) which requires a user id
and password to access.  Now, imagine writing an application to let joe
user to look up and insert info into this table.  HOWEVER, we do not
want to generally publish the user id and password; we want the coldfusion
app as the 'gateway' into the table.

So far, so good.

However, because of the gateway issue, hard coding the userid and password
into the cfm files is out - the cfm files are in general accessible by
someone browsing the directories. 

The database itself is sensitive enough that the owner does not want the
userid and password put into the ColdFusion admin area either...

If you had to write an app where the database userid and password:
could not be hard coded,
could not be put into the admin area,
could not be entered via prompting
what approach would you use?  Putting it into a file - encrypted or not -
doesn't work; the files are readable and so someone could just copy them
and build their own 'pseudo' app that accesses the data, right?

Looking for 'outside the box' possible solutions.

If it helps, the platform for the server is SPARC Solaris.
-- 
Never apply a Star Trek solution to a Babylon 5 problem.
Larry W. Virden  http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting should 
be construed as representing my employer's opinions.
-><-

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]

RE: Paranoid programming...

[Paul Johnston]

How about storing some of the information using a one way hash (ie MD5)?
This can't be unencoded (or at least, it's pointless to try).  This encrypts
a string the same way each time, so if you have a password, you can put the
same one in, and you always get the same result.

The problem is that you need to get the information from somewhere, so it
has to be stored somewhere secure.  This has to be protected in some way,
and either PGP encryption or one way hashing are the most effective ways of
doing this.

Having a SPARC (ie UNIX) is very useful because you can create a file with
permissions for a certain user and group.  Maybe you could hold all of the
information (encrypted) in there.  This can sit behind the webroot and
therefore isn't accessible except via the file system.  Maybe you could use
a berkeley database to hold the information (access via Perl or something)?

Permissions are definitely the way to go on this one.  Make the file and
directory it is in readable only by one user, and maybe use CFX_TCPClient to
ssh into machine and read the file only it can read.

The problem you have is that you cannot access the database except with the
username and password.  Maybe you could set up a system of temporary
usernames and passwords in the database that only have extremely limited
access to the database. These could then be used on a rolling basis (the
user would never see them).

IMPORTANT BIT
-

At some point you HAVE to pass in a username and password to CF otherwise
database access is impossible.  The issue IS NOT "how do I do this without
storing them", but "how do I store the information without anyone else
getting access?".  Two ways of doing this.  Store it encrypted in an
uncommon encryption format (or use PGP or something) or store it in format
that can only be accessed using a specific type of access (ie database, ssh,
etc) or both of course.

If someone is that desparate to hack into the database, it is unlikely that
they will get the usernames and passwords from trawling around the site and
finding a file that they reside in (make sure you don't name the file
"thepasswords.encrypted" or something silly). The most likely form of
hacking is through code exploits, so as long as you are careful in your
coding, you won't have a problem.

Enjoy!

Paul

> -Original Message-
> From: Larry W. Virden [mailto:[EMAIL PROTECTED]]
> Sent: 02 November 2000 09:41
> To: CF-Talk
> Subject: Paranoid programming...
>
>
> Okay - bear with me here folk!
>
> Imagine one has a database (for example Oracle) which requires a user id
> and password to access.  Now, imagine writing an application to let joe
> user to look up and insert info into this table.  HOWEVER, we do not
> want to generally publish the user id and password; we want the coldfusion
> app as the 'gateway' into the table.
>
> So far, so good.
>
> However, because of the gateway issue, hard coding the userid and password
> into the cfm files is out - the cfm files are in general accessible by
> someone browsing the directories.
>
> The database itself is sensitive enough that the owner does not want the
> userid and password put into the ColdFusion admin area either...
>
> If you had to write an app where the database userid and password:
>   could not be hard coded,
>   could not be put into the admin area,
>   could not be entered via prompting
> what approach would you use?  Putting it into a file - encrypted or not -
> doesn't work; the files are readable and so someone could just copy them
> and build their own 'pseudo' app that accesses the data, right?
>
> Looking for 'outside the box' possible solutions.
>
> If it helps, the platform for the server is SPARC Solaris.
> --
> Never apply a Star Trek solution to a Babylon 5 problem.
> Larry W. Virden <mailto:[EMAIL PROTECTED]> http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting should
be construed as representing my employer's opinions.
-><-


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]

RE: Paranoid programming...

[Shane Witbeck]

Create a separate user/pass and authenticate through email? i.e. they supply
a user/pass to get the db user/pass sent to them via email.

-Original Message-
From: Larry W. Virden [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 02, 2000 4:41 AM
To: CF-Talk
Subject: Paranoid programming...


Okay - bear with me here folk!

Imagine one has a database (for example Oracle) which requires a user id
and password to access.  Now, imagine writing an application to let joe
user to look up and insert info into this table.  HOWEVER, we do not
want to generally publish the user id and password; we want the coldfusion
app as the 'gateway' into the table.

So far, so good.

However, because of the gateway issue, hard coding the userid and password
into the cfm files is out - the cfm files are in general accessible by
someone browsing the directories.

The database itself is sensitive enough that the owner does not want the
userid and password put into the ColdFusion admin area either...

If you had to write an app where the database userid and password:
could not be hard coded,
could not be put into the admin area,
could not be entered via prompting
what approach would you use?  Putting it into a file - encrypted or not -
doesn't work; the files are readable and so someone could just copy them
and build their own 'pseudo' app that accesses the data, right?

Looking for 'outside the box' possible solutions.

If it helps, the platform for the server is SPARC Solaris.
--
Never apply a Star Trek solution to a Babylon 5 problem.
Larry W. Virden <mailto:[EMAIL PROTECTED]> http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting should
be construed as representing my employer's opinions.
-><-


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]

RE: Paranoid programming...

[Paul Johnston]

This is not a secure solution (which is what I assume you are after).  What
is to stop someone malicious getting/intercepting the email?  Sending a
username and password over email is a hackers dream!

You cannot pass any variables to anyone except the cold fusion server.
There has to be some form of authentication to be able to insert into the
database though.

Paul

> -Original Message-
> From: Shane Witbeck [mailto:[EMAIL PROTECTED]]
> Sent: 02 November 2000 13:02
> To: CF-Talk
> Subject: RE: Paranoid programming...
>
>
> Create a separate user/pass and authenticate through email? i.e.
> they supply
> a user/pass to get the db user/pass sent to them via email.
>
> -Original Message-
> From: Larry W. Virden [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 02, 2000 4:41 AM
> To: CF-Talk
> Subject: Paranoid programming...
>
>
> Okay - bear with me here folk!
>
> Imagine one has a database (for example Oracle) which requires a user id
> and password to access.  Now, imagine writing an application to let joe
> user to look up and insert info into this table.  HOWEVER, we do not
> want to generally publish the user id and password; we want the coldfusion
> app as the 'gateway' into the table.
>
> So far, so good.
>
> However, because of the gateway issue, hard coding the userid and password
> into the cfm files is out - the cfm files are in general accessible by
> someone browsing the directories.
>
> The database itself is sensitive enough that the owner does not want the
> userid and password put into the ColdFusion admin area either...
>
> If you had to write an app where the database userid and password:
>   could not be hard coded,
>   could not be put into the admin area,
>   could not be entered via prompting
> what approach would you use?  Putting it into a file - encrypted or not -
> doesn't work; the files are readable and so someone could just copy them
> and build their own 'pseudo' app that accesses the data, right?
>
> Looking for 'outside the box' possible solutions.
>
> If it helps, the platform for the server is SPARC Solaris.
> --
> Never apply a Star Trek solution to a Babylon 5 problem.
> Larry W. Virden <mailto:[EMAIL PROTECTED]>  http://www.purl.org/NET/lvirden/>
> Even if explicitly stated to the contrary, nothing in this posting should
> be construed as representing my employer's opinions.
> -><-
> --
> --
> 
> 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]
>



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]

Re: Paranoid programming...

[Steve Nelson]

How about store the username/password in a variable that is obtained
from some other place?  so instead of doing this:





You would need to pull that variable from somewhere, maybe from another
database, maybe from a file, that would be up to you.  But this would
keep the username/password out of your direct code and out of the ODBC
driver.

Is that a step in the right direction?

Steve

"Larry W. Virden" wrote:
> 
> Okay - bear with me here folk!
> 
> Imagine one has a database (for example Oracle) which requires a user id
> and password to access.  Now, imagine writing an application to let joe
> user to look up and insert info into this table.  HOWEVER, we do not
> want to generally publish the user id and password; we want the coldfusion
> app as the 'gateway' into the table.
> 
> So far, so good.
> 
> However, because of the gateway issue, hard coding the userid and password
> into the cfm files is out - the cfm files are in general accessible by
> someone browsing the directories.
> 
> The database itself is sensitive enough that the owner does not want the
> userid and password put into the ColdFusion admin area either...
> 
> If you had to write an app where the database userid and password:
> could not be hard coded,
> could not be put into the admin area,
> could not be entered via prompting
> what approach would you use?  Putting it into a file - encrypted or not -
> doesn't work; the files are readable and so someone could just copy them
> and build their own 'pseudo' app that accesses the data, right?
> 
> Looking for 'outside the box' possible solutions.
> 
> If it helps, the platform for the server is SPARC Solaris.
> --
> Never apply a Star Trek solution to a Babylon 5 problem.
> Larry W. Virden  http://www.purl.org/NET/lvirden/>
> Even if explicitly stated to the contrary, nothing in this posting should
> be construed as representing my employer's opinions.
> -><-
> 
>
> 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]

-- 
Steve Nelson
http://www.SecretAgents.com
Tools for Fusebox Developers

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]

Re: Paranoid programming...

[Larry W. Virden]

From: Steve Nelson <[EMAIL PROTECTED]>

How about store the username/password in a variable that is 
obtained
from some other place?  so instead of doing this:





You would need to pull that variable from somewhere, maybe 
from another
database, maybe from a file, that would be up to you.  But 
this would
keep the username/password out of your direct code and out of 
the ODBC
driver.

Is that a step in the right direction?



Unfortunately, someone reading the coldfusion source could then 
go to the file and read it - or write their own coldfusion page 
to read the file.

Frankly, I don't even know how one could do this truly securely 
OUTSIDE of ColdFusion let alone inside ColdFusion...

Something like use of ACLs to block the access to the web pages 
to everyone except nobody (and root or whatever login id the 
backups and restores look like) might be the best shot at locking 
things down.  It's just a real pain to deal with file by file 
ACLs...

-- 
Larry W. Virden mailto:[EMAIL PROTECTED]> 
http://www.purl.org/net/lvirden/>
Even if explicitly stated to the contrary, nothing in this 
posting
should be construed as representing my employer's opinions.



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]

RE: Paranoid programming...

[Gavin Myers]

How about this:

you have a database, here are the table names:


password / content


password would be like this:
:654312324968765132165463213216479897
:6546464634455678998545613213
:54546465465f6asa6sfas1z3x2cz6x5v4a64

content would be like this:
:
:


now, i do not know if this would work or not but... if you could store each
page inside the database and then you would only need one page and have the
information dynamically called from there, that way the only way anyone
could see anything other then an empty query is to hack the database?

make sense?

don't know if this'll work or not though

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]

Re: Paranoid programming...

[Deanna L. Schneider]

Larry,
Is it select access to the data that is an issue? Or is it
update/insert/delete? I would start by suggesting that you create another
user in the Oracle db and grant that user the barest minimum access to the
tables that is necessary. Use this "other" user as the web connection.




Deanna Schneider
Interactive Media Developer
UWEX Cooperative Extension Electronic Publishing Group
103 Extension Bldg
432 N. Lake Street
Madison, WI 53706
(608) 265-7923




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]

Re: Paranoid programming...

[Larry W. Virden]

From: "Deanna L. Schneider" <[EMAIL PROTECTED]>


Larry,
Is it select access to the data that is an issue? Or is it
update/insert/delete? I would start by suggesting that you 
create another
user in the Oracle db and grant that user the barest minimum 
access to the
tables that is necessary. Use this "other" user as the web 
connection.


The issue is that the users have to be able to select and insert 
data into the table, but only via the one ColdFusion application 
- not in any other way.


-- 
Larry W. Virden mailto:[EMAIL PROTECTED]> 
http://www.purl.org/net/lvirden/>
Even if explicitly stated to the contrary, nothing in this 
posting
should be construed as representing my employer's opinions.



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]

Re: Paranoid programming...

[Steve Nelson]

true the username/password data does need to sit somewhere. Although
with this method below you could store the data in a file that you are
SURE is secured.

This is an interesting dilemma.  I'm curious to know if you'll find the
solution you want.  I've had the similar issues of how to store keys to
encrypted data?  If you store it in Cf then if someone gets in throw
some hole in your web server where they could simply read the code, then
they can get your key and decrypt whatever they need to decrypt.  My
solution ended up being a combination, the key was both in the code AND
in the database.  that way you have to break into both servers to access
the full key.  Not a perfect solution, but better than if it was only in
one place.

How about something like that?  

Steve

"Larry W. Virden" wrote:
> 
> From: Steve Nelson <[EMAIL PROTECTED]>
> 
> How about store the username/password in a variable that is
> obtained
> from some other place?  so instead of doing this:
> 
> 
> 
> 
> 
> You would need to pull that variable from somewhere, maybe
> from another
> database, maybe from a file, that would be up to you.  But
> this would
> keep the username/password out of your direct code and out of
> the ODBC
> driver.
> 
> Is that a step in the right direction?
> 
> Unfortunately, someone reading the coldfusion source could then
> go to the file and read it - or write their own coldfusion page
> to read the file.
> 
> Frankly, I don't even know how one could do this truly securely
> OUTSIDE of ColdFusion let alone inside ColdFusion...
> 
> Something like use of ACLs to block the access to the web pages
> to everyone except nobody (and root or whatever login id the
> backups and restores look like) might be the best shot at locking
> things down.  It's just a real pain to deal with file by file
> ACLs...
> 
> --
> Larry W. Virden mailto:[EMAIL PROTECTED]>
> http://www.purl.org/net/lvirden/>
> Even if explicitly stated to the contrary, nothing in this
> posting
> should be construed as representing my employer's opinions.
> 
> 
>
> 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]

-- 
Steve Nelson
http://www.SecretAgents.com
Tools for Fusebox Developers

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]

Re: Paranoid programming...

[Larry W. Virden]

From: Steve Nelson <[EMAIL PROTECTED]>


 My
solution ended up being a combination, the key was both in 
the code AND
in the database.  that way you have to break into both 
servers to access
the full key.  Not a perfect solution, but better than if it 
was only in
one place.

In my case, the control I need is access to the database; so 
having keys in the database wouldn't solve anything; there still 
needs to be some way to get into the database, and once that 
occured, the user could theirself get the pieces to get to the 
data.

I suspect that the problem is that Web is just too insecure for 
this type of application.


-- 
Larry W. Virden mailto:[EMAIL PROTECTED]> 
http://www.purl.org/net/lvirden/>
Even if explicitly stated to the contrary, nothing in this 
posting
should be construed as representing my employer's opinions.



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]

Re: Paranoid programming...

[Steve Nelson]

how about instead of storing the username/pass in a database you store
it in a file that can only be accessible by the CF user?

not sure what you're doing, but you might be right about the web being
too insecure.  The web is "pretty" secure if you take a lot of
precautions, but it's not invincible. :)

Steve

"Larry W. Virden" wrote:
> 
> From: Steve Nelson <[EMAIL PROTECTED]>
> 
>  My
> solution ended up being a combination, the key was both in
> the code AND
> in the database.  that way you have to break into both
> servers to access
> the full key.  Not a perfect solution, but better than if it
> was only in
> one place.
> 
> In my case, the control I need is access to the database; so
> having keys in the database wouldn't solve anything; there still
> needs to be some way to get into the database, and once that
> occured, the user could theirself get the pieces to get to the
> data.
> 
> I suspect that the problem is that Web is just too insecure for
> this type of application.
> 
> --
> Larry W. Virden mailto:[EMAIL PROTECTED]>
> http://www.purl.org/net/lvirden/>
> Even if explicitly stated to the contrary, nothing in this
> posting
> should be construed as representing my employer's opinions.
> 
> 
>
> 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]

-- 
Steve Nelson
http://www.SecretAgents.com
Tools for Fusebox Developers

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]

RE: Paranoid programming...

[Gavin Myers]

how about this:

what about a dummy database?

once again, i don't know how this would work but you make one database that
serves as a relay to another... so the person submits the information to
one, and on a time basis another off server database would link to that one,
download the information and delete everything off of the relay database?

web -information-> database1

database1 -information-> database2(real database, not accessable via web,
download information then close link to network)

database1(deletes itself after upload)


if database2 retreives the information then database1 deletes everything,
even if they access database1 they cant get at database2... maybe?


I guess my question would be is: 

How many people will be using this, and how dynamic can it be? For example,
is this something 5 people would use maybe once every third day, or 100,000
people using every hour?

*shrug*

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]

RE: Paranoid programming...

[Scott Becker]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--_=_NextPart_001_01C044FA.EB0FDE60
Content-Type: text/plain;
charset="iso-8859-1"

>The database itself is sensitive enough that the owner does not want the
>userid and password put into the ColdFusion admin area either...

I'm curious, why do you consider the ColdFusion admin area insecure? Is
there a way the password can be discovered once its put there?

thanks,
Scott

-Original Message-
From: Larry W. Virden [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 02, 2000 4:41 AM
To: CF-Talk
Subject: Paranoid programming...


Okay - bear with me here folk!

Imagine one has a database (for example Oracle) which requires a user id
and password to access.  Now, imagine writing an application to let joe
user to look up and insert info into this table.  HOWEVER, we do not
want to generally publish the user id and password; we want the coldfusion
app as the 'gateway' into the table.

So far, so good.

However, because of the gateway issue, hard coding the userid and password
into the cfm files is out - the cfm files are in general accessible by
someone browsing the directories. 

The database itself is sensitive enough that the owner does not want the
userid and password put into the ColdFusion admin area either...

If you had to write an app where the database userid and password:
could not be hard coded,
could not be put into the admin area,
could not be entered via prompting
what approach would you use?  Putting it into a file - encrypted or not -
doesn't work; the files are readable and so someone could just copy them
and build their own 'pseudo' app that accesses the data, right?

Looking for 'outside the box' possible solutions.

If it helps, the platform for the server is SPARC Solaris.
-- 
Never apply a Star Trek solution to a Babylon 5 problem.
Larry W. Virden <mailto:[EMAIL PROTECTED]> http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting should 
be construed as representing my employer's opinions.
-><-


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]

--_=_NextPart_001_01C044FA.EB0FDE60
Content-Type: text/html;
    charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Paranoid programming...



>The database itself is sensitive enough that the =
owner does not want the
>userid and password put into the ColdFusion =
admin area either...


I'm curious, why do you consider the ColdFusion admin =
area insecure? Is
there a way the password can be discovered once its =
put there?


thanks,
Scott


-Original Message-
From: Larry W. Virden [mailto:[EMAIL PROTECTED]">mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 02, 2000 4:41 AM
To: CF-Talk
Subject: Paranoid programming...



Okay - bear with me here folk!


Imagine one has a database (for example Oracle) which =
requires a user id
and password to access.  Now, imagine writing =
an application to let joe
user to look up and insert info into this =
table.  HOWEVER, we do not
want to generally publish the user id and password; =
we want the coldfusion
app as the 'gateway' into the table.


So far, so good.


However, because of the gateway issue, hard coding =
the userid and password
into the cfm files is out - the cfm files are in =
general accessible by
someone browsing the directories. 


The database itself is sensitive enough that the =
owner does not want the
userid and password put into the ColdFusion admin =
area either...


If you had to write an app where the database userid =
and password:
    could not =
be hard coded,
    could not =
be put into the admin area,
    could not =
be entered via prompting
what approach would you use?  Putting it into a =
file - encrypted or not -
doesn't work; the files are readable and so someone =
could just copy them
and build their own 'pseudo' app that accesses the =
data, right?


Looking for 'outside the box' possible =
solutions.


If it helps, the platform for the server is SPARC =
Solaris.
-- 
Never apply a Star Trek solution to a Babylon 5 =
problem.
Larry W. Virden <mailto:[EMAIL PROTECTED]">mailto:[EMAIL PROTECTED]> <URL: =
http://www.purl.org/NET/lvirden/" =
TARGET=3D"_blank">http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing =
in this posting should 
be construed as representing my employer's =
opinions.
-><-
---

RE: Paranoid programming...

[Zachary Bedell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> >The database itself is sensitive enough that the owner does 
> not want the
> >userid and password put into the ColdFusion admin area either...
> 
> I'm curious, why do you consider the ColdFusion admin area 
> insecure? Is
> there a way the password can be discovered once its put there?

Any DB passwords entered in the CF Admin pages are stored encrypted
in the registry (or the CF registry file in the case of UN*X).  It's
technically possible to decrypt that password once it's stored there
if you know the password that CF uses to encrypt it in the first
place.

BUT since that section of your registry or the registry file should
be secured to admin access only, then only admins (which shall be
presumed to already know the password) could access the encrypted
password in the first place.


To respond to the original poster's questions:

I'm afraid you're being a little too paranoid for your own good.  No
matter how you structure things, at some point, the CF Server must
have an unencrypted copy of the DB password to send off to the DB
Server.  It's gotta be stored somewhere.  You can certainly encrypt
it when you store it, but the CF code has to be able to decrypt that
password in order to use it.  There really isn't any way to get
around the fact that the password must be in cleartext at some point
for CF to use it.  

Now...  You mentioned:
>However, because of the gateway issue, hard coding the userid and
>password into the cfm files is out - the cfm files are in general
>accessible by someone browsing the directories. 

I'm not sure who you're worried about browsing your directories. 
General web users can't see your CF source code (assuming your server
is configured correctly.  And if it's not, then you've got way bigger
issues to worry about, no?...).  The only folks that can see your CF
source are those that have direct telnet, ftp, or physical access to
the box.  And of those, only users that have been granted access to
the web directory can actually see the files in question.  Assuming
you've set your file system security settings properly (IE root, your
backup user, and the account that the webserver runs as should be the
only ones w/ access to those files), then no one important can see
that source anyways.

I gather that the security of your data is quite important to you,
and that's certainly understandable.  Unfortunately, there has to be
some level at which you trust your software & hardware.  If you can't
trust your own code, then there's really nothing you can do to make
yourself feel secure.  There are certainly an unlimited ways to
obfuscate things and make it more difficult for a would-be hacker to
get at your data, but it's not likely that you'll be able to stop a
dedicated attacker who has access to your source code.

That said, here's what I'd do given your situation:
1) Create a CF virtual root in the CF Administrator that points to
somewhere outside of the webserver's root (I'm assuming UN*X CF can
still do this).  Example:  If your webserver root is /home/www/, then
make a directory like /home/ReallySecretStuff/ (you might not want to
use *that* file name... ;-) and store the password files in there. 
If you've called that CF root "DBPass", then you can gain access to
files in there within CF template by using 

The benefit of using a virtual CF root is that if someone gains
source access to CFM's in your webroot through some sort of server
software exploit (::$DATA, +.htr, etc., etc), they can't get at
the files outside of your webroot (at least not with any exploits
I've seen to date).  That way they might see the name of the file
with your passwords, but chances are really slim they'd be able to
get to them.

2) Your password file itself is nothing more than a little CF
template w/ a couple of CFSets.  Something like:




You could certainly employ some basic encryption here, but it would
just be obfuscation.  You might slow down an attacker, but chances
are you won't stop them. 

I would use CFENCODE to encrypt that CF template. Again, that's not
terribly secure, but it will prevent a casual browser of your server
from accidentally seeing your passwords.

3) In your actual CFM's, do:


SELECT ...


That's about it  I'll stress just one more time that this is NOT
100% secure, and that someone who REALLY wants your data WILL GET
your data no matter what you do.  This does provide what I think is a
reasonable measure of security & difficulty so that your average
luser with nothing better to do will likely take a hike before he
gets into your data.

If you'd care to get any other details on any part of that, feel free
to ask.



Best regards,
Zac Bedell

-BEGIN PGP SIGNATURE-
Version: PGPfreeware 6.5.8 for non-commercial use 

iQA/AwUBOgHCEavhLS1aWPxeEQIhyQCfV1YHqMb7C5w7QopKL/+3ClQuEhIAn2SB
pwunhPbaqlW7xx+bm4FCmiUm
=KXcz
-END PGP SIGNATURE-

Re: Paranoid programming...

[Larry W. Virden]

From: Gavin Myers <[EMAIL PROTECTED]>

> what about a dummy database?

Now that's an interesting approach - I'll think about this one.

The problem with the idea of storing the password in a file 'accessible
only by the CF user' is that, under Unix, the server runs as a single
user.  It gets certain info from LDAP, etc. but runs as a separate, low
priority user.  So if coldfusion can read the file, so can everyone else...
-- 
Never apply a Star Trek solution to a Babylon 5 problem.
Larry W. Virden  http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting should 
be construed as representing my employer's opinions.
-><-

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]

Re: Paranoid programming...

[Larry W. Virden]

From: Scott Becker <[EMAIL PROTECTED]>

> I'm curious, why do you consider the ColdFusion admin area insecure? Is
> there a way the password can be discovered once its put there?

The problem, as it is described to me, is this.  Coldfusion on Solaris
requires one to share one ColdFusion instance per box.  Thus, one either
has to dedicate one complete hardware/software machine for one sensitive
application, or one has to remove userids and passwords from the data
source area.  Otherwise, anyone putting applications on that machine
could, potentially, make use of the data source to access your data.
-- 
Never apply a Star Trek solution to a Babylon 5 problem.
Larry W. Virden  http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting should 
be construed as representing my employer's opinions.
-><-

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]

Re: Paranoid programming...

[Jake Hileman - Patmos]

In Win, you can just set a certain key to 0 and wallah, the CFPassword is no
longer even in use... hosting companies should never let users use the
CFregistry tag.

Anyhow... do any of you boys have a solution to why cfpop won't give me a
valid #replyto# var?  it just pops it out empty... is this a bug?

jake
- Original Message -
From: "Larry W. Virden" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Thursday, November 02, 2000 2:36 PM
Subject: Re: Paranoid programming...


>
> From: Gavin Myers <[EMAIL PROTECTED]>
>
> > what about a dummy database?
>
> Now that's an interesting approach - I'll think about this one.
>
> The problem with the idea of storing the password in a file 'accessible
> only by the CF user' is that, under Unix, the server runs as a single
> user.  It gets certain info from LDAP, etc. but runs as a separate, low
> priority user.  So if coldfusion can read the file, so can everyone
else...
> --
> Never apply a Star Trek solution to a Babylon 5 problem.
> Larry W. Virden <mailto:[EMAIL PROTECTED]> http://www.purl.org/NET/lvirden/>
> Even if explicitly stated to the contrary, nothing in this posting should
> be construed as representing my employer's opinions.
> -><-
> --
--
> 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]

RE: Paranoid programming...

[Chris Evans]

What about hardcoding the username and password in a CFX tag?  It is
compiled, so it won't be simple to extract.

Chris Evans
[EMAIL PROTECTED]
http://www.fuseware.com


-Original Message-
From: Larry W. Virden [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 02, 2000 2:39 PM
To: CF-Talk
Subject: Re: Paranoid programming...



From: Scott Becker <[EMAIL PROTECTED]>

> I'm curious, why do you consider the ColdFusion admin area insecure? Is
> there a way the password can be discovered once its put there?

The problem, as it is described to me, is this.  Coldfusion on Solaris
requires one to share one ColdFusion instance per box.  Thus, one either
has to dedicate one complete hardware/software machine for one sensitive
application, or one has to remove userids and passwords from the data
source area.  Otherwise, anyone putting applications on that machine
could, potentially, make use of the data source to access your data.
--
Never apply a Star Trek solution to a Babylon 5 problem.
Larry W. Virden <mailto:[EMAIL PROTECTED]> http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting should
be construed as representing my employer's opinions.
-><-


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]

RE: Paranoid programming...

[Larry W. Virden]

From: "Chris Evans" <[EMAIL PROTECTED]>


What about hardcoding the username and password in a CFX tag? 
 It is
compiled, so it won't be simple to extract.


Might work - except I have been unable for the past 18+ months to 
find any info about writing cfx's for Solaris...

-- 
Larry W. Virden mailto:[EMAIL PROTECTED]> 
http://www.purl.org/net/lvirden/>
Even if explicitly stated to the contrary, nothing in this 
posting
should be construed as representing my employer's opinions.



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]

RE: Paranoid programming...

[Gavin Myers]

---Excerpts from stuff around the net that you probally allready have, worth
a shot though---

http://alive.allaire.com/CatalogCourseDetail.cfm?CourseID=20


http://alive.allaire.com/CatalogCourseDetail.cfm?CourseID=40
Solaris 

You can debug custom tags on UNIX using the dbx debugger. You should
shutdown ColdFusion using the stop script. 

Set the environment variables, including LD_LIBRARY_PATH and CFHOME as they
are set in the start script. You should then be able to run the cfserver
executable under the dbx debugger and set break points in your CFX code. You
may need to set a break point in main ("stop in main") so dbx loads the
symbols for your CFX before you can set breakpoints in your code. 

HP-UX 10.20 

You can debug custom tags on UNIX using HP's DDE debugger. You should
shutdown ColdFusion using the stop script. 

Set the environment variables, including SHLIB_PATH and CFHOME as they are
set in the start script. You should then be able to run the cfserver
executable under the DDE debugger and set break points in your CFX code. You
may need to set a break point in main ("stop in main") so the debugger loads
the symbols for your CFX before you can set breakpoints in your code. 

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]

RE: Paranoid programming...

[Jaime Garza]

Hey!

I use Java...  It is not that hard, and you might just start from the sample
in the help of CF 4.5.



> -Original Message-
> From: Larry W. Virden [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 02, 2000 12:08 PM
> To: CF-Talk
> Subject: RE: Paranoid programming...
>
>
>
> From: "Chris Evans" <[EMAIL PROTECTED]>
>
>
> What about hardcoding the username and password in a CFX tag?
>  It is
> compiled, so it won't be simple to extract.
>
>
> Might work - except I have been unable for the past 18+ months to
> find any info about writing cfx's for Solaris...
>
> --
> Larry W. Virden mailto:[EMAIL PROTECTED]>
> http://www.purl.org/net/lvirden/>
> Even if explicitly stated to the contrary, nothing in this
> posting
> should be construed as representing my employer's opinions.
>
>
> --
> --
> 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]

Re: Paranoid programming...

[Larry W. Virden]

From: Zachary Bedell <[EMAIL PROTECTED]>
>Now...  You mentioned:
>>However, because of the gateway issue, hard coding the userid and
>>password into the cfm files is out - the cfm files are in general
>>accessible by someone browsing the directories. 
>
>I'm not sure who you're worried about browsing your directories. 

This is an intranet application with over a thousand users having
simple NFS access to the directories...

> you've set your file system security settings properly (IE root, your
> backup user, and the account that the webserver runs as should be the
> only ones w/ access to those files), then no one important can see
> that source anyways.

Unfortunately, that's not how the web server directories are set here,
which of course is contributing to the problem.

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


> That said, here's what I'd do given your situation:

:

> That's about it  I'll stress just one more time that this is NOT
> 100% secure, and that someone who REALLY wants your data WILL GET
> your data no matter what you do.

Thanks - I wll let you know!

-- 
Never apply a Star Trek solution to a Babylon 5 problem.
Larry W. Virden  http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting should 
be construed as representing my employer's opinions.
-><-

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]

Re: Paranoid programming...

[Steve Nelson]

I am brand new to java cfx's, but you could do it in Java in about 10
lines of code, it'd be easy.  I have no idea how to setup java cfx's in
Solaris, but I'm willing to bet it's almost identical to NT.  I'll put a
qarbon tutorial on secretagents.com on how to do it in NT.  Are you
interested?

Steve

"Larry W. Virden" wrote:
> 
> From: "Chris Evans" <[EMAIL PROTECTED]>
> 
> What about hardcoding the username and password in a CFX tag?
>  It is
> compiled, so it won't be simple to extract.
> 
> Might work - except I have been unable for the past 18+ months to
> find any info about writing cfx's for Solaris...
> 
> --
> Larry W. Virden mailto:[EMAIL PROTECTED]>
> http://www.purl.org/net/lvirden/>
> Even if explicitly stated to the contrary, nothing in this
> posting
> should be construed as representing my employer's opinions.
> 
> 
>
> 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]

-- 
Steve Nelson
http://www.SecretAgents.com
Tools for Fusebox Developers

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]

RE: Paranoid programming...

[Larry W. Virden]

Re: allaire courses

When I choose download, it tells me to choose my C: drive;
my solaris machine doesn't have one of those ;-).  When
I choose play over ISDN (which I don't have) netscape generates
a trashed window (I see 1/2 of a button and no text).

Are other people who are using Solaris having better luck seeing 
this stuff?


-- 
Larry W. Virden mailto:[EMAIL PROTECTED]> 
http://www.purl.org/net/lvirden/>
Even if explicitly stated to the contrary, nothing in this 
posting
should be construed as representing my employer's opinions.



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]

Re: Paranoid programming...

[robi sen]

compiled code is easy to decompile unless people obfuscate the code and few know how.


Steve Nelson wrote:

> I am brand new to java cfx's, but you could do it in Java in about 10
> lines of code, it'd be easy.  I have no idea how to setup java cfx's in
> Solaris, but I'm willing to bet it's almost identical to NT.  I'll put a
> qarbon tutorial on secretagents.com on how to do it in NT.  Are you
> interested?
>
> Steve
>
> "Larry W. Virden" wrote:
> >
> > From: "Chris Evans" <[EMAIL PROTECTED]>
> >
> > What about hardcoding the username and password in a CFX tag?
> >  It is
> > compiled, so it won't be simple to extract.
> >
> > Might work - except I have been unable for the past 18+ months to
> > find any info about writing cfx's for Solaris...
> >
> > --
> > Larry W. Virden mailto:[EMAIL PROTECTED]>
> > http://www.purl.org/net/lvirden/>
> > Even if explicitly stated to the contrary, nothing in this
> > posting
> > should be construed as representing my employer's opinions.
> >
> > 
>
> > 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]
>
> --
> Steve Nelson
> http://www.SecretAgents.com
> Tools for Fusebox Developers
> 
>
> 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]

Re: Paranoid programming...

[Stephen M. Aylor]

I am ...

Steve - the other one...

(not that there is a comparison or anything... but I m good at drinking beer
:-)

- Original Message -
From: "Steve Nelson" <[EMAIL PROTECTED]>

> Are you
> interested?
>
> Steve





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]

Re: Paranoid programming...

[Felix Huber]

> >
> > From: "Chris Evans" <[EMAIL PROTECTED]>
> >
> > What about hardcoding the username and password in a CFX tag?
> >  It is
> > compiled, so it won't be simple to extract.
>
I don't think that's a good solution  a simple Dissambler (like
Win32Dasm) or a Hexeditor should be enough to find the Username and Password
in the dll.

Greets,
Felix Huber
Webtopia


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]

RE: Paranoid programming...

[Scott, Andrew]

There are a number of ways you can approach this:-

1) You could use the Siteminder security, by creating a userDirectory and a
context you can wrap IsAuthenticated and AuthenticatedUser(). With some work
with the queries you could also have group access and policies/rules to the
code. However you are still limited to the password being unencrypted, now
the best part is that CF has a hash() function. It can encrypt the string,
and store this into the db. But I have never used the hash function so I
can't tell you if you need to pass a key or not. But the point is this is
one way encryption.

2) Create a com object and hide it on the server that someone can't have
access to, but can be called via CF. You could use this com object to then
encrypt the password to be stored into the db.


Both methods work if you take care of the securtiy, and depending on your
needs one might be more overkill than the last.



regards

Andrew Scott
Senior Cold Fusion Application Developer


-Original Message-
From: Larry W. Virden [mailto:[EMAIL PROTECTED]]
Sent: 02 November 2000 20:41
To: CF-Talk
Subject: Paranoid programming...


Okay - bear with me here folk!

Imagine one has a database (for example Oracle) which requires a user id
and password to access.  Now, imagine writing an application to let joe
user to look up and insert info into this table.  HOWEVER, we do not
want to generally publish the user id and password; we want the coldfusion
app as the 'gateway' into the table.

So far, so good.

However, because of the gateway issue, hard coding the userid and password
into the cfm files is out - the cfm files are in general accessible by
someone browsing the directories. 

The database itself is sensitive enough that the owner does not want the
userid and password put into the ColdFusion admin area either...

If you had to write an app where the database userid and password:
could not be hard coded,
could not be put into the admin area,
could not be entered via prompting
what approach would you use?  Putting it into a file - encrypted or not -
doesn't work; the files are readable and so someone could just copy them
and build their own 'pseudo' app that accesses the data, right?

Looking for 'outside the box' possible solutions.

If it helps, the platform for the server is SPARC Solaris.
-- 
Never apply a Star Trek solution to a Babylon 5 problem.
Larry W. Virden <mailto:[EMAIL PROTECTED]> http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting should 
be construed as representing my employer's opinions.
-><-


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]

RE: Paranoid programming...

[Scott, Andrew]

This method is not secure! Although its unlikely that someone might packet
snoop your site, it can be done.


regards

Andrew Scott
Senior Cold Fusion Application Developer


-Original Message-
From: Shane Witbeck [mailto:[EMAIL PROTECTED]]
Sent: 03 November 2000 00:02
To: CF-Talk
Subject: RE: Paranoid programming...


Create a separate user/pass and authenticate through email? i.e. they supply
a user/pass to get the db user/pass sent to them via email.

-Original Message-
From: Larry W. Virden [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 02, 2000 4:41 AM
To: CF-Talk
Subject: Paranoid programming...


Okay - bear with me here folk!

Imagine one has a database (for example Oracle) which requires a user id
and password to access.  Now, imagine writing an application to let joe
user to look up and insert info into this table.  HOWEVER, we do not
want to generally publish the user id and password; we want the coldfusion
app as the 'gateway' into the table.

So far, so good.

However, because of the gateway issue, hard coding the userid and password
into the cfm files is out - the cfm files are in general accessible by
someone browsing the directories.

The database itself is sensitive enough that the owner does not want the
userid and password put into the ColdFusion admin area either...

If you had to write an app where the database userid and password:
could not be hard coded,
could not be put into the admin area,
could not be entered via prompting
what approach would you use?  Putting it into a file - encrypted or not -
doesn't work; the files are readable and so someone could just copy them
and build their own 'pseudo' app that accesses the data, right?

Looking for 'outside the box' possible solutions.

If it helps, the platform for the server is SPARC Solaris.
--
Never apply a Star Trek solution to a Babylon 5 problem.
Larry W. Virden <mailto:[EMAIL PROTECTED]> http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting should
be construed as representing my employer's opinions.
-><-


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]

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]

RE: Paranoid programming...

[Jaime Garza]

Get JBuilder foundation from inprise (free version), select project
properties, select obfuscate in compilation tab, and then recompile all.
Morale: Use IDE, just like trying CF without CF studio.



> -Original Message-
> From: robi sen [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 02, 2000 2:14 PM
> To: CF-Talk
> Subject: Re: Paranoid programming...
>
>
> compiled code is easy to decompile unless people obfuscate the
> code and few know how.
>
>
> Steve Nelson wrote:
>
> > I am brand new to java cfx's, but you could do it in Java in about 10
> > lines of code, it'd be easy.  I have no idea how to setup java cfx's in
> > Solaris, but I'm willing to bet it's almost identical to NT.  I'll put a
> > qarbon tutorial on secretagents.com on how to do it in NT.  Are you
> > interested?
> >
> > Steve
> >
> > "Larry W. Virden" wrote:
> > >
> > > From: "Chris Evans" <[EMAIL PROTECTED]>
> > >
> > > What about hardcoding the username and password in a CFX tag?
> > >  It is
> > > compiled, so it won't be simple to extract.
> > >
> > > Might work - except I have been unable for the past 18+ months to
> > > find any info about writing cfx's for Solaris...
> > >
> > > --
> > > Larry W. Virden mailto:[EMAIL PROTECTED]>
> > > http://www.purl.org/net/lvirden/>
> > > Even if explicitly stated to the contrary, nothing in this
> > > posting
> > > should be construed as representing my employer's opinions.
> > >
> > >
> --
> --
> > > 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]
>
> --
> Steve Nelson
> http://www.SecretAgents.com
> Tools for Fusebox Developers
> --
--
> 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]


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]

Re: Paranoid programming...

[paul smith]

The following on Java just came in over the transom

http://www.swynk.com/friends/smith/javaencrypt.asp

best,  paul

At 03:14 PM 11/2/00 -0700, you wrote:
> > I am brand new to java cfx's, but you could do it in Java in about 10
> > lines of code, it'd be easy.  I have no idea how to setup java cfx's in
> > Solaris, but I'm willing to bet it's almost identical to NT.  I'll put a
> > qarbon tutorial on secretagents.com on how to do it in NT.  Are you
> > interested?


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]

Re: Paranoid programming...

[Steve Nelson]

So.


What are the potential solutions?  Are any of them effective?


Steve Nelson
http://www.SecretAgents.com
Tools for Fusebox Developers

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]

Re: Paranoid programming...

[Jeremy Allen]

With email its not just your domain you have to worry about
but every other router it goes through to get there.


Jeremy

-Original Message-
From: Scott, Andrew <[EMAIL PROTECTED]>
To: CF-Talk <[EMAIL PROTECTED]>
Date: Thursday, November 02, 2000 9:32 PM
Subject: RE: Paranoid programming...


>This method is not secure! Although its unlikely that someone might packet
>snoop your site, it can be done.
>
>
>regards
>
>Andrew Scott
>Senior Cold Fusion Application Developer
>
>
>-Original Message-
>From: Shane Witbeck [mailto:[EMAIL PROTECTED]]
>Sent: 03 November 2000 00:02
>To: CF-Talk
>Subject: RE: Paranoid programming...
>
>
>Create a separate user/pass and authenticate through email? i.e. they
supply
>a user/pass to get the db user/pass sent to them via email.
>
>-Original Message-
>From: Larry W. Virden [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, November 02, 2000 4:41 AM
>To: CF-Talk
>Subject: Paranoid programming...
>
>
>Okay - bear with me here folk!
>
>Imagine one has a database (for example Oracle) which requires a user id
>and password to access.  Now, imagine writing an application to let joe
>user to look up and insert info into this table.  HOWEVER, we do not
>want to generally publish the user id and password; we want the coldfusion
>app as the 'gateway' into the table.
>
>So far, so good.
>
>However, because of the gateway issue, hard coding the userid and password
>into the cfm files is out - the cfm files are in general accessible by
>someone browsing the directories.
>
>The database itself is sensitive enough that the owner does not want the
>userid and password put into the ColdFusion admin area either...
>
>If you had to write an app where the database userid and password:
> could not be hard coded,
> could not be put into the admin area,
> could not be entered via prompting
>what approach would you use?  Putting it into a file - encrypted or not -
>doesn't work; the files are readable and so someone could just copy them
>and build their own 'pseudo' app that accesses the data, right?
>
>Looking for 'outside the box' possible solutions.
>
>If it helps, the platform for the server is SPARC Solaris.
>--
>Never apply a Star Trek solution to a Babylon 5 problem.
>Larry W. Virden <mailto:[EMAIL PROTECTED]> http://www.purl.org/NET/lvirden/>
>Even if explicitly stated to the contrary, nothing in this posting should
>be construed as representing my employer's opinions.
>-><-
>---
-
>
>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]
>---
-
>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]

Re: Paranoid programming...

[paul smith]

Sure.  Be nice and wait for their lawyer's demand letter.
Go on to other things.  Unless they have deep pockets
they'll think twice about pouring a lot of bucks down
an attorney black hole.

As a former member of a corporate board I can assure you
the last thing anyone in a small business wants is to litigate.
It's aggravating and takes too much time & $$$ away from
your business.

best,  paul

At 09:22 PM 11/2/00 -0500, you wrote:
>What are the potential solutions?  Are any of them effective?


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]

Re: Paranoid programming...

[Larry W. Virden]

Re: using CFX's (in any languagE)

It was pointed out to me locally that the problem with doing things in
the CFX is that any app could invoke the CFX, thus defeating the purpose
of putting it into the CFX...

The current hope is that whenever Advanced security becomes available for
ColdFusion Solaris, that will go quite a ways towards resolving the problem.
-- 
Never apply a Star Trek solution to a Babylon 5 problem.
Larry W. Virden  http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting should 
be construed as representing my employer's opinions.
-><-

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]

RE: Paranoid programming...

[Zachary Bedell]

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

Re: Paranoid programming...

[David Cummins]

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]