Tuesday, August 15, 2017

Hash vs Encryption

Hashing:  one-way, (fixed length), you can never un-hash...all you can do is compare hash values, because the same hash will be created for the same string.
That's why it is used for passwords.  All you can do is hash the user entered value and see if it matches the stored hash value of the password.

Salting:  What if the user has a simple or common password?  Then the hashes would look the same, and an attacker gaining one would gain access to the other by looking for same hash.  So add another string, called a salt, which is unique per user.

Encryption:  meant to also be decrypted using a key.  That key can be the same for both encrypting and decrypting, or you can have a different one for each pathway.


A hash is a string or number generated from a string of text. The resulting string or number is a fixed length, and will vary widely with small variations in input. The best hashing algorithms are designed so that it's impossible to turn a hash back into its original string.


Hashing is an ideal way to store passwords, as hashes are inherently one-way in their nature. By storing passwords in hash format, it's very difficult for someone with access to the raw data to reverse it (assuming a strong hashing algorithm and appropriate salt has been used to generate it).

When storing a password, hash it with a salt, and then with any future login attempts, hash the password the user enters and compare it with the stored hash. If the two match up, then it's virtually certain that the user entering the password entered the right one.

Hashing is great for usage in any instance where you want to compare a value with a stored value, but can't store its plain representation for security reasons. Other use cases could be checking the last few digits of a credit card match up with user input or comparing the hash of a file you have with the hash of it stored in a database to make sure that they're both the same.


  • MD5 - MD5 is the most widely known hashing function. It produces a 16-byte hash value, usually expressed as a 32 digit headecimal number. Recently a few vulnerabilities have been discovered in MD5, and rainbow tables have been published which allow people to reverse MD5 hashes made without good salts.
  • SHA - There are three different SHA algorithms -- SHA-0, SHA-1, and SHA-2. SHA-0 is very rarely used, as it has contained an error which was fixed with SHA-1. SHA-1 is the most commonly used SHA algorithm, and produces a 20-byte hash value.
  • SHA-2 consists of a set of 6 hashing algorithms, and is considered the strongest. SHA-256 or above is recommended for situations where security is vital. SHA-256 produces 32-byte hash values.


Encryption turns data into a series of unreadable characters, that aren't of a fixed length. The key difference between encryption and hashing is that encrypted strings can be reversed back into their original decrypted form if you have the right key.

There are two primary types of encryption, symmetric key encryption and public key encryption. In symmetric key encryption, the key to both encrypt and decrypt is exactly the same. This is what most people think of when they think of encryption.

Public key encryption by comparison has two different keys, one used to encrypt the string (the public key) and one used to decrypt it (the private key). The public key is is made available for anyone to use to encrypt messages, however only the intended recipient has access to the private key, and therefore the ability to decrypt messages.


Encryption should only ever be used over hashing when it is a necessity to decrypt the resulting message. For example, if you were trying to send secure messages to someone on the other side of the world, you would need to use encryption rather than hashing, as the message is no use to the receiver if they cannot decrypt it.

If the raw value doesn't need to be known for the application to work correctly, then hashing should always be used instead, as it is more secure.

If you have a usecase where you have determined that encryption is necessary, you then need to choose between symmetric and public key encryption. Symmetric encryption provides improved performance, and is simpler to use, however the key needs to be known by both the person/software/system encrypting and decrypting data.

If you were communicating with someone on the other side of the world, you'd need to find a secure way to send them the key before sharing your secure messages. If you already had a secure way to send someone an encryption key, then it stands to reason you would send your secure messages via that channel too, rather than using symmetric encryption in the first place.

Many people work around this shortcoming of symmetric encryption by initially sharing an encryption key with someone using public key encryption, then symmetric encryption from that point onwards -- eliminating the challenge of sharing the key securely.


  • AES - AES is the "gold standard" when it comes to symmetric key encryption, and is recommended for most use cases, with a key size of 256 bits. 
  • PGP - PGP is the most popular public key encryption algorithm. 

Wednesday, August 9, 2017

Bundling and Minification for ASP.NET


Adding Bundling and Minification to Web Forms

My   B/M tutorial provides a good introduction to benefits of Bundling and Minification. You should read it to become familiar with the bundling and minification. This blog will focus on using B/M with Web Forms, my B/M tutorial focused on ASP.NET MVC.
Create a new ASP.NET Web Forms application which targets the .Net 4.5 framework.
Run the application launch the IE F-12 developer tools. Select the Script tab, then use the assets button to view the JavaScript files.
You can select one of the JavaScript files and view it in the left pane. Note the full (non-minimized version) of the files are used.

Creating the jQuery Bundles

Add jQuery, jQuery.UI and jQuery validation to the  BundleConfig class in the App_Start folder. The following code shows the complete class:
using System.Web.Optimization;

public class BundleConfig
    public static void RegisterBundles(BundleCollection bundles)
        bundles.Add(new ScriptBundle("~/bundles/jquery").Include(

        bundles.Add(new ScriptBundle("~/bundles/jqueryui").Include(

        bundles.Add(new ScriptBundle("~/bundles/jqueryval").Include(

        bundles.Add(new ScriptBundle("~/bundles/WebFormsJs").Include(

        bundles.Add(new ScriptBundle("~/bundles/MsAjaxJs").Include(

        bundles.Add(new ScriptBundle("~/bundles/modernizr").Include(

Register the Bundles

The templates create the code hook up the bundle registration in the Application_Start method in the Global.asax file.
void Application_Start(object sender, EventArgs e)

Reference the Bundles

Add the jQuery bundles to the <asp:PlaceHolder > markup as shown in the following code:
    <asp:PlaceHolder runat="server">        
         <%: Scripts.Render("~/bundles/modernizr") %>
         <%: Scripts.Render("~/bundles/jquery") %>
         <%: Scripts.Render("~/bundles/jqueryui") %>
Comment out the jQuery script references in the ScriptManager tag as shown below:
    <form runat="server">
    <asp:ScriptManager runat="server">
            <asp:ScriptReference Name="jquery" />
            <asp:ScriptReference Name="jquery.ui.combined" />

CSS Bundles

Examine the Bundle.config file, which contains the markup to create CSS style bundles.
<?xml version="1.0" encoding="utf-8" ?>
<bundles version="1.0">
  <styleBundle path="~/Content/css">
    <include path="~/Content/Site.css" />
  <styleBundle path="~/Content/themes/base/css">
    <include path="~/Content/themes/base/jquery.ui.core.css" />
    <include path="~/Content/themes/base/jquery.ui.resizable.css" />
    <include path="~/Content/themes/base/jquery.ui.selectable.css" />
    <include path="~/Content/themes/base/jquery.ui.accordion.css" />
    <include path="~/Content/themes/base/jquery.ui.autocomplete.css" />
    <include path="~/Content/themes/base/jquery.ui.button.css" />
    <include path="~/Content/themes/base/jquery.ui.dialog.css" />
    <include path="~/Content/themes/base/jquery.ui.slider.css" />
    <include path="~/Content/themes/base/jquery.ui.tabs.css" />
    <include path="~/Content/themes/base/jquery.ui.datepicker.css" />
    <include path="~/Content/themes/base/jquery.ui.progressbar.css" />
    <include path="~/Content/themes/base/jquery.ui.theme.css" />

You can add your own style bundles to the Bundle.config file.
The following markup shows the CSS bundles and JavaScript bundles referenced. Note that you can multiple bundles in one call to the Render method.
<%: Styles.Render("~/Content/themes/base/css", 
                    "~/Content/css") %>
<%: Scripts.Render("~/bundles/modernizr") %>
<%: Scripts.Render("~/bundles/jquery",
                    "~/bundles/jqueryui") %>

Wednesday, August 2, 2017

Security in .NET

very useful:  http://www.dotnetnoob.com/2013/03/some-important-aspnet-45-security.html

Mar 3, 2013

Some important ASP.NET 4.5 security improvements

The .NET 4.5 framework was released a couple of months ago and it included several improvements in the security area. To benefit from these improvements you need to do a few changes to you application's configuration file. The documentation is a bit scattered over MSDN and MSFT blogs, I figured I'd collect them here for easy reference.

The ASP.NET team published a nice article on What's New in ASP.NET 4.5 and Visual Studio 2012. There you'll learn that:
  • There are changes to the ASP.NET request validation, it now supports deferred (lazy) validation, as well as giving the option to fetch data unvalidated.
  • The AntiXSS library is included in the framework.
However, there's no mention of two other important changes:
To take advantage of these new bits you'll have to do a bit of configuration, we'll get into that right away.

Switching to 4.5
While retargeting a couple of MVC applications to the new framework version, I learned that it's not enough to install the 4.5 framework and change the "Target framework" accordingly. You'll find that a comment appears in the web.config file:

    For a description of web.config changes for .NET 4.5 see http://go.microsoft.com/fwlink/?LinkId=235367.

    The following attributes can be set on the <httpRuntime> tag.


        <httpRuntime targetFramework="4.5" />

It's important that you set the targetFramework in your configuration file, else your application will run in "4.0" mode. Levi Broderick explains the effect of setting this attribute in: All about <httpRuntime targetFramework>.

Enabling AntiXss
You'd want to set the AntiXss library as the default encoder — that can easily be done in the httpRuntime configuration element:
<httpRuntime targetFramework="4.5" encoderType="System.Web.Security.AntiXss.AntiXssEncoder,System.Web, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

Note that there can be side effects to this, as AntiXSS takes a white list approach to encoding. That means that there may be characters that weren't encoded before, that will be encoded by AntiXSS.

Request validation
Lazy validation was introduced in ASP.NET 4.5, I just did some testing on it and it seems that lazy validation is the enabled regardless of how you set the "requestValidationMode", after you've installed the 4.5 framework. However, if you need access to any request parameters unvalidated, you'll need to set the validation mode to "4.5", as such:

<httpRuntime targetFramework="4.5" requestValidationMode="4.5" />

This will give you access to the unvalidated collections of parameters, e.g.:

This is a much better approach than disabling request validation altogether. But use it with care, as always you should throroughly validate the input.

Cryptographic improvements
You read Cryptographic Improvements in ASP.NET 4.5 right? If not, do it now. Seriously!

WIF 4.5
WIF is now part of the framework — that meant some breaking changes. It shouldn't take to much time to upgrade though,  particularly if you're concerned with RP's. There's a great article on MSDN with Guidelines for Migrating an Application Built Using WIF 3.5 to WIF 4.5.

There's two apparent changes I'd like to point out. First, you no longer need to set the "requestValidationMode" to "2.0" to cope with the request validation exceptions on the SignInResponseMessage's posted from an STS. WIF 4.5 plays nicely with the 4.5 request validation. Second, WIF now includes a MachineKeySessionSecurityTokenHandler which encrypts and MAC's WIF cookies based on the machine key. You'll find everything you need to set it up in: WIF and Web Farms.

And that's it. ASP.NET 4.5 includes several nifty security features, put them to use ASAP!