Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses

Re: Re: Obscuring sensitive data in Perl code?

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

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

Hmmm, I've been down that train of thought before, but it seems that it just delays the inevitable (Oh look, the account info is being read from a file - I'll go have a look at that file...). Anyone with access to the secondary file will be able to figure it out. But thanks for your suggestion - at least then the code by itself could be shown to others (for review, etc.) without exposing anything.

I think I'll go snag something I can adapt from the Obfuscated Code page, stick it in a module, and hope for the best...

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

Replies are listed 'Best First'.
Re: Re: Re: Obscuring sensitive data in Perl code?
by merlyn (Sage) on Mar 10, 2001 at 01:08 UTC
    I think I'll go snag something I can adapt from the Obfuscated Code page, stick it in a module, and hope for the best...
    Uh, no. That's precisely the wrong route. Security through obscurity. Check it out on google. Bad idea.

    Just treat that second file as sacred. Don't let people get at it.

    -- Randal L. Schwartz, Perl hacker

      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.

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


        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,

Re: Re: Re: Obscuring sensitive data in Perl code?
by Anonymous Monk on Mar 10, 2001 at 03:20 UTC
    To spell it out more explicitly...

    Make your program setgid and make it owned by a new group such as "wwwpass". Hide your database username/password combo in a separate file which can only be read by the group "wwwpass".

    Now only your program can read the file. Before it does, have your program authenticate the user somehow. If this authentication fails, just terminate the program. If it passes, go ahead and read the sensitive data from that external file.

    This way, even if a user finds out where the sensitive data is hidden, he can't read it unless he uses your program and passes your authentication test.

    You can use setuid instead of setgid if you must, but I personally feel safer using setgid and using a new group name which is dedicated to this task alone.

    The only drawback to all of this is that you must now ensure that your program will pass "taint" checks. But is that really a drawback?


      Excellent scheme, thanks! Sorry I overlooked it in the first round of replies! I think a combination of this method and DBIx::Password used in the appropriate spots will work very well.

Re: Re: Re: Obscuring sensitive data in Perl code?
by Chady (Priest) on Mar 10, 2001 at 01:11 UTC

    why should they have access to the secondary file??
    If you're on a server, you can easily set permissions for files, and you can put the file somewhere unreachable by others without proper permission.

    As you can encrypt the passwords

    Chady |

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://63358]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (4)
As of 2017-11-20 10:20 GMT
Find Nodes?
    Voting Booth?
    In order to be able to say "I know Perl", you must have:

    Results (286 votes). Check out past polls.