Channel 9 - Discussions by dwoodard

Tech Off - Pass hashed info through query string

dwoodard — Tue, 07 Mar 2006 15:55:32 GMT

It doesn't matter if you are using HTTP GET or POST. If you are passing the hash on an un-encrypted channel, then the hash can be viewed and stolen.

All that is being hidden is the plain text password. Which means that an attacker doesn't know your password, without cracking it. But if the hash is used for authentication or re-authentication then the attacker can simply pass the stolen hash around to get access.

That is why I mentioned using SSL.

Tech Off - Pass hashed info through query string

dwoodard — Tue, 07 Mar 2006 14:43:27 GMT

Unless you are using SSL, you realize that this is not secure? A hacker wouldn't need to do anything but capture the hash and that would be as good as having the password itself.

Tech Off - Clear All Textboxes On A Form

dwoodard — Tue, 28 Jun 2005 19:44:52 GMT

I am using recursion. I was just trying to avoid the time when a TextBox can contain other controls. Whis is terrifying, but possible in Avalon.

Your version certainly works though.

Tech Off - Clear All Textboxes On A Form

dwoodard — Tue, 28 Jun 2005 16:04:08 GMT

Not to beat a dead horse, but if you are looking for a slightly more generic approach, you could write something like this.

private void ClearTextBoxes(Control parent)
{

    if(parent is TextBox)
    {
        //using String.Empty is better than ""
        //because it is static so there is only one allocation
     parent.Text = String.Empty;
    }

    foreach(Control control in parent.Controls)
   {
        if(control is TextBox)
        {

            control.Text = String.Empty;
        }

        if(control.Controls.Count > 0)
        {
             ClearTextBoxes(control);
        }
}

This would allow you to pass in the parent form, a single tab, a group box a panel or whatever control that could possibly contain a text box.

Perhaps it is overkill, but since you asked.

Tech Off - Why dont Micorsoft use windows forms?

dwoodard — Thu, 09 Sep 2004 05:44:28 GMT

You bring up some good questions.

There is a lot of .NET / Windows Forms work going on within Microsoft. I can't speak to the teams I don't work on, but my team is in the process of writing a 99.99% NET WinForms smart client application that is due to ship midyear 2005. We can't make it 100% due to some legacy interop constraints.

I work in Microsoft Business Solutions and a number of products in that division are going through the .NET paces.

In my specific silo of Business Solutions, we have already shipped 2 Windows Forms applications and have one more in the design phase.

From my perspective (not MS hype), Windows Forms has provided my team a great productivity boost as well as a huge improvement in design / code quality over our legacy application (classic ASP, COM etc.).

I'm sure other teams have their reasons to not port to windows forms (legacy code size, development life cycle, longhorn / Whidbey sync etc.).

Tech Off - Object Orientated Design Question

dwoodard — Tue, 22 Jun 2004 20:52:45 GMT

While this posting doesn't specifically discuss solution design, it does discuss the performance implications of single assembly vs. multiple assemblies.

http://blogs.msdn.com/junfeng/archive/2004/02/23/78139.aspx

Junfeng Zhang works on the Fusion team and has some good insights.

The bottom line is one assembly is better from a performance perspective than multiple. However there are other benefits of multiple assemblies such as increased modularity and extensibility to name a few.

-dan

Coffeehouse - Least Privilege in Longhorn

dwoodard — Fri, 11 Jun 2004 15:18:36 GMT

From my barely posted to blog ...

Here is a good article on MSDN about running as a non administrator. I personally never run as an admin (well accept on virtual images) and it is not as difficult as you might think.

The good thing is as a developer, I don't have to worry if my code will run if the user is not an admin because I have unit tested the crap out of it that way.

Keith Brown of course has some good tips as well. http://www.develop.com/kbrown/book/html/lifestyle.html

Coffeehouse - Least Privilege in Longhorn

dwoodard — Mon, 26 Apr 2004 16:53:18 GMT

There is some great work going into Longhorn around least privilege.

http://msdn.microsoft.com/longhorn/default.aspx?pull=/library/en-us/dnlong/html/leastprivlh.asp

One thing that sounds interesting here is the concept of the "Protected Administrator". The protected administrator allows you to login as an admin, but only applications that are blessed as administrative applications will run under an administrative token. All others will run with least privilege.

Of course we should all be writing our non admin applications using LUA. But the protected administrator may make it possible for my Mom to run her applications safely.

Too bad this didn't make it into XP SP2 (Nice pop-up blocker BTW!).

-dan

Coffeehouse - Do you login as admin?

dwoodard — Wed, 07 Apr 2004 22:01:21 GMT

I do not run as admin at home or at work. As a developer, I have been living Keith Brown's developer lifestyle for quite a while. I only switch to admin when I need to be an admin. I think this is very important for developers to do as it exposes security issues early in the dev cycle. I'm currently developing on Windows 2003 as a non-admin and have stumbled across a few issues that some of my admin-running collegues would have never found.

A previous poster said a well designed network will make this easier for you and that is true. Even here at Microsoft, some of our IT applications require administrative privileges to run (Try submitting your annual review without being an admin). The cool thing though is that when you bring it up to the IT staff they are very receptive to it and willing to try to resolve the issue.

My biggest issue with the non-admin thing is that you need to have a fairly high degree of technical sophistication in order to accomplish this. While the security enhancements for Windows XP SP2 are great for notifying the user about certain unsafe actions. A lot of the actions require you to be an administrator (installing ActiveX controls for example).

In my example of our annual review tool problem, I had to run Internet Explorer as an administrator then provide my network credentials to access the tool. That worked fine for me, but good thing my grandma wasn't trying to do the same thing!

The problem as I see it, is with conflicting agendas. We want people to be admins to perform admin tasks (install programs, update the registry etc.) but we don't want to require our users to be administrators to read their email. ClickOnce deployment should help somewhat in this area, but you still have the issue of deploying CAS policies. I would love to see Longhorn nail this issue down so that it is easier for users to not run as admin.