Embed username/password/etc. in exe at install time.

[jehugaleahsa]

Hello:

We have a request for an console application to change the
administrative password on our user's machines during an upcoming
update. The console application will be called from a batch file that
the users will be able to see. Therefore, we can't put the user name/
password in the batch file or plain text in the executable. Finally,
the request specifically asked that the executable be configurable so
they can put other user name/passwords in later.

How can I recieve a user name/password and embed it in an executable?
I was thinking of having a separate file with the encrypted data in
it. However, I would prefer for there to be just the .exe. I also
don't want to create an installer, because it is just a console
application.

How do I do it?

Thanks,
Travis

 

[Lasse Vågsæther Karlsen]

Hello:

We have a request for an console application to change the
administrative password on our user's machines during an upcoming
update. The console application will be called from a batch file that
the users will be able to see. Therefore, we can't put the user name/
password in the batch file or plain text in the executable. Finally,
the request specifically asked that the executable be configurable so
they can put other user name/passwords in later.

How can I recieve a user name/password and embed it in an executable?
I was thinking of having a separate file with the encrypted data in
it. However, I would prefer for there to be just the .exe. I also
don't want to create an installer, because it is just a console
application.

How do I do it?

Thanks,
Travis

Why not store it in registry or a similar place?

Or do you intend to brand the file and then copy it to the target
machine? Perhaps you could just tuck the data onto the end of the file,
like this:

[ exe file contents ][ your data ][ size of your data as Int32 ]

If you build a small program to take the username/password, encrypt it
or otherwise make it less-than-readable, build a byte array, and store
it at the end, you can easily read it back in. The size at the end is
just for simplicity as you can now just read the last 4 bytes of the
file as an Int32, and use that to calculate back into the file.

I don't know how this would play with signing a file.

 

[Nicholas Paldino [.NET/C# MVP]]

Travis,

Ultimately, this is an exercise in futility. The administrators should
be changing the passwords by hand.

Because you don't want the passwords to be in plain text (so others
can't see, I assume), you would encrypt the file. However, to do that, you
need an encryption key. So you embed the encyrption key into the
application (or the application constructs it from other data available to
it). However, the application can be decompiled.

So you obfuscate it. Unfortunately, there is no foolproof way to
obfuscate your code, and you run the risk of potentially breaking your code
or changing how it works due to the obfuscation process.

And even then, obfuscation is a cat and mouse game. No matter what you
do (even if you compile a native binary), you will always be able to figure
out what the code is going to do.

Ultimately, there is no way that this will be secure, and the password
administration should be handled by other means.

 

[Family Tree Mike]

What are your thoughts about creating a webservice which returns a random
password, and logs it at "IT Central" tied to the client that got the
password? This was my first thought, and so I'm currious what you think.

Travis,

Ultimately, this is an exercise in futility. The administrators should
be changing the passwords by hand.

Because you don't want the passwords to be in plain text (so others
can't see, I assume), you would encrypt the file. However, to do that, you
need an encryption key. So you embed the encyrption key into the
application (or the application constructs it from other data available to
it). However, the application can be decompiled.

So you obfuscate it. Unfortunately, there is no foolproof way to
obfuscate your code, and you run the risk of potentially breaking your code
or changing how it works due to the obfuscation process.

And even then, obfuscation is a cat and mouse game. No matter what you
do (even if you compile a native binary), you will always be able to figure
out what the code is going to do.

Ultimately, there is no way that this will be secure, and the password
administration should be handled by other means.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hello:

We have a request for an console application to change the
administrative password on our user's machines during an upcoming
update. The console application will be called from a batch file that
the users will be able to see. Therefore, we can't put the user name/
password in the batch file or plain text in the executable. Finally,
the request specifically asked that the executable be configurable so
they can put other user name/passwords in later.

How can I recieve a user name/password and embed it in an executable?
I was thinking of having a separate file with the encrypted data in
it. However, I would prefer for there to be just the .exe. I also
don't want to create an installer, because it is just a console
application.

How do I do it?

Thanks,
Travis

 

[jehugaleahsa]

Why not store it in registry or a similar place?

The registry is too permanent. I am a little concerned putting
anything password-like in the registry, encrypted or not. If an error
should occur, I might end up with that registry key filled even after
my application bombs out. This is meant to be a simple, stand-alone
console application.

Or do you intend to brand the file and then copy it to the target
machine? Perhaps you could just tuck the data onto the end of the file,
like this:

[ exe file contents ][ your data ][ size of your data as Int32 ]

If you build a small program to take the username/password, encrypt it
or otherwise make it less-than-readable, build a byte array, and store
it at the end, you can easily read it back in. The size at the end is
just for simplicity as you can now just read the last 4 bytes of the
file as an Int32, and use that to calculate back into the file.

If I understand, you are suggesting putting extra bytes on the end of
my executable. I suppose that would eliminate the need for a separate
file; however, I am not willing to go to that extreme if using an
application setting file is more approachable. Thanks for the idea
though.

I don't know how this would play with signing a file.

--
Lasse Vågsæther Karlsen
mailto:[email protected]://presentationmode.blogspot.com/- Hide quotedtext -

- Show quoted text -

Thanks for the ideas.

 

[jehugaleahsa]

Travis,

    Ultimately, this is an exercise in futility.  The administratorsshould
be changing the passwords by hand.

I will advise them of your suggestion.

    Because you don't want the passwords to be in plain text (so others
can't see, I assume), you would encrypt the file.  However, to do that, you
need an encryption key.  So you embed the encyrption key into the
application (or the application constructs it from other data available to
it).  However, the application can be decompiled.

That is a wonderful point. I was thinking of having a separate form
modify the app.config file. However, in order for my executable to
decrypt the app.config settings, I would have to have the encryption
key inside or outside of my executable. So then I would need to
encrypt my key . . . and so on.

    So you obfuscate it.  Unfortunately, there is no foolproof way to
obfuscate your code, and you run the risk of potentially breaking your code
or changing how it works due to the obfuscation process.

That is also true.

    And even then, obfuscation is a cat and mouse game.  No matter what you
do (even if you compile a native binary), you will always be able to figure
out what the code is going to do.

    Ultimately, there is no way that this will be secure, and the password
administration should be handled by other means.

I think there is a middle ground of security that will be acceptable
inside our internal network. I will have to discuss this with them and
explain the security flaws inherent in their request. I am sure it
will surprise them. However, I think that they will probably say it is
okay for the encryption key to be visible in the exe, since it is a
degree away from putting the password plain-text. I might suggest
obfuscation as an additional precaution. Sigh . . .

Thanks,
Travis

 

[Nicholas Paldino [.NET/C# MVP]]

You could do that, but then you have to worry about "IT Central" having
the password and how secure that storage mechanism is. The fact of the
matter is that you are storing passwords somewhere, and you have to take
into account the security of that system.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

What are your thoughts about creating a webservice which returns a random
password, and logs it at "IT Central" tied to the client that got the
password? This was my first thought, and so I'm currious what you think.

Travis,

Ultimately, this is an exercise in futility. The administrators
should
be changing the passwords by hand.

Because you don't want the passwords to be in plain text (so others
can't see, I assume), you would encrypt the file. However, to do that,
you
need an encryption key. So you embed the encyrption key into the
application (or the application constructs it from other data available
to
it). However, the application can be decompiled.

So you obfuscate it. Unfortunately, there is no foolproof way to
obfuscate your code, and you run the risk of potentially breaking your
code
or changing how it works due to the obfuscation process.

And even then, obfuscation is a cat and mouse game. No matter what
you
do (even if you compile a native binary), you will always be able to
figure
out what the code is going to do.

Ultimately, there is no way that this will be secure, and the
password
administration should be handled by other means.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hello:

We have a request for an console application to change the
administrative password on our user's machines during an upcoming
update. The console application will be called from a batch file that
the users will be able to see. Therefore, we can't put the user name/
password in the batch file or plain text in the executable. Finally,
the request specifically asked that the executable be configurable so
they can put other user name/passwords in later.

How can I recieve a user name/password and embed it in an executable?
I was thinking of having a separate file with the encrypted data in
it. However, I would prefer for there to be just the .exe. I also
don't want to create an installer, because it is just a console
application.

How do I do it?

Thanks,
Travis

 

[Nicholas Paldino [.NET/C# MVP]]

I was going to say, if they are REALLY going to go down this route, at
least make it harder to get the key from the binary. Don't use managed
code. Write a small native DLL which will generate the encryption key based
on items in the DLL. For example, don't use a constant compiled into the
dll, as that can be pulled out from the .data section of the dll, but
rather, use a bunch of method calls which will cause transformations on data
which will generate the key ultimately.

It's really another layer of indirection, but it's not as easy as
running Reflector on the assembly to get the encryption key.

Of course, then you have to make sure that no one gets their hands on
that piece of code that will produce the encryption key. You could include
it as a module in a multi-module assembly, and then call it in this manner:

http://blogs.msdn.com/suzcook/archive/2004/10/28/249280.aspx

But then that leads to the fact that this can probably be extracted, and
the whole cat-and-mouse game begins again.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Travis,

Ultimately, this is an exercise in futility. The administrators should
be changing the passwords by hand.

I will advise them of your suggestion.

Because you don't want the passwords to be in plain text (so others
can't see, I assume), you would encrypt the file. However, to do that, you
need an encryption key. So you embed the encyrption key into the
application (or the application constructs it from other data available to
it). However, the application can be decompiled.

That is a wonderful point. I was thinking of having a separate form
modify the app.config file. However, in order for my executable to
decrypt the app.config settings, I would have to have the encryption
key inside or outside of my executable. So then I would need to
encrypt my key . . . and so on.

So you obfuscate it. Unfortunately, there is no foolproof way to
obfuscate your code, and you run the risk of potentially breaking your
code
or changing how it works due to the obfuscation process.

That is also true.

And even then, obfuscation is a cat and mouse game. No matter what you
do (even if you compile a native binary), you will always be able to
figure
out what the code is going to do.

Ultimately, there is no way that this will be secure, and the password
administration should be handled by other means.

I think there is a middle ground of security that will be acceptable
inside our internal network. I will have to discuss this with them and
explain the security flaws inherent in their request. I am sure it
will surprise them. However, I think that they will probably say it is
okay for the encryption key to be visible in the exe, since it is a
degree away from putting the password plain-text. I might suggest
obfuscation as an additional precaution. Sigh . . .

Thanks,
Travis

 

[jehugaleahsa]

I actually had a conversation with the other programmer here and was
trying to explain why the idea had a security flaw.

He wasn't trained in security, so he was being rather argumentitive
saying, "Well, that's very unrealistic." I explained to him the idea
"Identify the most likely security threat, mitigating it, repeat." He
even suggested the web service idea on his own. Even before you
posted, I was saying that the password was now traveling over a
network, being stored in a database and even if it was encrypted, the
key would *have* to be in the application.

I explained that we would have to make a few levels of indirection.
Fortunately, I have an encryption library that I wrote that does some
odd string manipulation to generate an x-byte key. So, technically,
the "key" will be plain text in the code, but what is done to it to
make it a real key is "uncertain". However, someone could run my code
using reflection and get it anyway. So I will probably obfuscate it
just for fun.

Thanks,
Travis

    I was going to say, if they are REALLY going to go down this route, at
least make it harder to get the key from the binary.  Don't use managed
code.  Write a small native DLL which will generate the encryption key based
on items in the DLL.  For example, don't use a constant compiled into the
dll, as that can be pulled out from the .data section of the dll, but
rather, use a bunch of method calls which will cause transformations on data
which will generate the key ultimately.

    It's really another layer of indirection, but it's not as easy as
running Reflector on the assembly to get the encryption key.

    Of course, then you have to make sure that no one gets their handson
that piece of code that will produce the encryption key.  You could include
it as a module in a multi-module assembly, and then call it in this manner:

http://blogs.msdn.com/suzcook/archive/2004/10/28/249280.aspx

    But then that leads to the fact that this can probably be extracted, and
the whole cat-and-mouse game begins again.

--
          - Nicholas Paldino [.NET/C# MVP]
          - (e-mail address removed)

Travis,

Ultimately, this is an exercise in futility. The administrators should
be changing the passwords by hand.

I will advise them of your suggestion.

Because you don't want the passwords to be in plain text (so others
can't see, I assume), you would encrypt the file. However, to do that, you
need an encryption key. So you embed the encyrption key into the
application (or the application constructs it from other data available to
it). However, the application can be decompiled.

That is a wonderful point. I was thinking of having a separate form
modify the app.config file. However, in order for my executable to
decrypt the app.config settings, I would have to have the encryption
key inside or outside of my executable. So then I would need to
encrypt my key . . . and so on.

So you obfuscate it. Unfortunately, there is no foolproof way to
obfuscate your code, and you run the risk of potentially breaking your
code
or changing how it works due to the obfuscation process.

That is also true.

And even then, obfuscation is a cat and mouse game. No matter what you
do (even if you compile a native binary), you will always be able to
figure
out what the code is going to do.

Ultimately, there is no way that this will be secure, and the password
administration should be handled by other means.

I think there is a middle ground of security that will be acceptable
inside our internal network. I will have to discuss this with them and
explain the security flaws inherent in their request. I am sure it
will surprise them. However, I think that they will probably say it is
okay for the encryption key to be visible in the exe, since it is a
degree away from putting the password plain-text. I might suggest
obfuscation as an additional precaution. Sigh . . .

Thanks,
Travis