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

Tech-Archive recommends: Fix windows errors by optimizing your registry

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


On Jan 8, 9:52 am, "Nicholas Paldino [.NET/C# MVP]"
<m...@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
    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]
          - m...@xxxxxxxxxxxxxxxxxxxxxxxxxxx

<jehugalea...@xxxxxxxxx> wrote in message

news:7f235abb-5db3-4211-bc1a-b5f55a3b45bd@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Jan 8, 8:37 am, "Nicholas Paldino [.NET/C# MVP]"

<m...@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
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

.

Relevant Pages

  • New Tools from Imperva ADC
    ... Imperva's Application Defense Center has released two new security ... This can be useful for identifying a dll that is related ... existance of an encryption key inside an executable file (based on Adi ... Shamir's "Playing hide and seek with encryption keys"). ...
    (Pen-Test)
  • Re: As related to you: Firing M. hyden to uphold mission and policies of CIA
    ... by the President returnee Agnes E Cherry (dormant as of February 20, ...    (cHECKED AND RECHEKED THAT MR HYDEN AND OR PRESIDENT BUSH WILL ... Issues of CIA confidentiality are observed; ... security functions, mission and execution of these, upon detailed ...
    (soc.culture.europe)
  • RE: Decrypt File
    ... Windows uses a fairly secure symmetric encryption key to ... public/private key pair (certificate) that the user then has access to. ... Subject: Decrypt File ... > Thinking About Security Training? ...
    (Security-Basics)
  • Re: Why is the national press (Fox, too) silent about the Pentagon-White House "retired general"
    ... are responsible for the security of the United States thought about ...   Info-war. ... At the end of world war two the United States abandoned democracy. ...
    (alt.politics)
  • Microsoft Security Bulletin Summary for April 2005
    ... Microsoft Security Bulletin Summary for April 2005 ... This advisory contains information about all security updates ...   valuable information to help you protect your network. ... reporting an issue described in MS05-021. ...
    (microsoft.public.windows.server.general)