Dan Sellers's WebLog : ASP.Net Security Series (Part 1 of 3)

Dan Sellers's WebLog : ASP.Net Security Series (Part 1 of 3)

.NET Obfuscator- NGEN

Why can't I just use NGEN to compile my assemblies into a native code before shipping to my customers?

Even if an application has been compiled to native code, the .NET Runtime still requires that the complete metadata and IL be included in an assembly before it is allowed to execute. So using NGEN does not protect your intellectual property at all! In addition, NGEN code suffers from other problems including:

* NGEN'd code may lose some of the advantages that .NET gives you (eg, platform agnosticism, verifiabilty, interoperablilty)
* NGEN'd code cannot be signed and there may be security difference compared to managed code.
* NGEN'd code is harder to administer because it not automatically deleted when an assembly is uninstalled.
* NGEN'd code is brittle. It must be re-JITed every time the environment changes, which is why the metadata is still required.

Strange Memory Behavior when Minimizing Applications

robgruen's WebLog : Strange Memory Behavior when Minimizing Applications on Windows XP

What you are seeing is expected behavior. Here's a recap of scenario two: Your application loads and its memory footprint grows so the OS allocates larger chunks of memory to it because it has memory available. If you attach perfmon to your application you'll see the working set and the private bytes increase however most likely the growth between the two counters will not be linear (working set will grow faster than private bytes). Then the app gets minimized....



At this point the os flushes all of the unused memory pages (those not doing any work) of your application to virtual memory (the paging file) and most of the working set is released back to the OS for use in other applications because your app isn't doing anything and no longer needs it. Hence the decrease to .82MB, most likely this is the memory for the message pump for the application and possibly the main window and it's resources. Then the application is reactivated...



The cpu starts running instructions on your process and pages are fetched from the paging file as necessary. Since the OS has already loaded most of your application and recognizes that your application is not allocating more memory, it (the os) only allocates very small/if any amounts of working set to your app. That is why it is now at 2.5MB instead of 16MB.





The best way for you to view this is to use perfmon and watch working set, virtual memory, and private bytes while you do scenario 2 from your mail. You'll see the behavior I describe above. In a citrix enviroment you'll see tha the OS is more sparing with the working set as more and more users consume more resources.

Challenge-Response

The client sends the username to the server. The server creates a second random salt which is NOT stored in the user list. This random salt is used only once -- we either make it so big that odds of generating it again are low, or keep a list of previously used random salts and pick a new one if we have a collision. We'll call the random salt "the challenge" for reasons which will become apparent in a minute.

The server sends the user's password salt and the challenge to the client. The client appends the password salt to the password and hashes the salted password. It converts the salted hash to a string, appends the string to the challenge, and hashes the resulting string to form the "response" hash. The response is sent across the wire.

The server then does the same thing – converts the stored salted password hash to a string, appends it to the challenge, and hashes the resulting string. If the response from the client is equal to the value the server just computed, then the client must have computed the same salted hash, and therefore knows the password.

Now what does the eavesdropper know? The eavesdropper knows the username, the password salt, the challenge and the response. The eavesdropper has enough information to launch an offline dictionary attack against that user. But since the random challenge is never going to be used again, the fact that the attacker knows a valid challenge/response pair is essentially irrelevant.

This system has the downside that an attacker who gets the password file has obtained password equivalents, so no dictionary attack is necessary. (Unless of course the attacker is trying to determine a user's password in order to try it against the user's account on a different system!)

Fortunately, these weaknesses can be mitigated somewhat by changing your password frequently, not using the same passwords for different accounts, never using common dictionary words as passwords, and making passwords long -- passphrases are better than passwords.