Posterous theme by Cory Watilo

Pretty Good Passwords

=The importance of passwords= 

Passwords are one of the most important pieces of the security puzzle when it comes to protecting your online assets. Passwords are one of the most frequently targeted vulnerabilities by the bad guys, and for good reason. Most of the time, your password is all that stands between your bank account and the bad guys. To them, if they can't scam you into giving them your money, taking it from you is the next best thing. Keyloggers, trojans and other malware exist precisely for getting at your password.

=Pretty good passwords= 

You'll hear people talk about the importance of strong passwords. In reality, truly strong passwords are a pain in the butt because they end up being impossible to remember, or at least, very difficult. We all want our online accounts to be secure from the bad guys, but we don't want them to be secure from us!

Strong passwords are important but in the everyday world they have to be balanced with the practical need of being accessible to us while still being inaccessible to others. Because there are more secure kinds of passwords that I don't recommend for practical reasons, I humbly call my recommended password method "pretty good" passwords. In the first place, most of us have pretty terrible password practices by comparison, so even pretty good passwords are a big improvement.

What makes a pretty good password? Pretty good passwords actually incorporate a lot of the attributes of really strong passwords. They:

* are long, at least 8 - 12 characters if not more
* contain a combination of upper and lower case letters, punctuation and numbers
* are different for every account you have

That's a tall order!

In addition, pretty good passwords have one important attribute that most strong passwords don't:

* easily memorable

Also, your password practices should add to the strength and usability of your passwords:

* passwords are never reused
* passwords are changed at least once a year
* passwords are kept written down somewhere safe and accessible

Why all that stuff? Well, generally speaking there are four methods for "cracking" a password:

* steal it, by whatever means
* guess it by knowing something about the person who made it
* guess it using a "dictionary" attack that looks for passwords made from words from the dictionary or other "words" (like people names)
* guess it using a "brute force" method where you just keep trying different combinations of letters and numbers until the system gives you a match

The first method, stealing, is cause for concern. Keyloggers and trojans try to steal your password by installing themselves on your system, so good antivirus is essential in preventing these. Some websites appear legitimate but aren't, hoping that you will use the same password that you use with other accounts to register on theirs. Finally, hackers can attack a legitimate website in the hopes that the users' passwords aren't kept securely there. While you can't necessarily prevent these last two methods from getting your password on those sites, you can protect your other accounts by using different passwords on every site. That way one password being compromised doesn't open the door to the rest of your accounts.

The second method, guessing your password by using your knowledge about you is usually reserved to your circle of family and "friends". We won't worry about this much, but there are three important things you can do to avoid this. First, don't use an obvious password, such as a pet's name. Second, treat your passwords as sensitive information. Don't leave them lying around, don't share them with anyone and change them on a regular basis (yearly or more frequently). Finally, if more than one person uses your computer, make separate accounts and use a password to protect your account. Also make the user have to enter the password when the computer comes back from the screensaver.

The third method, using dictionary attacks to guess your password, is a favorite method used by password crackers. Even simple modifications of words, such as the infamous "password1" get quickly cracked this way. The best way to protect your password against this is to not use real words as your entire password. It's unfortunate, because words are the easiest passwords to remember, but you can still use them if they are only part of a more complicated password which isn't in a dictionary.

The last method, brute force attacks, are simple to defeat, but come at the cost of usability. Brute force attacks simply try to guess every possible password combination there is. While this may take a long time, computers are pretty powerful at doing this under the right circumstances. Password length and "complexity" are the only effective deterrents to a determined and resourceful cracker. Unfortunately, an 8-letter password is no longer effective at stopping this method. You should be using a password that contains more than 8 characters, preferably 12 or more. You can see why this is harder, both on the plus side for cracking it as well as the minus side for remembering it. Also, since crackers prioritize what characters they use in their guesses, trying all lower-case letter combinations first, you want to include less-anticipated characters in your password. Banks and other security-conscious institutions often make requirements that you use numbers, punctuation and/or capital letters in your password for this reason. While they can still be guessed, using these characters usually makes sure that it takes longer rather than shorter for your password to be cracked. Sometimes all you need is to be more secure than the next guy to avoid attack.

=Creating Pretty Good Passwords= 

Here is the method I use for generating my passwords. It meets the criteria of:

* is long, at least 12 characters in general
* contains an upper case letter, two numbers and punctuation
* for the most part, not based on a dictionary word
* is memorable (to me) and I think for most people
* is different for every account

The other requirements about having it written down and changing it regularly are up to you, so don't forget to pay attention to those no matter how you make your actual password.

Before I go into the steps, a word about diversity. Diversity in passwords is a good thing. As soon as I describe how you make my password, I make it easier for the bad guys to target that method by making their cracking method smart to it. Unfortunately, that's the bad thing about trying to come up with a single method. The act of explaining the method itself weakens it.

However, it's still a good thing to use a known method, as long as it's stronger than the password you would otherwise use. So I still recommend this method, but I encourage diversity. Feel free to change the method to suit you, as long as it still meets the basic criteria. For example, instead of using your birth year for the digits, use a two-digit number that means something to you. Diversity can strengthen your password by making it more unpredictable.

The only thing I wouldn't recommend changing is that the site-specific part of the password should come near the end. The reason is that because some sites limit the length of your password, you don't want the password cut down to the point that it only contains the site-specific part. If it were, it would probably no longer meet the capitalization, number, punctuation and dictionary requirements.

The last thing I'll mention is that I checked my financial accounts first to see that this method would generate an acceptable password. This method isn't useful if you can't use it on your most important accounts, and financial accounts usually have the most stringent requirements. You may want to check your bank's password requirements before you use this method. If you need to make modifications, do so beforehand.

Here are the steps I use:

1. Come up with a random, memorable word that's six letters or more.

I use http://watchout4snakes.com/CreativityTools/RandomWord/RandomWordPlus.aspx. I like using this site because you can adjust the "commonality" of the word. I crank it up high and bring it down if it comes up with words I can't remember. This ensures that you won't use a common word that crackers guess easily.

2. Capitalize the word and cut it down to the first five letters.

If cutting it down to five letters yields a regular word instead of just a fragment, go back to step 1 and choose another word.

This gets you the capital letter requirement. It should also make it a non-dictionary word. While this offers limited protection, since crackers will also try word fragments, it adds strength compared to using a full word. Additionally, this won't be the whole password, so the other parts of the password protect from dictionary attacks as well.

3. Add your birth year as two digits at the end.

While this is very predictable as a number, it's only part of a larger password, so this is another compromise for memorability. You should be able to remember your birthday, right? If you can think of a different, just as memorable two-digit number you'd like to use, feel free to do so in the interest of diversity. You can also place it before the word instead of after. Once you pick a rule though, stick with it so you don't get confused the next time you make a password.

4. Add a period to the end of it.

This gets you the punctuation requirement. Again, you can pick another punctuation mark or symbol and place it earlier in the interest of diversity, but stick with your rule. Also, there are punctuation marks that you *don't* want to use, despite what some people say. Computers are notoriously bad at correctly using spaces in something that's supposed to be a single "word". Don't tempt fate by using spaces, since you don't want to be the one to discover some website's bug that accidentally locks you out because of it. You also want to avoid "SQL characters", which include ";", single- and double-quotes and "%". The reasons for this are arcane, but it's just a good idea. I like using "." (without quotes) because it's safe and easy to type.

What you have now is your base password. It's the unchanging part of your password that isn't specific to a particular site you're visiting. It satisfies the requirements for not using dictionary words, for using upper case letters as well as numbers, and for punctuation. Additionally, it should be eight characters long, which is the minimum required password length for most sites. If for any reason you can't or don't want to make the password site-specific, you can use this base password by itself without being completely exposed.

The final step is to make site-specific versions of this password for each site where you have an account. Before we do this, however, take the following steps for securing this base password so you don't forget it, which is a frequent problem with new passwords.

Write down your base password in two places. First, write it on the back of a business card you keep in your wallet, someplace you won't clean out, such as behind your driver's license. Second, write it down on a piece of paper, card or address book that you keep in the same place with your valuables, such as a fire safe. This takes care of the writing down requirement.

5. When you visit a site to create or change your password, double-click the site name in your browser's address bar, then copy and paste it onto the end of your base password.

Let's say you visit www.google.com. When changing your password there, first enter your base password, then double-click the "google" in "www.google.com". Double-click automatically highlights the entire word "google", which you can then paste onto your base password. Ctrl-C is the keyboard shortcut for copy and Ctrl-V is the shortcut for paste.

One important thing to note is that different browsers capture different amounts of the site name when double-clicked. Internet Explorere, for example, only captures "google", while Google Chrome captures "google.", with the trailing period. It is important to know which your browser does so you can write it down properly. I use Chrome, so I always remember the trailing period when I write down a password. (Don't rely on this period to take the place of the punctuation requirement though since some sites cut it off.)

What does this accomplish? Two things. First, it makes your password specific to that website, which means that when someone cracks your password, if they blindly enter into your account on another website, it won't work. This protects you from automated attacks. For example, an illegitimate site that tricks you into registering may turn around and automatically try to log into your email and Facebook account with the password you provided. Your password won't work, so it defeats this kind of attack. It requires human eyes and thought to determine how to use your password to get to your other accounts, which is still a weakness to be concerned about, however. More on this in my discussion at the end.

The second thing it does is perhaps more important, which is that it adds significant length to your password without the need for typing *anything*. The strongest protection against brute-force attacks is a long password, as the cracking program will have to try innumerably more letter combinations to reach your password. Long passwords are hard to remember and type, though, which makes them hard to use. This method takes care of both problems. Simple, huh?

=Care and Feeding of Passwords= 

You'll need to track these individual site passwords, but you don't need to store them in a safe or your wallet. Either write them down in an address book kept somewhere reasonably safe (a desk drawer) or use a password manager such as LastPass.

Make a list of your important accounts now. You'll need this list whenever you need to change passwords, either when you routinely change them or when one has been hacked.

There are two kinds of important accounts; ones that have access to your money and ones that don't. The money ones are your most important and the others are important, but for other reasons. You should list your accounts should such as:

==Most important== 

*Email*
Password Managers: LastPass, KeePass, Roboform, etc.
Financial: Bank, Investment
Payment: PayPal, etc.
Money Management: Mint, BillGuard, etc.
Shopping: Ebay, Amazon, Google Checkout, anything that stores your credit card info

==Important== 

Windows logon
Social Networking: Facebook, etc.
Anti-theft: Prey, Hidden
Backup: Mozy, Carbonite, CrashPlan, etc.
Synchronization: DropBox, Windows Live, SugarSync, etc.
Remote Access: LogMeIn, GoToMyPC, etc.
Encryption: TrueCrypt, BoxCryptor, etc.

After your bank and investment accounts, email is by far the most important account. Why? Because a hacker with access to your email account can reset the passwords for virtually *all* of the rest of your accounts. Email is like the back door to all of your accounts. Protect it as you do the most important of your accounts. If you use Gmail, strongly consider using their 2-step verification feature, which requires you to enter a code sent to your phone via text message in order to complete the logon process. It's that important.

Set a reminder for 6 months or a year from now to change your base password. Never reuse a base password you've used in the past. You'll need to immediately change to the new password on all of the accounts on your list. You should be able to accomplish this in half an hour or so.

The rest of the accounts not on this list don't need to be changed as long as you have the passwords written down or saved in a password manager. For this reason I strongly recommend a password manager to track them for you, such as LastPass. It keeps me sane so I don't have to change every single password I have on the non-important accounts.

Finally, if you do use an online password manager such as LastPass, then this is a good time to export your passwords. Print them out and put the printout in your safe place with your valuables. Delete the exported file and remember to empty the Recycle Bin at this point. Don't keep the exported file on your computer unless you know how to encrypt it with an encryption solution such as KeePass or BoxCryptor.

=An Example= 

Have you made it this far? Great!

Here's an example of how to generate a base password.

Using the random word site set to generate a random uncommon noun, after a few tries I get "headhunting". I can remember this and the five-letter version, "headh", isn't a dictionary word, so I choose it.

I capitalize it and add my birth year as well as a period. Let's say I was born in 1969, so my base password is "Headh69.". I write this down on two cards, one I put in my wallet behind my driver's license and the other in the firesafe I keep at home.

Now I go to my important accounts to change my password. Let's take Gmail first. When I go to www.gmail.com, I log in and go to account settings to change my password. First I type in "Headh69.". Then, I go to the address bar and double-click the site name. Because Gmail changes the site name to "mail.google.com", when I double-click it I get "google". Actually, since I'm using Google Chrome as my web browser, I get the trailing dot as well, so I get "google.". I copy and paste that onto the end, so my password is "Headh69.google.".

That's your pretty good password for Gmail.

Note: do NOT use this example as your real password.

=An Important Word of Advice= 

Now, before you go and change your passwords on all of the rest of your accounts, I need to point out one important thing. Remember when I said there's reason for concern that the site-specific part of the password is just the site name? That's because if someone gets your password, such as "Headh69.google.", it's not too difficult to see that it's for your google account. One easy guess later and they could have your bank password by substituting the bank domain name for "google".

While pretty good passwords are better than using some simple password on all of your accounts, you should really take another step to secure your most important accounts. That's why I make more than one password. In fact, I use three passwords. I use one password on the most important accounts (email and financial), another password on the other important accounts (Facebook, etc.) and a third on the rest of my accounts, the ones that I really don't trust. These three tiers; very secure, secure and insecure; isolate the important accounts from the less trustworthy ones.

Even though this is harder to remember, I highly recommend you take this step. If you can't remember three, then use at least two. Use one password for all of the important accounts and another password for the rest. A password manager like LastPass makes all of this much easier than you might think.

Still, you don't have to go this far if it's too much for you. If all you do is make one password using these instructions, you're still much better off than the vast majority of other people's passwords. There is no perfect password and although this method has its issues, it's better than "password1" by a longshot.

=A Final Word on Other Password Methods= 

There are lots of opinions on how to make passwords. If you want other ideas, you can check out these resources:

One more which deserves most of the credit, to which I basically made refinements (as well as coming up with a snappy name):

Gem Versioning and Bundler: Doing it Right

http://yehudakatz.com/2011/05/30/gem-versioning-and-bundler-doing-it-right/

-- Shared with Google Share Button

This article talks about best practices for using Bundler and Gemfile.lock.

I take an even more conservative approach than this and use explicit versioning in my Gemfile, but the discussion of the principles and rationale is enlightening here.

I also can't use the "always run bundle exec" advice for my server because the service application I use can only kill the executable when the service stops if the executable is what was directly called when starting the service.  Unfortunately, "bundle exec" introduces another executable between the service manager and the actual server executable, which means that it breaks the service stop function.

Upgrading Spree

This is the first draft of a guide to upgrading the instance of Spree commerce which we use at my work.

Updating Spree

Created Monday 17 October 2011

New versions of Spree or Spree extensions may be needed and you'll need to update the DidItBetter Spree store when that happens.

There are really two kinds of modifications you might need to deploy. The first is one that is made by us, that is to say code changes that we've developed ourselves. The other is changes made by the originators of the code. More on the latter later.

Let's start with code changes we've made ourselves. It doesn't really matter in this case whether or not the code change is to the core spree code or to an extension, because our spree instance references both the same way. The code for both the spree core as well as the extensions are referenced in the store's Gemfile. Bundler is used to pull updates to this code from the github repository(s). Copy any new assets from the public directory of the updated code to the server's public directory, then restart the server and bang, you're done. Well, that's the short version but there are actually more steps in between.

Since we're talking about our own code changes here, presumably there's some development that's been done along with some testing before we roll that out to the server. Hopefully. So you need a development environment, a way to test the code and then check in the finished product.

The spree server code for our instance does live in a github repository and can be easily checked out and run anywhere, with the exception of the database itself. This means it's easy to do a run-through and test of the upgrade before we actually touch the real server. So that means running the server in at least two places: in production where customers can reach the real server and on a development machine where the developer can try the deployment themself, first.

However, that's for staging, not for actual development, for two reasons. The first is to keep the deployment process agile. If you're doing development on the staging server and an important update is suddenly needed, it's stuck behind the work you need to finish. You don't want that, so doing development separately from staging keeps you able to deploy an update at a moment's notice. Second, the real server doesn't make it easy to do development with the core or extensions. The real server pulls all code changes from the repositories, meaning that code changes have to be pushed to the network repository and then pulled to the server, even if the code was local in the first place. For this reason, to do development you need a development server where the server and extensions are in a sandbox setup that allows all the code to be run and edited locally.

The sandbox model is a checkout of the spree source code where an instance is created in a subdirectory named "sandbox". The server can be run from that directory with the normal "rails s" command, but the difference between this and the production server is that the code is live. If run in rails' development mode, you can even change the code while the server is running and see the effects. The way this is accomplished is that the sandbox directory is an instance, and it has a Gemfile which, instead of pointing to the github repository for the spree code, instead points to the parent directory. Similarly with extensions, it points to local directories instead of repositories, usually in directories sibling to the parent with the spree code.

So let's say you've done your development on a spree extension and been testing it using the sandbox. All the tests are green and you're ready to deploy. From here there are several steps:

  • Commit your code
  • Push to the network repository
  • Go to your deployment server directory
  • Tell the server to update the module in question
  • Run the deployment server and test

 

This cycle happens without bothering the server in production and verifies that the committed code made it through the repository and deploys in a production environment. This identifies any issues with the deployment process, as well as integration with other modules already in deployment, so it is both process and integration testing. The deployment server is usually a local checkout of the same instance of the production server, from the same repository.

Once everything is verified, the changes made to the deployment server are committed and pushed to its repository. The great thing here is that if we did have to make any changes in order to get the new code working on the deployment server, these changes are committed and pushed, and simply pulled to the production server intact. Because the deployment server is an actual copy of the production server and using the same repository, all of the work done on the deployment server is simply pulled to production intact, it does not have to be redone.

The process of actually getting the updates into the deployment server also has a couple of details.

As far as the new code goes, you have to do something to pull the updates to the server. That's what bundler (the "bundle" command) and the Gemfile are for. Since the Gemfile indicates what versions we require of certain modules, we could just run the usual "bundle install" command which got us started with it in the first place, but this won't work. "bundle install" will pull the latest acceptable versions from their repositories and resolve all of the dependencies, but if the modules have already been downloaded once it will stick with the installed versions. It is conservative and will only update the versions of items in the Gemfile which are not currently satisfied. Hold that thought.

We could also simply run the "bundle update" command. This command is not conservative at all. It will go through every module and find the latest updates for all of them from the repositories and install them all in one go. This can cause problems because there may be unknown conflicts introduced in the latest versions of modules and it's usually not wise to do these upgrades wholesale like that, unless you're feeling lucky and have time on your hands. Additionally, if you haven't committed your current Gemfile.lock, you may not be able to get back to where you were.

You could instead run "bundle update [package]", which works to just update a single package, although it also goes and updates any packages on which the updated module depends. This is a middle-ground approach, but supposedly it occasionally causes issues with updating a shared dependency to a version not supported by another top-level package. So it can cause problems as well.

Usually, the Gemfile is specified very loosely, allowing bundler to install the latest version of a module so long as it meets a basic version number. Because of this, when you run a "bundle update", there are usually lots of candidates for being updated, resulting in a lot of change. Fortunately the installed versions are tracked in the Gemfile.lock file, which needs to be under version control. When it is under version control, you can make a checkout and just run "bundle install". This will install all of the necessary dependencies in exactly the versioning specified in Gemfile.lock, so you get an exact copy of the code used to commit in the first place. This is the only way to get a reproducable instance.

This Gemfile.lock file is a fallback in case you do have a problem with an update, but you may need to do an entirely new checkout to get back to the versions specified in Gemfile.lock. It is unclear to me at this point whether you can just revert Gemfile.lock in an existing install that has newer-version gems associated with it and try a "bundle install". I don't think "bundle install" will downgrade gems this way. In any case, this doesn't seem like a good mechanism for avoiding versioning problems in the first place, but it is there.

So the challenge is to make it reliable to upgrade one package and as little else as possible. It seems that the best way to do this, while it may seem a bit unflexible, is to lock down the versions of the extensions you want to control by specifying them precisely in the Gemfile. My general approach is to lock down just the spree code as well as the extensions which I manage through my own github repositories. Any other extensions which I don't manage myself, I trust that I will update infrequently enough that I don't need to worry about their interference with any other modules. But the core spree code can break lots of stuff when it changes, so that I want locked down, as well as my own managed extensions, mostly because their releases are not as rigorously tested and managed as other modules.

You can lock these in the Gemfile by specifying specific revision numbers. However, this isn't the best method when you're loading from the repositories. Instead, you can lock them to branches or commits. I prefer commits because they are uniquely precise, if a bit unwieldy. I prefer commits over versions for the spree code because I frequently want to be running the latest committed code without necessarily waiting for a release. If you're using versions, you have to wait for a release in order for the version number to increment. Also, for my modules, I don't typically go to the trouble of grooming releases at all, so the version number may not increment for long periods of development.

If you use this Gemfile upgrade technique, you don't need the "bundle update" command at all. Instead you always use "bunde install", which checks the Gemfile for updated versioning info and only updates the specific components needed. It also handles shared dependencies correctly. Finally, it means you can use a single command for all of your installation and updating, making the syntax simpler and consistent.

Check the Gemfile for examples of how to specify the commit revisions.

To do the upgrade to the staging server, then, you update the Gemfile and run "bundle install". Then you put the assets in place

As far as assets go, since we are currently using rails 3.0, changes apart from code, such as stylesheets and javascript, still must be copied manually to the public assets directory on the deployment server and then checked in there. Since the deployment server runs its extensions as gems, without the source readily available, you usually need to copy these items from the original directory without relying on the repository. Once you have the assets in the deployment server's assets directory however, you just check them in and they will be there when pulled to the production server.

Once bundler is done and the assets are in place, run "rails s". Do your testing, then commit your changes (mostly the assets, Gemfile and Gemfile.lock) and you're done.

To push to the production server, you pull the changes from the repository, run "bundle install", restart the server and test. There is no copying of assets since you did that on the staging server and pulled them with the commit.

If something goes wrong, you can try reverting to the last server commit (including its Gemfile.lock) and running "bundle install", but I don't think this will downgrade gems. Haven't tried it.

You will then probably need to make a new copy of the server, since bundler stores the gems specific for each install. You'll get a fresh set of gems at the specified versions this way. Make the new checkout and run "bundle install". You'll also need to copy the files that aren't in the commit, namely the database configuration file config/database.yml.

Posting to Posterous via Email

http://howdoi.posterous.com/how-to-get-the-most-out-of-posting-by-email

-- Shared with Google Share Button

Blog posting to my Posterous account has been easiest by email so far, since the various widgets I've tried to use all leave something to be desired.

Email posting is pretty easy and full-featured, but I forget the instructions on how to use the occasional advanced feature.  Here's the link to the email posting tutorial so I can remind myself how to do it.

Cyberduck – FTP client with S3 support and more

http://cyberduck.ch/

FileZilla is a great FTP client and the clear king of the roost, but it's strength and weakness is that it focuses on FTP and doesn't support Amazon's inexpensive S3 storage service.

At work we use S3 to serve the larger content for our website, kind of like a poor man's content-distribution network.  Pictures and downloads go there.

Amazon has a web-browser based management console, but it's a bit clunky to get it started.  I prefer an application.  Fortunately, Cyberduck is just such an application.

It caters to a wide variety of storage backends and feels fairly intuitive.  It used to be for Mac only, which is probably why it feels nice, but now supports Windows as well.  Also, it's open source.

For S3, there are specific settings in the preferences dialog that I had to set to get it to use S3's less expensive Reduced Redundancy Storage by default.  You can also set default permissions as well.

Domain URL redirection, mojoPortal default site handling, URL rewriting and ASP.NET 4 extensionless URLs

Check out this website I found at vanadiumtech.com

Hold on, this one's twisty.

One of my managers recently informed me that when you go to our website with "sitename.com", you were redirected to "support.sitename.com", not "www.sitename.com". This wasn't the desired behavior.

I thought I could solve this using mojoPortals "Preferred Site Name" feature. The preferred site name tells the server to redirect to another URL, one which contains the full site name, when a request comes in without a hostname tacked on the domain, as above. Sounds perfect, right?

Well, not quite. First of all, kiddies, don't mess with this setting unless you know what you are doing. Unfortunately for me, I frequently think I know what I'm doing when I, in fact, do not. Twice I locked myself out of my support site by forcing it to redirect me elsewhere. There's a way to fix this mistake by logging onto the server and using SQL Management Studio to find the right field in the database and erase it. You can find the field in the mojoPortal docs, I believe thanks to me reporting it to them after the first time I messed it up.

So what happens when you use the setting? Well, if you have my setup, nothing. See, first you go into the admin interface. This has to be done on the default site in order for you to see the preferred hostname setting. So first you go to the default site, support.sitename.com in my case, and then login to the admin interface.

Now here's the rub. If I set the preferred hostname to "www.sitename.com" on the default site, I lock myself out. Why? Because now when I go either to "sitename.com" *or* "support.sitename.com", I get redirected to "www.sitename.com". Which is the desired behavior for "sitename.com" but *not* for "support.sitename.com", which you can no longer reach at all and, by the way, is *not* the default site and therefore cannot undo the setting. Why? Because you can only access that setting when you're logged into the admin interface on the *default* site.

SQL Management Studio to the rescue. Fortunately the fix takes effect immediately and doesn't require any restarting of services.

Scratch head. Maybe it'll work if I set it on the other site, the non-default one? So I try this, and nothing. Of course, if you visit the other site "www.sitename.com", there's no need to use the preferred hostname because you're already at it. If that site had another name, then this might be useful, but it doesn't in our case. Why doesn't it do anything for the "sitename.com" case? Well, that's because the preferred hostname is on the non-default site, which never sees that request. mojoPortal *always* routes the non-specific domain request to the default site. The only way to change that particular host request is to use the preferred site name on the site that handles the request, which is the default site. As we've seen, that's impossible here.

More head scratching. Clearly I'm going to have to turn to another feature or technology to get me out of this.

I didn't really consider trying to put a manual redirect into mojoPortal's redirect handler (had enough of it's model) and IIS 6 itself can only do redirects on urls that exist as files in the filesystem. No dice.

However, I was already using another tool that is more powerful and could handle arbitrary redirects: URL rewriting via IIRF 2.1.

I had IIRF already installed on the server to handle reverse proxying to a web application server. I just needed to allow the same install to work for my mojoPortal site and to write the rules for it.

I was able to succeed with this approach, but it took a bit of wrangling. The first problem was that IIRF is an ISAPI filter, and for some reason it didn't want to load on the mojoPortal site in IIS manager. This may have been an issue with some of my security software, so I turned the security off and also ended up approaching things a little bit differently, so I'm not sure which it was that solved it.

Instead of installing IIRF as a filter on the mojoPortal site, I installed it once for all of the sites at the top level, removing it from the web application site. This worked fine for the web application site when I restarted IIS, but wasn't working for mojoPortal.

I first made a basic iirf.ini for the mojoPortal site that just enabled IIRF and logging and nothing else. I was checking the iirfstatus url to get a report from the module, which worked on the web app but not mojo. What gives.

Then I remembered. The web app is on an older ASP.NET worker group because ASP.NET 4 (for mojo) was messing with its URLs. ASP.NET 4 magically mangles any extensionless URL (basically anything not ending in ".aspx" or ".html", although that's simplifying). The same was happening with the iirfstatus url, so IIRF was never seeing the request.

The article linked above talks about that in more detail and offers a couple different solutions, one by disabling extensionless URL handling (something I had been trying to avoid so I might use it in the future) and another by doing some crazy rewriting. Valuing my sanity, I chose to disable extensionless URLs through the DWORD: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0\EnableExtensionlessUrls = 0

Once I did that and restarted IIS, I could get to the status page and see IIRF was working on the mojoPortal site. I used the rewrite rules from the article mentioned above and it worked like a charm after that.

Whew!

Adding a monospace TrueType font for the Windows console

If you want to change the system default monospace font for your Windows command-line, there are a few steps.

  1. Make sure you have the font installed in Windows
  2. Add a new "00" registry value with the font name at HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Console\TrueTypeFont.  Add a zero to the value name for each additional font that you want.
  3. Open a console window, go to properties and select font options.  Swith to TrueType and select the font.  It won't show in the window until you reboot, however.
  4. Reboot.

Full details are here: http://support.microsoft.com/kb/247815

Avoid malware attacks using the ScriptNo Chrome extension

Despite the usefulness of the web, an unfortunate reality is that the web is used for many, if not most, malware attacks.  It used to be that to infect your system, you had to run an executable piece of software on your computer, usually by being tricked into running an email attachment or by running cracked, infected software for example.

Attackers have become a lot more sophisticated since those days.  While regular virus infections such as those are still a threat, nowadays your machine can become infected just by clicking a bad link, or worse, visiting a regular, normally trustworthy site that has been compromised by the bad guys.  These attacks usually get your browser to run the infected program without asking you and without any visible indication that the bad guys have succeeded.  They make use of holes in your browser software, Javascript, Java, PDFs or other technologies that can be abused.

Frequently, the first step is to get your browser to do something that you have no control over and that you don't see happening, such as running Javascript or using hidden iframes, zero-pixel pictures, and other dirty tricks.  Even some otherwise-legitimate sites use some of these tricks for tracking purposes so they can better track your online movements.

For this reason, I recommend using Google Chrome, the third most-popular browser on the Internet.  I recommend it both because it's an excellent browser, my favorite from an ease-of-use perspective, but also because it is less directly targeted by malware authors because of its "runner-up" status (look for this to change as it becomes more popular, which I believe it will continue to do).

Chrome supports extensions, add-on pieces of software that change how it functions.  If you are security conscious, ScriptNo is one such excellent add-on. 

ScriptNo blocks scripts and other web nasties from running by default, showing you an icon in the toolbar whenever you visit the page.  This icon is important because it tells you whether the page is trusted or not, and how many items have been blocked from running on the page.  Visit one of your favorite sites and you may be shocked to learn that some are running 20 or 30 of these items on a page, not just from the site itself but from all over the web.

While "normal" sites tend to run many fewer than that, it's not out of the realm of possibility.  And to be fair, many if not most of these items are innocuous or useful.  For example, most page animations and popups (such as picture "lightboxes") are scripts.  These are good and useful most of the time.

However, even legitimate sites include a lot of stuff I find objectionable, mostly related to tracking your movements on the web for advertising purposes.  These things are blocked by ScriptNo as well unless you explicitly enable them.

And, for the most part, many many pages load and run fine without all of the added junk.

The drawback (and there's a drawback of course), is that the pages that _do_ need the added junk won't work when you first install ScriptNo.  This is a problem.  You go to read your email and the page loads partially, but no email shows up.

That's because all scripts are blocked by default and "web apps" like email and facebook need them to be allowed.  To do this, you go back to the icon in the toolbar and click it.  It then shows you a list of all the places on the Internet that this page is loading scripts from (yes, a page can load scripts from anywhere else on the Internet that it wants, and you never see that).

A word about these sites.  Usually you can go ahead and "allow" the site name that you're visiting without too much further thought.  However, it loads a lot of scripts from places you've never heard of.  These show up in the list, but how to know whether to enable them or not?

For the most part, you shouldn't.  Go ahead and enable the main site name and see if the page starts working (more on how to do this in a moment).  However, if the page still doesn't work, it takes some judgment.  I normally avoid anything I already know is an advertising-related site.  It gets easy to figure out which these are over time because you see them *everywhere*.  For the rest, if I see something with CDN in the name, those are candidates because they are content distribution networks, which feed large files like video and images.  Others I address on a case-by-case basis and see if they affect the page's usability.

There are a couple important buttons by the site names when you list them from the ScriptNo icon:

Rating: If I don't know what a site is already, I click this and it shows me WOT's (Web of Trust) page on the site.  Their color coding system makes it easy to weed out the untrustworthy sites.  If it's green, I generally allow it.

Temp: temporarily allow the site while this browser is open.  I use this to see if a site makes the page usable, and if so I allow or trust it later.

Allow: allow just that particular now and in the future.

Trust: allow all sites it that domain now and in the future.  I generally use this for major sites like google.

Distrust: never allow all sites in that domain.  I use this on tracking sites and anything WOT rates orange or red.

ScriptNo saves all of this information, so it learns over time and becomes less intrusive.  You always need to train it on new sites whose functionality relies on scripts though, which are a good portion of sites.  This is the price you pay for security, is less usability and more intrusiveness.

Having been the victim of drive-by web attacks before, it is sad to say but for me an extension like this is a necessity and I use it on all of my computers.  However, I'm knowledgable about how it works, the good sites versus the bad, and I'm willing to pay the usability price.  Your average user wouldn't choose to do this on their own unless all of those things were true.  To each his own, and I don't recommend this tool for everyone.

However, there is one kind of user for whom I'd strongly recommend this extension, and that's anyone who handles major financial transactions on-line.  Or anyone piloting unmanned drones on bombing missions, but I digress.  If you run your business account online, either do it on a computer expressly dedicated for that purpose and strongly secured, or at least do it with this tool.  Many bank accounts have been looted after being compromised unknown to the user.

Giotto is a free Flash animation tool

If you're into any kind of animation, this seems like a very cool tool.  It's hard to find quality Flash animation software that isn't, well, Adobe Flash.  Swish is the next best thing I've been able to find and although it's much cheaper than Adobe, it's also pretty dated-looking and not the easiest software to use.  I don't know how easy Giotto is yet, but the price is right, it's supposed to track the Flash UI somewhat, so tutorials should work, and thus far it looks slick and has good documentation.  I'll be curious to see how it measures up.

http://vectorian.com/giotto/

Sharing folders between Dropbox accounts

I use Dropbox to keep my personal as well as some work items synced to all of my PCs so that I can easily pick work up where I left off while I'm on the go.

This has worked great so far, but I found myself in a situation at work where I really wanted Dropbox on another machine so I could have access to those same work files.  However, I didn't want all my personal stuff that's beside it in my Dropbox to show up as well.  Besides, I've got about a gig and a half I don't really want to sync.

So I found out that you can share folders between Dropbox accounts.  Apparently this is just what I want.  I already had the folder I wanted to share in my Dropbox, with all of the work stuff I needed.

So I opened a Dropbox account with my work email and installed it on the other machine.  Then, from my Dropbox login to my personal account on their website, I was able to share the folder to my work email.  From the work email's account, all I had to do was accept the invitation to share, and now that folder with just the work stuff shows up on that new machine.  But it syncs to the same folder in my personal account, which shows up on my desktop and home machines.  Sweet.