System Admin for Developers
Jeff Atwood shows us why we should consider better password policies when developing applications or setting company policy.
As we know, the biggest threat to security is not hackers, but the users themselves making it easy for someone to gain access to protected resources by having ridiculously easy to guess passwords. As developers we are as much at fault for building applications that allow this behavior. Jeff recommends using pass phrases instead of passwords. A phrase is longer (and thus more resistant to brute force) and easier to remember than a mixed up jumble of nonsensical characters. By adding an unusual word or character pass phrases are very difficult to break with dictionary attacks as well. Pass phrases are controversial as well, see:
The Great Debates: Pass Phrases vs. Passwords. Part 1 of 3
The Great Debates: Pass Phrases vs. Passwords. Part 2 of 3
The Great Debates: Pass Phrases vs. Passwords. Part 3 of 3
Personally, I think the hard part is convincing users and business owners of an application that longer or more complicated is better. From my own experience I understand users want the simplest password policy possible. Often the business owners of an app don't feel the information being protected is all that important to justify such an imposition for the users, or feel that it becomes a support expense because users can't manage their own data or password very well (a great argument for using something like Windows CardSpace). I think they forget that users re-use the same password everywhere possible: a free e-mail account, network access at work, bank web sites, a blog, a MySpace account, etc. I would not want to be responsible for a malicious person to gain a password from my system and then use that password to systematically destroy someone else's life. Be strong, insist on good password policy.
Doh! Another simple thing I wish I knew (or thought of) previously: Using RunAs to connect to SQL Servers in other domains
On a new server install, you can copy over the files for your web app and mysteriously get 404 errors. It's a simple configuration in IIS. By default the server is configured not to allow ASP.NET. You simply need to enable this in the IIS management console:
Yahoo posted a list of rules for improving the performance of your web site, along with a new FireFox-based tool for diagnosing your site's performance, called YSlow.
Their number one rule is to reduce the number of HTTP requests, and this only makes sense. I'll bet most of us ASP.NET developers are well aware of output caching, and how to do this in code. But what about those static files, like images and scripts? Well, there is an IIS setting for that. It's easy to do, and the payoff can be big if you have a very graphic-intense site. Here's what you do for IIS 6:
- Open the IIS Management console
- Find the directory containing your images (static content only)
- Right click the directory, and choose Properties.
- Click the HTTP Headers tab.
- Check the Enable Content Expiration check box.
- Click the Expire After radio button, and choose an interval.
- Click the OK button. Done!
The downside is that you won't get the payoff for the first time a user visits the site, but other pages using the same resources will be much snappier. Be aware that caching dynamically created content this way can cause some strange issues, so take care as to what you cache. As always, test it well before you release it and you will be rewarded.
I blogged previously about some
issues with SelfSSL and multiple web sites. A colleague of mine,
Charles Medcoff, blogs about a related problem with
SelfSSL and SQL Server.
Learn how to leverage Active Directory in your .Net apps:
The .NET Developer's Guide to Identity
IISToolshed - thanks to
Paschal for pointing it out.
SelfSSL is a tool found in the IIS 6.0 Resource Kit. It allows you to generate SSL certificates for a development environment. In all the instructions for using SelfSSL, it describes one of the parameters as "Site ID", where the default value=1, which is the default web site installed on the computer. The Site Id parameter is essentially telling SelfSSL which web site to install the certificate into. Well, if you have multiple web sites, then the default site id is useless. You need the Site Id of the web site where you want the certificate installed. Of course the documentation does not spell this out, and as a non-Admin the Site Id was not an intuitive term for me. But I found that there is a script you can run from the command-line called iisweb.vbs using the /query switch. That will tell you the Site Id. Seeing that, then I realized that the IIS log file folders (in windir\System32\logfiles\) are named according to the Site Id.
Anyway, creating a second certificate for a different site on the same IIS using SelfSSL messes up the SSL cert of first site. This is a known issue apparently, and David Wang has a great post on this problem. The comment further down by Paul Carrig is most useful, as he points out there is a workaround for the SelfSSL and multiple site issue. So I actually found two workarounds:
- The technique described by in the aforementioned post:
- Install the cert in the first site
- Export it to a .pfx file
- Install the cert in the second site
- Remove the cert from the first site
- Re-Import the cert to the first site using the .pfx file
or
- Install the cert in the first site, and export it to a .pfx file. Then import that to the other sites. The down side to this is that the certificate is even less valid for the second sites as now it has an untrusted publisher (me!) and the site name is not a match. The prompt is essentially the same, but in our case one site contains web services which will throw an error if the prompt comes up at all (as it should). The workaround for that is to install the certificate on the client computers as well, which is an acceptable problem for a development enviroment.
Having to excecute hundreds of .sql files in an environment without port 1433 open led me to this nugget of a Usenet post: How to execute multi-file.
Here is the gist of it, the command line for executing all those .sql files with osql:
FOR %i IN (*.sql) DO OSQL -n -U sa -P sapassword -d databasename -i %i
I am sure I could have merged them all into one file or made some sort of batch vbs, but this did the trick nicely.
We have been using Virtual PCs to host a separate development environment. Some of the team members have been having sporadic network issues with SourceSafe on the Virtual PCs. They were unable to get all of the projects involved down to the Virtual PC without getting a “Network Not Found” error. Eventually they would get all the files, but it was clearly not the best situation.
The Virtual PC image was sysprepped before distributing it, to avoid network problems. Unfortunately, that is not completely the case. Sysprep does reset the MAC address on the Virtual PC, but it apparently happens when sysprep runs, not when the user is re-setting up the PC. After distributing the image, the subsequent users still had the same MAC address. This was causing network problems when more than one person were using the Virtual PCs at the same time. The problem manifested itself mostly with SourceSafe, especially when there was a large change and multiple users were getting all the latest files at the same time.
At least the solution was simple once we realized that the MAC address was the issue (thanks to an astute network admin who had noticed some problems with a particular MAC address on one of the switches). In the .vpc file (it's XML), there is an entry for ethernet address. It contains the MAC address the Virtual PC uses. If you remove the data from the tag, leaving the empty tags, Virtual PC will auto-generate a new MAC address the next time it starts up. Since that change the “Network not Found” error has disappeared.