Is the internal password of delphi exe secure?

Question

If I need the user to enter a password to open the Delphi-generated exe and I use a code like this but not a simple password as this :

if password='1234' then begin
   form2.show
end;

Answer 1

Just to demonstrate HOW unsecure it is, consider this small console application:

program Project1;

{$APPTYPE CONSOLE}

{$R *.res}

uses
  System.SysUtils;

procedure StartProgram;
begin
  writeln('You entered the correct password. Welcome to this awesome program!');
end;

procedure EndProgram;
begin
  writeln('That is not the correct password. Goodbye.');
end;

var
  PW : string;

begin
  write('Enter password: ');
  readln(PW);

  if PW = 'SuperSecretPassword' //See if you can spot this in the image
    then StartProgram
    else EndProgram;

  readln;
end.

Compile it, and open the exe-file in a hex-editor. The screenshot is from XVI32, but I suppose any hex-editor will look somewhat similar:

Not so super secret after all.

Answer 2

No, that will almost certainly be stored as cleartext within the executable.

In fact, no amount of effort will make the executable secure since the checks are done locally - all an attacker needs to do is to edit the executable file to modify the conditional jumps, and your tests will be bypassed. The way these things are usually secured is to move such power away from the attacker. For example, send a user-input password up to a central server that you control, and have the checks done there, sending back something that's needed (and that cannot be faked by a replacement server) only if the checks succeed.

However, that's a lot of possibly unnecessary effort. If all you're trying to do is keep out the casual cracker, you may be able to do so just with a little obfuscation, such as XORing the password with a keyphrase so that it's no so obvious in the executable. Doing the same thing with the password entered by the user, and then comparing those, means that the plaintext password will not be visible.

A scheme like that won't stop a determined cracker but it will make it harder for the vast majority. The idea of security (IT, home, or any other type) is not always to make it impossible to defeat, just to make it hard enough to be less worthwhile.

It really depends on who you're trying to defeat - that will dictate how complex your scheme should be.

Alternatively, you may want to consider an option raised by hvd in a comment. Have the executable simply be a stub which has the actual executable as encrypted data. This would be decrypted using a user-entered key and written to the filesystem, checked for validity, and then run.

Because the password is not within the stub itself, it is not susceptible to an easy attack. The password only exists with the creator (used when making the stub) and the user (hopefully only in their head). Someone who obtains just the stub has no easy way to run the encrypted executable.

Again, there are ways to get around that, but they all involve getting the password without the executable (brute force, social engineering, etc).

Answer 3

No. If somebody wants, they can reverse engineer the executable and get the password.