Re: prompting for secure data during startup.pl

2003-03-04 Thread Joshua b. Jore/IT/Imation

Or simply unpack() which can also read directly from memory (demonstrated at http://www.greentechnologist.org/wiki/wiki?PerlSvInternals).

Josh






Perrin Harkins <[EMAIL PROTECTED]>
03/03/2003 01:05 PM

        
        To:        "Aaron J. Mackey" <[EMAIL PROTECTED]>
        cc:        [EMAIL PROTECTED]
        Subject:        Re: prompting for secure data during startup.pl


Aaron J Mackey wrote:
> I need to make some secure data available to mod_perl handlers, without
> having it physically stored in a file, database, or "named" shared memory
> (since if someone can read the handlers' code, then they could read the
> sensitive data as well).  So I need to prompt for it during server
> (re)start-up, and stuff it away into a lexical variable that only the
> handler can get at (i.e. another piece of code, or even another handler,
> that blesses itself into my handler's package still cannot access the
> data).  Every httpd child process should have their own copy of the data.
> Is there a solution or cookbook recipe for this yet?

What you're doing looks fine, as far as it goes.  By making these 
variables part of a closure, you are making it impossible for people to 
read it directly with Perl code.  Of course there is nothing you can do 
to prevent someone with full access to your server from running C code 
that will walk Perl's variables until it finds $secret.  They could 
probably do this with creative of some of the B:: modules.

- Perrin





Re: prompting for secure data during startup.pl

2003-03-03 Thread Perrin Harkins
Aaron J Mackey wrote:
I need to make some secure data available to mod_perl handlers, without
having it physically stored in a file, database, or "named" shared memory
(since if someone can read the handlers' code, then they could read the
sensitive data as well).  So I need to prompt for it during server
(re)start-up, and stuff it away into a lexical variable that only the
handler can get at (i.e. another piece of code, or even another handler,
that blesses itself into my handler's package still cannot access the
data).  Every httpd child process should have their own copy of the data.
Is there a solution or cookbook recipe for this yet?
What you're doing looks fine, as far as it goes.  By making these 
variables part of a closure, you are making it impossible for people to 
read it directly with Perl code.  Of course there is nothing you can do 
to prevent someone with full access to your server from running C code 
that will walk Perl's variables until it finds $secret.  They could 
probably do this with creative of some of the B:: modules.

- Perrin



prompting for secure data during startup.pl

2003-03-03 Thread Aaron J Mackey

I need to make some secure data available to mod_perl handlers, without
having it physically stored in a file, database, or "named" shared memory
(since if someone can read the handlers' code, then they could read the
sensitive data as well).  So I need to prompt for it during server
(re)start-up, and stuff it away into a lexical variable that only the
handler can get at (i.e. another piece of code, or even another handler,
that blesses itself into my handler's package still cannot access the
data).  Every httpd child process should have their own copy of the data.
Is there a solution or cookbook recipe for this yet?

Said another way, here's my basic handler code:

package MyHandler;
use Apache::Constants qw(OK DECLINED);

my $SECRET = "secret";
my $SECRETSET = 0;

# only allow the secret to be set once, by startup.pl
sub set_secret { $SECRET = shift unless $SECRETSET++; }

sub handler($$) {

if ($SECRET eq "secret") {
return DECLINED;
} else {
# go ahead, make use of $SECRET
# ...
return OK;
}
}
1;
__END__

And I want startup.pl to do this:

use Term::ReadPassword;
use MyHandler;

MyHandler::set_secret(read_password("Enter secret:"));
__END__

Does this make sense?  Will this work?  Will this be secure? (as long as
no one intercepts my call to set_secret() in startup.pl by installing a
bogus MyHandler.pm in my lib search path ...).

Thanks,

-Aaron

-- 
 Aaron J Mackey
 Pearson Laboratory
 University of Virginia
 (434) 924-2821
 [EMAIL PROTECTED]