In a former life I was a network guy. In that time I saw the rise switches instead of hubs for networks. For those of you who were not networkers here is the definition:

Hubbed Network
The hub is a device that acts as a repeater out to the other connected computers. If I am trying to talk to Joe’s computer every other computer receives that information. The other computers investigate the packet and drop it as it is not destined for them. Joe’s computer accepts the packet as he says it is for him.

Switched Network
The switch is a smarter device that knows which computers are connected to it and which port on the switch they are plugged into. When a packet is sent the switch looks up the destination and sends the proper destination port.

For those of you that have run a packet sniffer on a hubbed network you will see all the traffic from all computers. Some of these things include email messages and passwords (yes POP3 sends your password in plain text over the wire), instant messaging conversations, oh and maybe some actual work documents being passed around.

When you run a sniffer on a switched network all you see is the traffic from your computer to the destination. This is because the switch is being the traffic cop and redirecting everything properly.

Switches were invented to be traffic cops, not security cops. It is actually fairly trivial to trick the switch into thinking that either you are the intended destination (via ARP poisoning in the initial traffic notification) or to convince the router that one computer is hooked up to the switch twice (via MAC address duplication). It is also possible to flood the switch until it crashes and fails open into a hub configuration until the flood stops.

If you want more technical details sans.org has a good article here:
http://www.sans.org/resources/idfaq/switched_network.php

   While .NET does a lot of great security things for us one of the things it lacks is an easy way to do input validation. To that end I created a control with some common validations built right in (note that these are server side validations that are only evaluated on post back).

It is easy to provide your own custom validation  as well:

By default if validation fails the control will throw an exception upon postback. You can change this behaviour by changing the notification type to raise an event or do nothing (doing nothing is not recommended and is in place in case you wish to temporarily disable validation).

I also built a http module for this project that will throw an exception if a textbox is found on any page before it is sent to the browser. This forces me to use the validating text box all the time (which I should be doing anyway). This is more of a development module and I would remove it for production myself to avoid the performance impact of inspecting every form before it is sent to the browser.

<httpModules>
  <add type="Solidhouse.Validation.WebControls.ValidationEnforcementModule,
  Solidhouse.Validation.WebControls" name="ValidationEnforcementModule" />
</httpModules>

TODO

-Add logging functionality. There will be a dialog where you can add logging channels upon a validation error. This is helpful to spot either a validation that is too restrictive or to see if someone is trying to exploit your site.

Again this is alpha software I came up a few nights back so use at your own risk. All feedback is appreciated.

In a lot of my talks I harp on the fact that using Random.Next() is not actually all that random. The data for Random.Next() is based off of seed data. If the same seed is specified (as you can do in the constructor for Random()) you will get the same outputs every time.

Random random = new Random(27);
for (int i = 0; i< 5; i++)
{
     Console.WriteLine(random.Next(50));
}

Every time I run this code I get: 41, 36, 32, 16, 19

The reason for this is that the generation of the next random number is based on the last number generated (or the seed data if no number has been generated yet).

Now I have not dug into the source code of .NET but I assume like most other languages it uses the linear congruental method that will allow the creation of a fairly randomly distributed range of numbers.

Here is a home grown random class using this method:

Public Class Random
{
    private int lastNumber;
    public void Random(int seed)
    {
         lastNumber = seed;
    }

    public int Next()
    {
         lastNumber = lastNumber * 106 + 1283
         return lastNumber % 6075;
     }
}

Now in .NET the Random() constructor has an option to take no parameters. It internally generates a seed for us. Many other programming languages default the seed to 0 if not specified which would just generate the same numbers over and over again.

This is why I state not to use Random() if you need strong random numbers.

Now the cryptographically strong random numbers are generated in a slower but more…. random fashion by incorporating more entropy into the system (entropy is the disorder or randomness in a closed system). Some of these include:

-The process/thread ID

-Current Time

-Some performance counters

-System info (cpu/memory/page file state/about 100 more)

-About 10 more items

By using all this we get seed data that should statistically never happen again. But by polling all of these sources there is the performance hit.

If you need strong random data please use the System.Security.Cryptograhy.RNGCryptoServiceProvider