Fix my program

[Nomen Nescio]

Hello, for an assignment I need to protect my files with a
password. Can anyone please tell me why my C/C++ program is
not working?!!

void main() {
char password[40];
fflush(stdin);
password = gets(NULL);
if (password != "november13") {
10 PRINT "INVALID PASSWORD"
20 BEEP
30 GOTO 10
}
}

Thank you for fixing my program! Also please do not tell
anyone the password, it is copywrited.

-- Nth Complexity --
-- Have A Nice Day! --
"However, these criteria, admirable as they are, are insufficient
for a *liberatory* postmodern science: they liberate human beings
from the tyranny of 'absolute truth' and 'objective reality', but
not necessarily from the tyranny of other human beings. In Andrew
Ross' words, we need a science 'that will be publicly answerable
and of some service to progressive interests.'" -- A.D.S.

 

[santosh]

Hello, for an assignment I need to protect my files with a
password. Can anyone please tell me why my C/C++ program is
not working?!!

void main() {
char password[40];
fflush(stdin);
password = gets(NULL);
if (password != "november13") {
10 PRINT "INVALID PASSWORD"
20 BEEP
30 GOTO 10
}
}

Thank you for fixing my program! Also please do not tell
anyone the password, it is copywrited.

What a lame troll attempt.

<snip>

 

[Richard Heathfield]

Nomen Nescio said:

Hello, for an assignment I need to protect my files with a
password. Can anyone please tell me why my C/C++ program is
not working?!!

void main() {
char password[40];
fflush(stdin);
password = gets(NULL);
if (password != "november13") {
10 PRINT "INVALID PASSWORD"
20 BEEP
30 GOTO 10
}
}

The problem here is that you're using = for assignment. Try := instead, and
you should find that it works just fine. Don't forget to check the "MFC
Support" box in your gcc Makefile before invoking your JCL.

Thank you for fixing my program! Also please do not tell
anyone the password, it is copywrited.

Your secret is safe with me, I promise.

 

[rossum]

Hello, for an assignment I need to protect my files with a
password. Can anyone please tell me why my C/C++ program is
not working?!!

void main() {
char password[40];
fflush(stdin);
password = gets(NULL);
if (password != "november13") {

You need to hide your password here. Better to use:
if ((password + 1) != "november14") {

 

[Zom-B]

Comparing strings with == or != is the same as comparing the memory
locations where both strings are stored, which are of course
different. Try strcmp(password, "november13") instead. Note that this
needs the include "#include <string.h>".

Moreover, it is always a bad idea to store the password as plain text
in the source code. Anyone obtaining a copy of either the source or
executable can see the password with minimal effort. In fact, this is
exactly how I once "cracked" the trial version of UniVBE when I was a
kid.

 

[borkhuis]

Moreover, it is always a bad idea to store the password as plain text
in the source code. Anyone obtaining a copy of either the source or
executable can see the password with minimal effort. In fact, this is
exactly how I once "cracked" the trial version of UniVBE when I was a
kid.

You know that this is illegal. Now we have to report you to the FBI,
the CIA, MI5 and the Internet Security Counsel. Please don't leave
your current location, you will be picked up within an hour.

 

[Mark Wooding]

if (password != "november13") {

It's probably worth pointing out that you can improve security by
hashing the passwords. You should probably replace the above with
something like

if (strcmp(sha384(password), sha384("november13"))) { ... }

-- [mdw]

 

[Richard]

Comparing strings with == or != is the same as comparing the memory
locations where both strings are stored, which are of course
different. Try strcmp(password, "november13") instead. Note that this
needs the include "#include <string.h>".

Moreover, it is always a bad idea to store the password as plain text
in the source code. Anyone obtaining a copy of either the source or
executable can see the password with minimal effort. In fact, this is
exactly how I once "cracked" the trial version of UniVBE when I was a
kid.

Wow. What a whoosh.

 

[Bartc]

It's probably worth pointing out that you can improve security by
hashing the passwords. You should probably replace the above with
something like

if (strcmp(sha384(password), sha384("november13"))) { ... }

Wouldn't "november13" still exist in the executable? Unless sha384 is some
clever macro?

Perhaps encrypted in a separate program and the result put in here.

 

[CBFalconer]

Hello, for an assignment I need to protect my files with a
password. Can anyone please tell me why my C/C++ program is
not working?!!

void main() {
char password[40];

The above line is unique. Apart from lines with only a lone '}',
it is the only line in the program without an obvious error.

fflush(stdin);
password = gets(NULL);
if (password != "november13") {
10 PRINT "INVALID PASSWORD"
20 BEEP
30 GOTO 10
}
}

 

[Thad Smith]

Wouldn't "november13" still exist in the executable? Unless sha384 is some
clever macro?

When <sha384.h> is included, sha384() computes the hash of the string
literal at compile time, but the hash of password at run time, since it
points to a run-time variable.

 

[Sebastian G.]

When <sha384.h> is included, sha384() computes the hash of the string
literal at compile time, but the hash of password at run time, since it
points to a run-time variable.

A optimizing compiler may decide to not optimize away any sufficiently
complex calculation.

 

[Thad Smith]

A optimizing compiler may decide to not optimize away any sufficiently
complex calculation.

Obviously such a compiler is not up to the task!

 

[Sebastian G.]

Obviously such a compiler is not up to the task!

Nonsense. Please show me a compiler that would be so stupid to optimize away
the following function:

BOOL foo(void) {
for(iint64_t i=0; i < 0x0FFFFFFFFFFFFFFF; i++)
if (strcmp(DES_encrypt(i,"foo"),"bar")
return TRUE:
return FALSE;
}

 

[CBFalconer]

Wouldn't "november13" still exist in the executable? Unless sha384
is some clever macro?

Perhaps encrypted in a separate program and the result put in here.

And obviously sha384 has nothing to do with the C language,
inasmuch as it never appears in any C standard. Followups have
been set to eliminate c.l.c, where this is off-topic.

 

[Chris Dollin]

Nonsense. Please show me a compiler that would be so stupid to optimize away
the following function:

BOOL foo(void) {
for(iint64_t i=0; i < 0x0FFFFFFFFFFFFFFF; i++)
if (strcmp(DES_encrypt(i,"foo"),"bar")
return TRUE:
return FALSE;
}

As the previous poster said, /such a compiler/ may not be up to the task
/of compile-time evaluation of/ `sha384` from the possibly-built-in-as-
suggested-by-the-<> `<sha384.h>.

A compiler that decides it cannot do X is -- obviously -- not up to
the task of doing X.

 

[Mark Wooding]

When <sha384.h> is included, sha384() computes the hash of the string
literal at compile time, but the hash of password at run time, since it
points to a run-time variable.

Indeed.

(Of course, the real question is why I chose SHA384 of all things...)

-- [mdw]

 

[Richard Heathfield]

CBFalconer said:

And obviously sha384 has nothing to do with the C language,
inasmuch as it never appears in any C standard. Followups have
been set to eliminate c.l.c, where this is off-topic.

Whoosh!

 

[Richard Tobin]

And obviously sha384 has nothing to do with the C language,
inasmuch as it never appears in any C standard. Followups have
been set to eliminate c.l.c, where this is off-topic.

Er, this whole thread is just responses to a troll, or perhaps a joke,
and is no more on- or off-topic in comp.lang.c than anywhere else. If
you don't find it funny, just don't respond to it, and eventually it will
die out.

-- Richard

 

[santosh]

And obviously sha384 has nothing to do with the C language,
inasmuch as it never appears in any C standard.

This is the case with your ggets and hashlib too.

Followups have
been set to eliminate c.l.c, where this is off-topic.

So I presume your ggets and hashlib are to be considered off-topic here?