Asp Forum - embedding password in program

JohnF

6/2/2011 8:22:00 AM

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,
--
John Forkosh ( mailto: j@f.com where j=john and f=forkosh )

9 Answers

Kleuskes & Moos

6/2/2011 9:56:00 AM

On Jun 2, 10:22 am, JohnF <j...@please.see.sig.for.email.com> wrote:
> 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

6/2/2011 11:37:00 AM

On Jun 2, 11:22 am, JohnF <j...@please.see.sig.for.email.com> wrote:
>
> 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.

Carl

6/2/2011 11:50:00 AM

On 6/2/2011 4:22 AM, JohnF wrote:
> 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/3rdpa...

--
Bill

gazelle

6/2/2011 11:59:00 AM

In article <is7h7o$r8k$1@reader1.panix.com>,
JohnF <john@please.see.sig.for.email.com> wrote:
>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

6/2/2011 1:18:00 PM

On Jun 2, 1:49 pm, Billy Mays <no...@nohow.com> wrote:
> On 6/2/2011 4:22 AM, JohnF wrote:
>
>
>
>
>
>
>
>
>
> > 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/3rdpa...
>
> --
> Bill

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

phrogg

6/2/2011 10:39:00 PM

gazelle

6/2/2011 10:57:00 PM

In article <ur3gu6l966bttp70597tfhkiar5vggalk3@4ax.com>,
Mickey Mouse <fake@email.com> wrote:
>On Thu, 2 Jun 2011 08:22:16 +0000 (UTC), JohnF
><john@please.see.sig.for.email.com> wrote:
>
>>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.

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

--
"Remember when teachers, public employees, Planned Parenthood, NPR and PBS
crashed the stock market, wiped out half of our 401Ks, took trillions in
TARP money, spilled oil in the Gulf of Mexico, gave themselves billions in
bonuses, and paid no taxes? Yeah, me neither."

JohnF

6/3/2011 11:05:00 AM

Kenny McCormack <gazelle@shell.xmission.com> wrote:
> JohnF <john@please.see.sig.for.email.com> wrote:
>>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.

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/ma...
http://www.forkosh.com/mi...
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[i] != whatever_user_entered[i] ) break;
else if ( PASSWORD[i] == '\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
--
John Forkosh ( mailto: j@f.com where j=john and f=forkosh )

Datesfat Chicks

6/3/2011 2:13:00 PM

On Thu, 2 Jun 2011 08:22:16 +0000 (UTC), JohnF
<john@please.see.sig.for.email.com> wrote:

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

The standard approach for passwords these days is not to store the
password directly, but to store the cryptographic hash of the
password.

I do have (as part of the program source code) source code for an
SHA-512 implementation here:

http://www...

You may also find this information helpful:

http://en.wikipedia.org/wiki/Cryptographic_has...

Now, a cryptographic hash function (alone) only prevents a person from
going "backwards" from the stored hash to the password. There still
is the problem (if the algorithm is known and it is cheap) that a
person may harvest the hash from the program, then expend a lot of
compute time trying to find a password that matches the hash.

There are two approaches that can be used to make this less
attractive:

a)Try to find some "salt", something else hard for the attacker to get
that is mixed in with the password before the hash.

b)Use a hash procedure that has many rounds and takes perhaps on the
order of 0.5s of compute time. This makes a serious dictionary attack
harder.

You might also look up "Dictionary Attack".

DFC

comp.lang.c

embedding password in program

JohnF

Kleuskes & Moos

Malcolm McLean

Carl

gazelle

Kleuskes & Moos

phrogg

gazelle

JohnF

Datesfat Chicks

x Login to ForumsZone