Clear Password String in C# Compiled Code

[cooltoriz]

Hello there,

I just found that the compiled code won't hide the string variables so
that I can see them by opening the execuable using Notepad. I have
couple applications that have password hardcoded and I've been thinking
that the string varialbes are hidden in compiled code. I knew that the
VS.NET doesn't compile the source code into machine code. But I didn't
know that it will expose string variables in the compiled code. Here is
my code:



static private string Hello1 = "Hello my world";

private void button1_Click(object sender, EventArgs e)
{

string filePath = @"C:\Windows\Notepad.exe";
string userName = "Username";
string password1 = "MyPassword";


// ProcessStartInfo psi = new ProcessStartInfo(args[0]);
ProcessStartInfo psi = new ProcessStartInfo(filePath);
psi.UserName = userName;

psi.Password = ConvertStringToSecureString(password1);
psi.Domain = "";
psi.UseShellExecute = false;
psi.CreateNoWindow = true;
psi.WindowStyle = ProcessWindowStyle.Hidden;

Process.Start(psi);
}

private static SecureString ConvertStringToSecureString(string
password)
{
SecureString tempSecureString = new SecureString();

foreach (char c in password)
{
tempSecureString.AppendChar(c);
}

return tempSecureString;
}




When I opened the compiled version using the notepad, I see this in the
middle of text:

-- snippet --
ControlCollection get_Controls Add ResumeLayout
WindowsApplication1.Properties.Resources.resources
WindowsApplication1.Form1.resources QW i n d o w s A p p l i c a t
i o n 1 . P r o p e r t i e s . R e s o u r c e s -C : \ W i n d o w s
\ N o t e p a d . e x e U s e r n a m e M y P a s s w o r d
b u
t t o n 1 F o r m 1 H e l l o m y w o r l d As젽???^쩾?
톧\V4?

  

    


!

%
-- snippet --

Clearly, I can see the hello1, filepath, username, password values.
I am using VS.NET 2005 with Framework v2.0. And I found the RunAs code
sample from Web sites. Many sites have the examples.

I have to hardcode the password in my application in SECURE way. Could
someone give me an example or tips? I appreciate your help.

 

[Gabriel Lozano-Morán]

You could use the Cryptography Application Block, and place the encrypted
password in the application's configuration file. Normally I would always
try to prevent hard coded string literals.

Gabriel Lozano-Morán

Hello there,

I just found that the compiled code won't hide the string variables so
that I can see them by opening the execuable using Notepad. I have
couple applications that have password hardcoded and I've been thinking
that the string varialbes are hidden in compiled code. I knew that the
VS.NET doesn't compile the source code into machine code. But I didn't
know that it will expose string variables in the compiled code. Here is
my code:



static private string Hello1 = "Hello my world";

private void button1_Click(object sender, EventArgs e)
{

string filePath = @"C:\Windows\Notepad.exe";
string userName = "Username";
string password1 = "MyPassword";


// ProcessStartInfo psi = new ProcessStartInfo(args[0]);
ProcessStartInfo psi = new ProcessStartInfo(filePath);
psi.UserName = userName;

psi.Password = ConvertStringToSecureString(password1);
psi.Domain = "";
psi.UseShellExecute = false;
psi.CreateNoWindow = true;
psi.WindowStyle = ProcessWindowStyle.Hidden;

Process.Start(psi);
}

private static SecureString ConvertStringToSecureString(string
password)
{
SecureString tempSecureString = new SecureString();

foreach (char c in password)
{
tempSecureString.AppendChar(c);
}

return tempSecureString;
}




When I opened the compiled version using the notepad, I see this in the
middle of text:

-- snippet --
ControlCollection get_Controls Add ResumeLayout
WindowsApplication1.Properties.Resources.resources
WindowsApplication1.Form1.resources QW i n d o w s A p p l i c a t
i o n 1 . P r o p e r t i e s . R e s o u r c e s -C : \ W i n d o w s
\ N o t e p a d . e x e U s e r n a m e M y P a s s w o r d
b u
t t o n 1 F o r m 1 H e l l o m y w o r l d As????^??
?\V4?

  

    


!

%
-- snippet --

Clearly, I can see the hello1, filepath, username, password values.
I am using VS.NET 2005 with Framework v2.0. And I found the RunAs code
sample from Web sites. Many sites have the examples.

I have to hardcode the password in my application in SECURE way. Could
someone give me an example or tips? I appreciate your help.

 

[Rad [Visual C# MVP]]

I have to hardcode the password in my application in SECURE way. Could
someone give me an example or tips? I appreciate your help.

Most good obfuscators offer string encryption for precisely this purpose.
Check out Dotfuscator and Xenocode

 

[rossum]

Hello there,

I just found that the compiled code won't hide the string variables so
that I can see them by opening the execuable using Notepad. I have
couple applications that have password hardcoded and I've been thinking
that the string varialbes are hidden in compiled code. I knew that the
VS.NET doesn't compile the source code into machine code. But I didn't
know that it will expose string variables in the compiled code.

[snip]

One way is to do your own encryption. It will not be completely
secure since anyone who can disassemble your code can disassemble the
decryption function, but it will stop casual readers or a simple
search for ASCII strings being able to pick out the password.


static string codedPassword = "elephant";

static string DecodePassword(string cyphertext) {
byte[] key = { 0x16, 0x1D, 0x10, 0x19, 0x1A, 0x13, 0x0B, 0x18 };
StringBuilder sb = new StringBuilder(cyphertext);
for (int i = 0; i < sb.Length; ++i) {
sb = (char)(key ^ sb);
}
return sb.ToString();
}

static void Main() {
Console.WriteLine("The secret password is: {0}",
DecodePassword(codedPassword));
}

This example uses a simple XOR encryption. I deliberately made the
coded password look like a real word as an added level of
misdirection. The real password does not appear anywhere in the
program file.

An alternative, short of actual encryption, is to put the password
into Base64 in your source file and to decode it as needed. For
example, "elephant" = "ZWxlcGhhbnQ=" in Base64. The disadvantage is
that it is easily recognisable as Base64.

Another alternative is to have a plaintext password in your source,
but to use the Base64 as the actual password within your program.
Have "elephant" in the source, but use "ZWxlcGhhbnQ=" as the actual
password.

Other ideas along these lines are possible.

rossum

 

[Lucian Wischik]

One way is to do your own encryption.
This example uses a simple XOR encryption.

What they often do in unix-land is use the standard crypt() function
for encryption. (instead of simple XOR or whatever). There must be a
..net equivalent somewhere. With the "crypt" function, I seem to
remember, it's not possible to deduce the plaintext password given its
cryptographic hash. You will still be vulnerable to a "dictionary"
attack where the attacker tries every single word in the dictionary
until he finds one that generates the right hash, but that's it.

 

[0xB055]

Hello there,

I just found that the compiled code won't hide the string variables so
that I can see them by opening the execuable using Notepad. I have
couple applications that have password hardcoded and I've been thinking
that the string varialbes are hidden in compiled code. I knew that the
VS.NET doesn't compile the source code into machine code. But I didn't
know that it will expose string variables in the compiled code. Here is
my code:

store the password encrypted instead! take your password in clear-text
and encrypt it with SHA1 or MD5 or something else. Then you store the
hash from your password in the code. when the user enters a password you
calculate the hash from this password and compare it to yours. this is
safe and easy.

alain

 

[rossum]

store the password encrypted instead! take your password in clear-text
and encrypt it with SHA1 or MD5 or something else. Then you store the
hash from your password in the code. when the user enters a password you
calculate the hash from this password and compare it to yours. this is
safe and easy.

alain

Easy, but not safe. This form of password storage is vulnerable to a
dictionary attack. To avoid that you need to add (cryptographic) salt
to the password before hashing, where the salt is different for every
user. See http://en.wikipedia.org/wiki/Salt_(cryptography).

rossum

 

[cooltoriz]

Thank you all for informatoin, I always appreciate your help.

The applications are internal only. Our users only have restricted
privilege and they are remote users. So I am writing an application so
that they can install software using my application that use local
admin account previlege. However, I don't want them to know the account
password.

I was informed that someone tried to open it up using Notepad and found
the password. Since the password is the same as other computers. There
is a chance that he can use it to access other computer. I will change
the admin password and redistribute applications once I change my
codes.

Again, thank you for your knowledge.

 

[Lucian Wischik]

Easy, but not safe. This form of password storage is vulnerable to a
dictionary attack. To avoid that you need to add (cryptographic) salt
to the password before hashing, where the salt is different for every
user. See http://en.wikipedia.org/wiki/Salt_(cryptography).

Can you explain how salt applies here, please? I mean, he's
hard-coding a password in the executable. There are no users, and they
don't type in a password at runtime. So he'd have to pre-salt his
thing before storing it in the executable. And so someone would
disassemble his code, see which salt he's using, and proceed with a
dictionary attack against that salt.

 

[Christof Nordiek]

Thank you all for informatoin, I always appreciate your help.

The applications are internal only. Our users only have restricted
privilege and they are remote users. So I am writing an application so
that they can install software using my application that use local
admin account previlege. However, I don't want them to know the account
password.

I was informed that someone tried to open it up using Notepad and found
the password. Since the password is the same as other computers. There
is a chance that he can use it to access other computer. I will change
the admin password and redistribute applications once I change my
codes.

Again, thank you for your knowledge.

In this case, it is better to not to use the password to authenticate from
outside the system. Not only can your users know the password but anyone who
has access to the executable. You shouldn't undersetimate the chance, the
executable comes into wrong hands. Even if the password was encrypted 100%
safe (wich is not possible), anyone having access to the executable could
gain access to your network through it and make anything your users make.

Instead your users should be mandated to authenticate themselves with their
own account, and then the server part of the application should autheticate
itself against the system with an application-account to have access to the
resources it needs.

Also you surely shouldn't ever give an admin password out of your system, if
encrypted or not.

 

[0xB055]

Easy, but not safe. This form of password storage is vulnerable to a
dictionary attack. To avoid that you need to add (cryptographic) salt
to the password before hashing, where the salt is different for every
user. See http://en.wikipedia.org/wiki/Salt_(cryptography).

rossum

this is true. But it's much better than storing the password in
clear-text and much better than trying to invent an own
'security-by-obscurity'-method to disguise the password. i'm quite
fluent in reading hexadecimal values for instance.

passwords are usually stored in a hashed form in database. this is true
for windows and un*x operating systems (where the database is a simple
file).

thanks for the article anyway. have a nice weekend

alain

 

[rossum]

this is true. But it's much better than storing the password in
clear-text and much better than trying to invent an own
'security-by-obscurity'-method to disguise the password. i'm quite
fluent in reading hexadecimal values for instance.

passwords are usually stored in a hashed form in database. this is true
for windows and un*x operating systems (where the database is a simple
file).

thanks for the article anyway. have a nice weekend

alain

In this case I suspect that hashing the password may not solve the
OP's problem. It seems to me taht the password is not the user's
password, but something like a database password that the OP wants to
use to connect to a database in the background without involving the
user. Depending on how much control the OP has over the database
password the requirement may be for some sort of *reversible* way to
hide the password, which would rule out a hash.

rossum