The Waffleshop

To follow ASP.NET MVC best practices, you should put all static content files in the Content directory. However, this doesn’t play nice with favicon.ico, which is expected to be in the root of your domain. The solutions to this problem that I have seen online the most are to just put favicon.ico in the root of your project and tell the routing system to ignore it.

I came across a different solution: a custom route handler that can be used to redirect to the file in the Content directory:

Using this class, you can set up a route like the following, that will (internally) redirect requests for /favicon.ico and serve the file out of your Content directory.

RouteTable.Routes.Add(new Route("favicon.ico", new StaticFileRouteHandler("~/Content/favicon.ico")));

Kudos to RandomBen for the StaticFileRouteHandler class. I rewrite it a bit and adapted it for use in MVC to use the Content directory.

While filling out my wife’s FAFSA, I was asked to enter a password in case I decided to save my progress and come back later. However, beside the password entry box was the dreaded limitation: 4 to 8 characters.

This limitation of 4 to 8 characters eliminates all of the passwords I routinely use, which means that once again I would have to come up with a new password for a new web account. Now, FAFSA is probably not the best example, since it should probably have its own password anyway – financial institutions should always have a unique, strong password.

Most other websites I visit, however, do not warrant a unique password; I have neither the memory to remember them all nor the will to try. When a website comes up that demands I create an account but impose password limits that eliminate my common passwords, I facepalm. Then I usually just leave the site.

The biggest reason for my annoyance at this is the face that it is completely unnecessary – when a password is entered into a website it should always be stored as a hash. For those of you who are not programmers, ‘hashing’ a password is a method of turning your password into a series of letters and numbers. You can go from a password to a hash, but you cannot reverse the process – once you create a hash of a password you can not (easily) get the original password back.

This is an excellent security measure – if the database containing user names / passwords is ever compromised, the attacker will not have a simple list of usernames and the corresponding password. More relevant to this rant is the fact that hashes are the same length, no matter what the password is – so why limit how long my password can be?

If you limit my password length, I assume that the password is not being hashed. If it was, why impose a limit, since you will have to store the same amount of data no matter what the password is? Just let me use one of my ‘throw-away’ passwords – passwords I use for the accounts I would not be terribly hurt if they were compromised. Honestly, I’m not going to make up a new password for every account on every website that I visit. It would be nice if more websites used a common authentication service, but thats an article for another time.

Technical Note: What I said above about hash functions being one-way is true; there is no method you can apply to a hash to get the original data (in this case, password) back. However, there are techniques for finding this out anyway. Hash functions can be brute-forced – that is, you can generate the hash for every possible password, and when you find a hash that matches you have a possible password match.

Hash functions are many-to-one functions; that means that many passwords will give you the same hash. Brute force methods could just give you a ‘collision’ – it may or may not be the original data, but it has the same hash and thus can be used as a substitute for the original data.