Amazon's EC2 Isn't A Good Windows Desktop

It is tempting to think that you could have a configured Windows desktop computer on Amazon EC2 that you turned on whenever you like paying 12.5 cents an hour, then turned off and have it cost you nothing but storage of the hard drive. This computer you could use as a configured desktop with all your favorite applications installed to check email, do work and that you could access anywhere. However, Amazon EC2 isn’t set up that way; in fact it would be very hard to work day to day on an EC2 machine unless you left it turned on constantly. Here are the reasons that Amazon EC2 doesn’t make a good desktop environment:

• Amazon EC2 only runs Windows 2003 (As of 10/24/2009). Most people are used to a better desktop experience provided by Windows 7, Vista, or Windows 2008 and the Windows 2003 Windows 2003 desktop will feel old to them.
• When you terminate your Amazon EC2 instance (which stops the meter) EC2 deletes the underlying hard drive and everything that you have saved to that drive unless you take the time to bundle the AMI and register it. This really is a drawback, since bundling and registering the AMI (operating system hard drive) can take up to 15 minutes. If you never terminate the instance you can work on it indefinitely, however the meter never stops running.
• Remote Desktop Connection (RDC) is the only way to work with the EC2 computer like a desktop and there are things that RDC doesn’t handle like a desktop computer. You can’t stream video, watch movies, and the updates when browsing appear clunky. There are no burning CDs, watching DVDs, or playing video games.
• EC2 instances do not turn on very fast, sometimes up to ten minutes. The idea that you have a computer that you turn on and off, and only pay for when you used is romantic, however with a ten minute turn on time, you start to wonder why you turn it off.

{6230289B-5BEE-409e-932A-2F01FA407A92}

Shutting Down Windows in Amazon EC2

Restarting Windows in Amazon EC2 doesn't terminate the EC2 instance. This is good to know if you are installing software and wonder will the required restart terminate the instance before you are able to Bundle it into an AMI. The answer is no, restarts don't cause termination. {6230289B-5BEE-409e-932A-2F01FA407A92}

PuzzleOverflow.com

Started a new web site yesterday with an idea from Rob S -- it is called PuzzleOverflow.com and it is using the Stack Exchange technology. Stack Exchange was written by a team at FogCreek Software to run the hugely popular StackOverFlow.com website. Our version of PuzzleOverflow.com is all about asking and getting answers to puzzles, riddle, and brain teasers. The unique feature of the Stack Exchange technology is that it allows the smartest user to rise to the top with reputation. The whole site only took me an hour to configure in that hour I purchased a domain name, started a Stack Exchange instance and added Google’s AdSense to the web site. Promoting the web site will take me much longer then the technology aspect for this undertaking. If you like brain teasers, riddles and puzzle come visit: PuzzleOverflow.com {6230289B-5BEE-409e-932A-2F01FA407A92}

Update To MVC's LogOnUserControl.ascx

Microsoft has this code for the LogOnUserControl.ascx partial control when you create a brand new ASP.NET MVC application:

<%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl" %>
<%
    if (Request.IsAuthenticated) {
%>
        Welcome <b><%= Html.Encode(Page.User.Identity.Name) %></b>!
        [ <%= Html.ActionLink("Log Off", "LogOff", "Account") %> ]
<%
    }
    else {
%> 
        [ <%= Html.ActionLink("Log On", "LogOn", "Account") %> ]
<%
    }
%>

However, this isn't 100% correct. It just so happens that Page.User.Identity.Name in their example is the User's name, however really Page.User.Identity.Name in most cases is a unique (primary) key to a users table. This is a little cleaner:

<%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl" %>
<%
    if (Request.IsAuthenticated) {
%>
        Welcome <b><%= Html.Encode(Membership.GetUser(Page.User.Identity.Name).UserName) %></b>!
        [ <%= Html.ActionLink("Log Off", "LogOff", "Account") %> ]
<%
    }
    else {
%> 
        [ <%= Html.ActionLink("Log On", "LogOn", "Account") %> ]
<%
    }
%>

This change makes sure that we are getting the username (Display Name) from the membership provider regardless of what is used for the key to the provider. {6230289B-5BEE-409e-932A-2F01FA407A92}

The Big Idea : Better Password Hashing

For the last couple of days I have been thinking about how browsers send passwords across the network. I think I have a safer way. I would have to work at Microsoft or Mozilla to get this implemented however, I am content with blogging about it and getting some feedback. This is a line of code that as a web developer I write all the time:

<INPUT TYPE=”TEXT” NAME=”Login” /><br />
<INPUT TYPE=”PASSWORD” NAME=”Password” />

This HTML delivers the login and password to the browser in clear text. The web application takes the password and concatenates it onto a stored piece of random text (called salt) and then hashes the complete string. This hash is compared with the hash store for that login and if they match then the web application can assume that the user knows their password. If the web developer implemented good security for his system then he never stores the password, only a hash of the salt and the password. The salt helps make every hash unique. Why do web developers hash passwords? Well, most people only have four to five passwords that they use on roughly a hundred sites. If one of those sites is compromised and the password is in clear text then that password can be tried on other sites to gain access as that user. It also limits the harm an employee can cause if they have access to every password. Since you don’t know if the web site you are entering your password into is storing it hashed or in clear text it is in your best interest to change your password for every web site. However, keeping track of all those passwords becomes a maintenance nightmare. If you can’t remember them all you will need to write them down – and then where do you store them to keep them safe? So here is the big idea: Why doesn’t the browser hash the password before it sends it to the web site? This way the user would know that the web site couldn’t store his/her password as clear text because the web site would never get the clear text from the browser. The web developer would just store what they get from the browser, the hash of the password and compare that hash every time the user logs in. If the browser is going to hash the password, it has to know the salt in order to create a unique hash. This is the tricky part. Every user needs to have a different salt and that salt needs to be the same for that user every time. The salt can’t change based on browser, or computer, or location of the computer. The salt must be different for each web site – since having the same salt and password would mean the same hash for every web site which is the same security risk as the same password stored as clear text. My suggestion is that the salt be the domain name of the site concatenated with the login. The domain name and the login are known by the browser when the form is submitted; it is always unique per user and would be the same no matter where they logged in from. Plus each salt would be different for each domain. An evil doer that compromised the web application reading the password hash from the web database wouldn’t know the hash for another web site. Basically it is the same as making the browser generate a unique password for every web site. How would the browser do this securly? How would the HTML have to be rewritten (i.e. how does the browser know which input is the login)? Would the DOM restrict client side scripting from reading the password? These are all questions I don’t have the answers for. However, I do know that password handling on hundreds of web site is going to be an issue that needs solving in the next four to five years. {6230289B-5BEE-409e-932A-2F01FA407A92}