Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Re: Re: Re: Re: Obscuring sensitive data in Perl code?

by larryl (Scribe)
on Mar 10, 2001 at 01:53 UTC ( #63374=note: print w/replies, xml ) Need Help??


in reply to Re: Re: Re: Obscuring sensitive data in Perl code?
in thread Obscuring sensitive data in Perl code?

Sorry, I deserved that, for being a bit flip in my answer... Didn't mean to imply obfuscation was an acceptable security practice...

What I was getting at was just this: The best I can do is set permissions for my script as 0700. For my script to be able to read the secondary file, the permissions on the secondary file most likely would be 0600 with the same owner as my script. So if that user account is compromised, anyone who can read my script can read the secondary file too. At that point I'm basically hosed, so I might as well do what I can and hope the cracker isn't a Perl hacker...

For the Apache server, I will definitely look into DBIx::Password as suggested by chromatic.

  • Comment on Re: Re: Re: Re: Obscuring sensitive data in Perl code?

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Obscuring sensitive data in Perl code?
by buckaduck (Chaplain) on Mar 10, 2001 at 03:48 UTC
    No. Wrong. See my discussion of setgid/setuid programs a few sections below.

    You don't have to set your code to 0700 to make it secure. Make the data 0060 and make your setgid code do a thorough authentication before it reads the data file.

    You don't have to worry about the group being compromised, because you don't even need to have any members in this group. No one can read the data except your program. If you build sufficent security into the program, you're all set.

    (This time I remembered to log in...)

    buckaduck

Re: Re: Re: Re: Re: Obscuring sensitive data in Perl code?
by jynx (Priest) on Mar 10, 2001 at 04:33 UTC

    Please take no offense, but there is a bit of fault in your logic.

    If someone has access to that one account, why don't they have access to root as well? Most likely they do. Especially if the machine is set up well, so that root is the only user that can get access to that account. At that point don't worry about the perl script or the files that you're working on. Worry about the machine (rm -rf /).

    Hoping that the cracker isn't a particular type is about the worst security you can carry, since crackers come in more flavors than unix.

    Hope This Helps,
    jynx

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://63374]
help
Chatterbox?
[hippo]: For explanation, I've seen this construct in someone else's code (no names, no pack drill) and couldn't think of a situation to trigger it.
[Corion]: You'll have to look somewhere esoteric for that. Maybe some tied variable or special dualvar can also trigger that. But it's certainly not a common occurrence
[Corion]: And on 5.20, the following also outputs no find:perl -wle 'for my $x ("\x{2000}".."\ x{1fffff}") { if( $x && ! length $x ) { warn qq(<$x>); warn length $x; die } }'
[Corion]: (this time on Unix)
[hippo]: Understood. I'll have to go through the code and see if it's doing anything fancy with ties, dual-vars or non-scalars. In the end, it's probably a bug though.
[Corion]: Aaah - you should be able to do this with overload, but I would hit somebody really hard if they constructed objects that are true but the empty string, and you not knowing about the domain knowledge where this makes sense

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (14)
As of 2017-07-27 13:34 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    I came, I saw, I ...
























    Results (413 votes). Check out past polls.