embedding password in program

[JohnF]

I have a C program, used as a public cgi, where a few
of the commands it recognizes and runs should be
restricted to "authorized users". The consequences
of unauthorized use aren't horrendous, so I'm just
looking for enough security to keep out the riff-raff.
What's easy for me to implement is something like
#if !defined(PASSWORD)
#define PASSWORD "default_password"
#endif
static char password[129]=PASSWORD;
and compile it with
cc -DPASSWORD=\"secret_password\" etc.
and then make users enter an extra directive
\password{secret_password}
whenever they want to access restricted commands.

But compiled like this, the strings command run
against the cgi executable image would show the
compiled-in password. Again, the consequences
wouldn't be horrendous. But is there a way to
gently scramble the password a bit so the
executable image doesn't show it quite so easily,
and the code just unscrambles it whenever needed?
A constraint is that the person compiling the
program must still be able to enter the unscrambled
cc -DPASSWORD=\"secret_password\" etc.
And I also don't want that person to need a separate
small scrambling program, whereby he'd then enter
cc -DPASSWORD=\"$(scramble secret_password)\" etc.
So the scrambling must, I suppose, take place at
compile time, at the preprocessor level, while the
corresponding unscrambling would be done by the
program during execution. ... Or something like that.
Thanks for any suggestions,

 

[Kleuskes & Moos]

I have a C program, used as a public cgi, where a few
of the commands it recognizes and runs should be
restricted to "authorized users". The consequences
of unauthorized use aren't horrendous, so I'm just
looking for enough security to keep out the riff-raff.
What's easy for me to implement is something like
  #if !defined(PASSWORD)
    #define PASSWORD "default_password"
  #endif
  static char password[129]=PASSWORD;
and compile it with
  cc -DPASSWORD=\"secret_password\" etc.
and then make users enter an extra directive
  \password{secret_password}
whenever they want to access restricted commands.

But compiled like this, the strings command run
against the cgi executable image would show the
compiled-in password. Again, the consequences
wouldn't be horrendous. But is there a way to
gently scramble the password a bit so the
executable image doesn't show it quite so easily,
and the code just unscrambles it whenever needed?
A constraint is that the person compiling the
program must still be able to enter the unscrambled
  cc -DPASSWORD=\"secret_password\" etc.
And I also don't want that person to need a separate
small scrambling program, whereby he'd then enter
  cc -DPASSWORD=\"$(scramble secret_password)\" etc.
So the scrambling must, I suppose, take place at
compile time, at the preprocessor level, while the
corresponding unscrambling would be done by the
program during execution. ... Or something like that.
Thanks for any suggestions,

There's several, especially if security isn't a big issue, try rot13,
but keep in mind this will only obfuscate the pw, not encrypt it.
Alternetively, you could XOR the chars in the password with some known
value, thus obfuscating it.

Mind you, neither method is safe in the face of a determined hacker.

 

[Malcolm McLean]

A constraint is that the person compiling the
program must still be able to enter the unscrambled
  cc -DPASSWORD=\"secret_password\" etc.

/* make sure password is long enough */
#define PASSWORDPAD PASSWORD ## "12345678901234567890"

int foo(void)
{
password[0] = PASSWORDPAD[0] ^ 0xDE;
password[1] = PASSWORDPAD[1] ^ 0xAD;
...
password[20] = PASSWORDPAD[20] ^7D;
}

foo should compile to a meaningless set of constants. You need to use
the same ones to scramble the entered password for comparison
purposes, of course.

 

[Billy Mays]

I have a C program, used as a public cgi, where a few
of the commands it recognizes and runs should be
restricted to "authorized users". The consequences
of unauthorized use aren't horrendous, so I'm just
looking for enough security to keep out the riff-raff.
What's easy for me to implement is something like
#if !defined(PASSWORD)
#define PASSWORD "default_password"
#endif
static char password[129]=PASSWORD;
and compile it with
cc -DPASSWORD=\"secret_password\" etc.
and then make users enter an extra directive
\password{secret_password}
whenever they want to access restricted commands.

But compiled like this, the strings command run
against the cgi executable image would show the
compiled-in password. Again, the consequences
wouldn't be horrendous. But is there a way to
gently scramble the password a bit so the
executable image doesn't show it quite so easily,
and the code just unscrambles it whenever needed?
A constraint is that the person compiling the
program must still be able to enter the unscrambled
cc -DPASSWORD=\"secret_password\" etc.
And I also don't want that person to need a separate
small scrambling program, whereby he'd then enter
cc -DPASSWORD=\"$(scramble secret_password)\" etc.
So the scrambling must, I suppose, take place at
compile time, at the preprocessor level, while the
corresponding unscrambling would be done by the
program during execution. ... Or something like that.
Thanks for any suggestions,

Steve Reid made a simple and fast SHA-1 set of functions wrapped up into
a single C file. You could calculate the hash of the password you want
in your program and store it in plain text, and then just hash the
incoming password to see if it matches.

Heres a link to the file, but you can easily google his name and sha1 to
find others:

http://source.colloquy.info/svn/trunk/Frameworks/Acid/3rdparty/sha1.c

 

[Kenny McCormack]

I have a C program, used as a public cgi, where a few
of the commands it recognizes and runs should be
restricted to "authorized users". The consequences
of unauthorized use aren't horrendous, so I'm just
looking for enough security to keep out the riff-raff.
What's easy for me to implement is something like

You don't mention platform, but that's probably a good thing as it keeps the
CLC topicality police away, at least temporarily (Kiki: Are you out there?).

Anyway, the reason I bring this up is that on some platforms, the norm these
days is for executables to be compressed (which works out to mean
encrypted), so you can't really run "strings" on them anyway. If yours is
not such a platform, you could probably obtain and use an executable
compressor yourself.

--
Is God willing to prevent evil, but not able? Then he is not omnipotent.
Is he able, but not willing? Then he is malevolent.
Is he both able and willing? Then whence cometh evil?
Is he neither able nor willing? Then why call him God?
~ Epicurus

 

[Kleuskes & Moos]

I have a C program, used as a public cgi, where a few
of the commands it recognizes and runs should be
restricted to "authorized users". The consequences
of unauthorized use aren't horrendous, so I'm just
looking for enough security to keep out the riff-raff.
What's easy for me to implement is something like
   #if !defined(PASSWORD)
     #define PASSWORD "default_password"
   #endif
   static char password[129]=PASSWORD;
and compile it with
   cc -DPASSWORD=\"secret_password\" etc.
and then make users enter an extra directive
   \password{secret_password}
whenever they want to access restricted commands.

But compiled like this, the strings command run
against the cgi executable image would show the
compiled-in password. Again, the consequences
wouldn't be horrendous. But is there a way to
gently scramble the password a bit so the
executable image doesn't show it quite so easily,
and the code just unscrambles it whenever needed?
A constraint is that the person compiling the
program must still be able to enter the unscrambled
   cc -DPASSWORD=\"secret_password\" etc.
And I also don't want that person to need a separate
small scrambling program, whereby he'd then enter
   cc -DPASSWORD=\"$(scramble secret_password)\" etc.
So the scrambling must, I suppose, take place at
compile time, at the preprocessor level, while the
corresponding unscrambling would be done by the
program during execution. ... Or something like that.
Thanks for any suggestions,

Steve Reid made a simple and fast SHA-1 set of functions wrapped up into
a single C file.  You could calculate the hash of the password you want
in your program and store it in plain text, and then just hash the
incoming password to see if it matches.

Heres a link to the file, but you can easily google his name and sha1 to
find others:

http://source.colloquy.info/svn/trunk/Frameworks/Acid/3rdparty/sha1.c

Much better solution than mine. Use this, if possible.

 

[Mickey Mouse]

I have a C program, used as a public cgi, where a few
of the commands it recognizes and runs should be
restricted to "authorized users". The consequences
of unauthorized use aren't horrendous, so I'm just
looking for enough security to keep out the riff-raff.

If your server has directory/file permissions it is easy to set up and
use that rather than buiding some sort of security into the cgi
program.

 

[Kenny McCormack]

If your server has directory/file permissions it is easy to set up and
use that rather than buiding some sort of security into the cgi
program.

It has to be assumed that ordinary file permissions aren't a solution to
this problem.

(... In order for the problem to make any sense ...)

 

[JohnF]

You don't mention platform, but that's probably a good thing as it keeps the
CLC topicality police away, at least temporarily (Kiki: Are you out there?).

Anyway, the reason I bring this up is that on some platforms, the norm these
days is for executables to be compressed (which works out to mean
encrypted), so you can't really run "strings" on them anyway. If yours is
not such a platform, you could probably obtain and use an executable
compressor yourself.

Thanks, Kenny. Ditto K&M, Malcolm, Billy Mays (love your Quick Chop),
Mickey. Actually, the two programs I want to add that \password{}-like
thing to are open source,
http://www.forkosh.com/mathtex.html
http://www.forkosh.com/mimetex.html
and usually compiled by others, so I can't really demand everybody
do that. Likewise with permissions suggested by Mickey (and some
servers require cgi's to have specific permissions that include
r as well as x access). Anyway, any solution has to be generic
since anybody might be compiling it on any platform/environment.

I thought Malcolm (that ## seems extraneous/wrong) and
Billy's solutions wouldn't work since they both involved
runtime code, so the cgi image on disk would still have the
clear password embedded in it. But while messing around with
that kind of thing, I found out the following, which everybody
else probably knows already, and which seems to make the problem
a non-issue:

A preprocessor statement like
#if !defined(PASSWORD)
#define PASSWORD "i don't want strings to show this ascii string"
#endif
doesn't put anything in the executable image >>until<< you
follow it with something like
static char password[999] = PASSWORD;
at which point strings compiled_image.cgi displays the password.

Likewise, even without ever declaring password[],
a function like
int check_password ( char *whatever_user_entered ) {
int i=0, ischecked=0;
for (;;i++)
if ( PASSWORD != whatever_user_entered ) break;
else if ( PASSWORD == '\000' ) { ischecked=1; break; }
return ( ischecked ); }
also embeds a complete "uninterrupted" PASSWORD string
in the compiled_image.cgi file for the code to index through,
and which strings can again display.

But, if you impose a max password length and write the
loop out explicitly, like
int check_password ( char *whatever_user_entered ) {
int ischecked=0;
if ( PASSWORD[0] != whatever_user_entered[0] ) goto end_of_job;
if ( PASSWORD[0] == '\000' ) { ischecked=1; goto end_of_job; }
if ( PASSWORD[1] != whatever_user_entered[1] ) goto end_of_job;
if ( PASSWORD[1] == '\000' ) { ischecked=1; goto end_of_job; }
...
if ( PASSWORD[99] != whatever_user_entered[99] ) goto end_of_job;
if ( PASSWORD[99] == '\000' ) { ischecked=1; goto end_of_job; }
end_of_job: return ( ischecked ); }
then only the separate chars PASSWORD[0], PASSWORD[1], etc,
ever make it into the compiled_image.cgi, each char separated from
its neighbors by lots of bytes of code. The PASSWORD as a whole
string doesn't appear. So strings shows nothing. A determined
hacker, of course, wouldn't have much trouble, but, like I said
originally, I'm only trying for the lowest level of security here.

Of course, I can't be sure what every compiler will do,
but the few I checked (a couple of gcc versions on linux,
and djgpp and mingw on windows) seem to behave this way,
as far as I can tell.

Is God willing to prevent evil, but not able? Then he is not omnipotent.
Is he able, but not willing? Then he is malevolent.
Is he both able and willing? Then whence cometh evil?
Is he neither able nor willing? Then why call him God?
~ Epicurus

You can avoid this, and most such problems, because God is "unknowable".
Of course, a la category theory, all unknowable things are kind of
identical up to isomorphism, so God's pretty much anything you want
him to be. Or, the trivial solution, nothing. ... Whoa, that lightning
came kind of close. But, hah, he mis