Dev411 Blog

Laptop Security and IronKey?

John Wang — Fri, 30 May 2008 02:20:00 -0500

This article was initially focused on the T61p's fingerprint reader and IronKey; however, I've expanded it to cover other options as well. Since the fingerprint reader has turned out to have little value in the way of security, I've turned my attention to the bulk encryption hard drives and encrypting file systems.

I've been discussing IronKey; however, other hardware crypto tokens such as smart cards and USB tokens may also be solutions.

Fingerprint Reader

After playing with the ThinkPad T61p fingerprint reader, I got thinking whether it would be useful to tie an IronKey USB key to the laptop fingerprint reader and/or require the IronKey to be present for the ThinkPad to boot. Furthermore, the laptop's hard drive could be encrypted by a key stored on the IronKey. Some interesting things to think about.

Does anyone know how secure the ThinkPad fingerprint reader actually is? The NotebookReview Forum has a thread fingerprint readers.

Update: After a bit more reading, it appears that it's impossible to eliminate use of a password for the Administrator user as mentioned in this thread. IBM references include this and this.

Encrypting Hard Drives

Modern hard drives including the Hitachi Travelstar 7K200 and the Momentus® 5400 FDE.2 Hard Drives include built-in bulk-encryption technology. Here is a thread on the ThinkPad's bulk encryption hard drive. Moving the decryption key to a removable device like the IronKey seems to make a lot of sense. This way if the laptop/hard drive was lost, it would be useless without the IronKey and the IronKey password. Is something like this in the future for laptop security? I wasn't able to find this feature on their website but it seems like an interesting option.

Encrypting File Systems

Microsoft has been offering their Encrypting File System (EFS) offering for sometime and has redesigned for Vista. Linux users also have an option with EncFS which is licensed under GPL. PGP Whole Disk Encryption is yet another option. Microsoft EFS can use keys stored in smart cards, and presumably the IronKey. I'm still not sure how popular Microsoft EFS is and whether you need a Microsoft PKI deployment or not.

With the growing number of laptop security solutions, what is the current best option and what would be the ideal option for the future? I have to admit the idea of using a USB crypto token to decrypt a hard drive seems attractive.

Whither Point Releases?

John Wang — Wed, 14 Nov 2007 01:24:00 -0600

In the old software days with point releases, major versions would increase from 1 to 2 to 3, etc. Releases in between major versions would point releases along the lines of 1.1, 1.2, 1.3 and smaller releases would be 1.1.1, 1.1.2, 1.1.3, etc. Then came along Windows 95 and the exit of sequential version numbers. With this naming scheme you really can't have Windows 95.1 so we now have Releases, along the lines of Oracle 11g Release 1 and Windows 2003 Server Release 2. You can pretty much guarantee that there isn't going to be an Oracle 11.1g ;)

That's all fine and good from a marketing perspective if the reason is that we are now using a year or abbreviation instead of a simple integer but are there other technical reasons? I recently upgraded from Apache httpd 2.0.x to 2.2.x and the major thing that I encountered was that configuration had changed significantly and that I had to redo my conf files. I've spoken with some people that indicated many organizations are afraid of point releases for enterprise software because they often break things and are not necessarily smooth upgrades. This fit with my Apache httpd experience which got me thinking.

If there exist enough backward compatibility problems with point releases, it would make sense that software publishers would want to avoid point releases (at least from a marketing perspective), when the release is backward compatible, e.g. Releases for former point releases, Service Packs for aggregated patches and the like. Has the single point (vs. double point) release come to mean that backward compatibility has been broken. If so, should it be avoided from a marketing perspective when backward compatibility still exists?

Comparing CPAN Modules with YUI DataTable

John Wang — Fri, 09 Nov 2007 00:09:00 -0600

There is a lot of choice on the CPAN for open source Perl libraries and sometimes it's difficult to get an idea of how modules compare to each other. CPAN Ratings is a good source of reviews but it's not convenient to compare one module with another. To provide a partial solution, I whipped up a quick CPAN Compare page which will pull the CPAN Ratings from a number of modules and summarize them for you.

I decided to use YUI DataTable for this. I've heard good things about YUI so I decided to give it a try. Getting the example code to work off of the Yahoo website almost as straight forward as say using Scriptaculous demos but it was faster than working with Dojo in the early days. The nice thing about the DataTable is that it takes a JavaScript array which can be populated using server-side JSON generated code. I used JSON::XS for this.

YUI DataTable has a nice sorting feature and it can sort on text, numbers, dates, etc. However, it does not seem to be able to sort on visual information only so if you include HTML markup, that will be used for sorting as well. To get around this I used standard text sorting and customized the title fields to assist in the sorting. For example, in a link, I start with <a title=" instead of <a href=" because title is arbitrary and can be used to mirror the InnerHTML. For numbers a text sort will have 25 come before 4 so I added leading zeros to numbers using sprintf and put them in the title attribute as well.

A few Perl modules and the Logo Creator website made this easy to set up. YUI DataTable has a nice default CSS so I just left that as is.

Note: YUI DataTable is convenient if you just drop in a Perl data structure and have it generate the HTML and JS for you. This script uses 3 DataTables (ratings, popular and recent) so I wrote a Perl wrapper for YUI which takes a hashref and generates the client code, extracting the fields from the column definitions. This works because YUI does not require the HTML table to be built beforehand. By not having an underlying table, it's faster to get running but also won't fallback as nicely for people who aren't running JS (8% of users?). As an alternative, jQuery has a couple of add ons which work by enhancing an existing HTML table. jQuery has some nice syntax but I haven't gotten around to using it yet. Perhaps it's worth a look.

What is the best digital voice recorder (DVR)?

John Wang — Wed, 05 Sep 2007 01:37:00 -0500

I just recently picked up a digital voice recorder (aka DVR, not to be confused with digital video recorders) for recording conference calls and meetings. In three short meetings I have become a true believer. I always taken detailed meeting notes but that was because I would write notes during the meeting. With a DVR, I can concentrate on running the call and going back to catch the details later.

For my first DVR I picked up the Olympus DS-30 from FRYs. The benefits that I keyed in on where the large-looking stereo speakers and the noise reduction. Since this is my first DVR I was easily impressed by the utility of it. So far I've recorded and played back on the device, copied the WMA files off using it as a USB storage device on Win XP and converted the WMA to OGG Vorbis using dbPowerAmp. The only thing that doesn't seem to work is the CD that it came with. XP would not recognize it at all but at least I don't need since it doubles as a USB device.

Although it meets my current notetaking requirements easily, I've been thinking about whether it'd be good to use for recording podcasts. My current issue is that it records in WMA and not a FOSS standard. After looking over a number of DVRs, it seems that the higher end ones use WMA, LPEC, DSS, etc. but not common music formats such as MP3 and OGG. What native format do you think is the best for DVRs? Is it fine to record as WMA and convert to OGG Vorbis or are there better options?

I don't know too much about voice recorders at the moment so I'm easy to please. Which ones do you like and what are important features for you?

Database Abstraction - code vs infrastructure

John Wang — Tue, 04 Sep 2007 23:38:00 -0500

I've worked on a number of database-driven projects and no matter how much people want database abstraction, it was always difficult to code and maintain. I was recently reminded of this when I read this Drupal article on dropping PostgreSQL support. Not only can it be difficult to maintain support for multiple databases, but it may be difficult to find developers.

One solution of modern programming is to move database abstraction from the code to the infrastructure using a ORM (Object-Relational Mapper) or Data Mapper. A ORM and Data Mapper abstracts the database for you so you no longer have to do tie db abstraction to each app. Not only does it let you code once for multiple databases it lets your users migrate their data from one database to another. This blog runs Typo which is based on Ruby on Rails and ActiveRecord. I've been contemplating migrating Typo from MySQL to PostgreSQL and I've been told that it would be as simple as exporting the data with YAML, updating the database.yml file and importing the data. I haven't gotten around to doing it yet but it is a powerful idea. ActiveRecord is a data mapper and isn't as flexible as a full blown ORM but it gets the job done for the most part. For a full-blown ORM, I think of Perl's DBIx::Class which provides a full OO interface to the RDBMS allowing you to code just once for multiple DBs without limiting you when you want to use some esoteric database-specific SQL. DBIx::Class is often used with the Catalyst Framework but is also used by itself.

There are PHP frameworks out there like Symfony and Cake but do any of them have stand-alone ORMs? If so, could Drupal move to something like that and solve their maintainership problems once and for all? Drupal is part of the Go PHP5 effort so there should be no issue using PHP 5 OO. Something to think about for the Drupal folks if a PHP ORM is available.

Initial Thoughts on OpenID

John Wang — Sat, 07 Jul 2007 15:39:00 -0500

There has been a lot of talk about OpenID so I decided to take a look at it and think about some of the potential issues with respect to broad adoption and integrating it into a website as a relying party. There have been numerous attempts to either improve the security of authentication via the web or improve the usability with SSO (Single Sign-On) including client SSL, OTP tokens, USB tokens, AmEx Blue smart cards, Microsoft Passport, Verified by Visa, etc. Many of these had SSO capabilities but none has been able to supplant local passwords. It will be interesting to see if OpenID can succeed where these others have failed. Here are my thoughts after watching two screencasts but before following the mailing lists. I'm now reading the list archives and it seems a number of similar issues are being discussed.

Provider Types

The decentralized nature of OpenID means anyone can be a Provider and because the Provider is entrusted with performing the authentication, it is important to trust the provider. Here's my way of classifying Providers.

Tier 1 Provider: These are organizations that have good reputations and perform initial identity verification in a manner that is not often subject to identity theft. Banks and brokerages qualify. At bricks and mortar banks, you often appear in person and provide identification via a physical national or state/provincial government ID. At a brokerage you have to invest money which many thieves aren't willing to do (though some are). These organizations will have known domain names and employ a method of authentication in the response such as TLS/SSL.
Tier 2 Provider: These are organizations that have good reputations but base identity verification on anonymous information or information that is subject to identity theft. Examples of anonymous information include website urls and email addresses. Examples of information subject to identity theft include using a credit card for $1 auth verification. Response authentication via TLS/SSL or other crypto mechanism is not required here.
Tier 3 Provider: These are organizations that have low or unknown reputation.

OpenID Assurance Levels

Given the sophistication of phishing and pharming combined with the propensity of Internet users to succumb to such attacks, there is a real need for higher assurance authentication, especially since this is a SSO (Single Sign-On) system. One way to think about assurance levels can be qualify OpenID solutions by the level of authentication employed and the reputation of the OpenID provider. The latter is needed given the third-party authenticator architecture.

High-Assurance OpenID: A high-assurance OpenID is one that uses strong, aka two-factor, authentication issued by a Tier 1 Provider. For example, a two-factor hardware token issued by an e-banking or e-brokerage company can be considered high-assurance because the authentication method is strong and you can trust the provider confirming the authentication. A cell phone with OpenID password may also qualify. In this case, two-factor authentication is achived by requiring the user to enter their OpenID and password before their registered cell phone is text messaged with an authentication key. The reason a Tier 1 Provider is needed in addition to strong authentication is due to the third-party nature of the authentication. An untrusted provider can simply skip strong authentication while claiming to do so. Because of this, only OpenIDs issued by trusted Providers that use strong authentication may qualify as high-assurance.
Medium-Assurance OpenID: These are weaker authentication solutions but where the user should notice the compromise quickly. Cell phone authentication using text messaging without requiring a password is one example. Although losing one's cell phone will compromise the account, theoretically the person will realize their cell phone has been lost before they realize a password has been compromised. So while both are considered single-factor in the traditional authentication sense, one compromise is more difficult achieve and easier to detect than the other. OpenID providers should be somewhat well known but may not be the largest organizations with the most stringent procedures.
Low-Assurance OpenID: These are weak authentication solutions or from unknown OpenID providers. Username/password based OpenIDs are low-assurance, regardless of the provider. Strong authentication paired with an unknown OpenID provider cannot be trusted to have actually occurred so these are also low-assurance.

Relier Types

Now that we have a framework for understanding the types of OpenIDs, let's look at the OpenID relying parties to see what kind of OpenID each relier type would prefer. Reliers can be classified by the type of information they hold for the OpenID end user. Depending on the sensitivity of information, users may prefer one level of OpenID vs. another.

Sensitive Information: e-banking and e-brokerage. These organizations will most-likely not rely on OpenIDs issued by other organizations but it's possible for them to issue hardware token authenticated OpenIDs that can then be used by other relying sites independent of the issuer (except for the load on the issuer's OpenID authentication servers). E*Trade and other organizations have already issued hardware authentication tokens to their users. It wouldn't be overly difficult to leverage those tokens for an OpenID provider service if there was enough business justification.
Important Information: online identities. There are many social networking and community websites where a person's online identity is very important for personal and reputation perspectives but there's no financial or other sensitive information at stake. Users and owners of these sites may also want high-assurance OpenID if they are going to place faith in a third-party OpenID provider. However, because the information on these sites is not that sensitive, few of these sites may be willing to issue expensive hardware-based high-assurance OpenIDs. OTOH, these sites may be willing to rely on High-Assurance OpenID issued by Tier 1 Providers. Perhaps these sites can provide some kind of incentive to potential Tier 1 Providers to convince them to move their existing hardware token authentication methods to OpenID. Like their local username/passwords today, these sites can also participate in OpenID by issuing their own Low-Assurance OpenIDs.
Unimportant Information: blog comments. Today some sites require users to authenticate themselves to post blog comments but others don't. Presumably the ones that don't require any authentication will not mind switching to low-assurance OpenIDs though the benefit is somewhat elusive.

Given that some types of Relying Parties may require different assurance levels for OpenIDs, it makes sense to have some local filtering rules (white lists, black lists, etc.) on which OpenID providers to allow and which to disallow. Something like this is already happening on a simple level at OpenID relier websites that only recognize OpenIDs they issued themselves (many, if not most or all, of the larger OpenID reliers?). While these sites have deployed OpenID, they are not allowing use of any externally issued OpenIDs. This may defeat the purpose of OpenID but it could be because no other issuers are issuing OpenIDs of high enough assurance for them to rely on.

OpenID growth may be slowed due to lack of recognition if the larger OpenID Relying Parties continue to recognize only OpenIDs they issued themselves. For example, if two large websites are issuing OpenIDs, A and B, and A does not recognize B's OpenIDs, there may be no incentive for B to pre-emptively recognize A's OpenIDs. In this case, both A and B's OpenIDs may effectively remain "CloseIDs."

It could be beneficial to have the Provider return the authentication type/level in the OpenID response so the Relying Party can decide whether the assurance level is high enough for the requested resource. This may only work with Tier 1 or 2 OpenID Providers since a Provider can return anything here so you need some level of reliance. The known/trusted providers can be placed in a local white list.

Relier Considerations: User Experience

Some considerations for a pleasing end user experience.

Redirect experience: the basic user experience presented is to have the relying site redirect to the provider site which then redirects back to the relying party site. This might be ok for early adopters but it's questionable whether the masses will accept this type of redirect authentication. Visa's Verified by Visa tried this approach, then switched to pop-ups to provide some continuity in the user experience, and then switched to iframes in the relying party site after pop-ups proved problematic with pop-up blockers. I'm skeptical whether the average Internet user will accept a redirect and think it may be up to the browser providers to create a better user experience. It will be interesting to see how Firefox 3 handles OpenID authentication.
Redirect branding: one way to improve the redirect experience is to brand the OpenID Provider's authentication page with the Relying Party's logo to add some continuity to the user experience. Today a user doesn't mind being redirected from groups.yahoo.com to login.yahoo.com and back to groups.yahoo.com again because the branding is consistent. The domain is also the same but how many Yahoo users check? To do this, a logo URI can be included in the OpenID request for the OpenID Provider to embed in the login page. This will be more doable if sites choose which OpenID Providers to recognize, creating some incentive for OpenID Providers to assist in creating a better end user experience.
Redirect to unresponsive site: no recovery is possible with a straight redirect to a site that is either dead or having temporary difficulties. A frame could solve this issue but that could create an opening in the user experience for phishers to take advantage of. A list of dead or unresponsive sites is useful so these can be avoided. This list can either be created/managed centrally or locally and kept up to date with periodic pings to the server. It might be more efficient for the Relying Party to ping the servers that are supposed to be live. The ping can happen immediately before redirecting the user or can be done periodically to reduce load on the authentication server, say every 5 to 15 minutes.
Remember me: when a user's session ends on the relying party site, the site can remember the user's OpenID in addition to the username so the OpenID will already be populated with a redirect to the Provider site.
Short names: if the relying party has issued their own OpenIDs, they can append their domain name automatically for local verification so the user doesn't have to type as much. For sites that recognize more than one Provider, there can be a select list for a limited number of providers or an auto-complete for a large list.

Relier Considerations: Captive OpenIDs

Captive OpenIDs are ones that are issued by and relied upon by a single site without even letting anyone know OpenID is being used. The benefit is SSO across all of a organization's servers and partners. Some multi-host websites today use a separate host, http://login.$domain.com, to handle authentication. OpenID can be easily leveraged to create that type of solution without having the user redirected to an outside site, go through multiple pages to authenticate or type long OpenIDs. The UI can be exactly the same as username/password on a single page today because the relier is the same organization and thus trusted.

Today the site will get SSO across their sites, with the same domain or not. In the future, additional OpenID Providers can be recognized or the organization can become a public OpenID Provider themselves. Underneath, a single authentication method is used for authentication internally or to exteral Providers to reduce the level of effort in the future.

Conclusion

There does not appear to be enough higher-assurance Tier 1 and 2 OpenID Providers to convince larger websites to recognize any Providers other than themselves, preventing the OpenID system from realizing its idealized potential. Because those sites refuse to recognize OpenIDs issued by others, there may be a negative feedback loop where other sites are reluctant to recognize their OpenIDs. Part of this is that the OpenIDs issued today tend to be Low-Assurance OpenIDs. If larger sites require Medium or High-Assurance OpenIDs from third-party Providers, then we may have to wait for a reputable provider to use two-factor authentication such as hardware tokens cell phones with passwords and text messaging to come on the scene.

Until High-Assurance OpenIDs become available, issuing one's own OpenIDs may be the way to go to get the SSO benefits across your own sites today while preparing for the future when it makes more sense to rely on OpenIDs issued by others. The OpenIDs can be marketed as such to generate more discussion or the OpenID nature of the authentication can be hidden until it makes sense to discuss it.

Key Wiki Features

John Wang — Sat, 30 Jun 2007 12:11:00 -0500

I just installed MediaWiki at an organization to manage some information I was researching. The primary reasons I chose MediaWiki were (a) it's open source, (b) it has auto-TOC (table of contents), (c) it has auto-categorization and (d) I was familiar with it already. I ran into some rough spots during the Win2K3 R2 / IIS 6.0 installation getting PHP 5.2.3 and the php_mysql extension working but other than that the installation was pretty smooth. It seems that the php_mysql extension that comes with PHP 5.2.3 doesn't work and you need to get it from PHP 5.2.2. Also, rebooting after installing PHP from the MSI helps but that doesn't seem to be mentioned in the installer. The other issue is that IIS doesn't seem to come with rewrite capabilities so I tried a third-party rewrite filter before tabling that for now. It's hard to believe that IIS doesn't have rewrite capabilities.

Some "Enterprise Wiki" solutions include Confluence and SocialText but I don't have any experience with these.

Which wiki do you like for "enterprise" purposes and what features do you find to be key? Do any other wikis have auto-TOC?

Single Sign-On (SSO) with and without subdomains

John Wang — Sat, 16 Jun 2007 20:06:00 -0500

If you are running a site without a subdomain, e.g. http://dev411.com and need to maintain cookie-based sessions across other server names with subdomains, e.g. blog.dev411.com and wiki.dev411.com, you will need to customize your session cookies.

To have your session cookie be used across multiple subdomains, set a wildcard domain which starts with a dot followed by the base domain name, e.g. ".dev411.com", which will make it qualify for all subdomains of dev411.com. This, however, will not work for http://dev411.com where there is no subdomain.

The have the same session used for http://dev411.com, set a second session cookie without domain. This way the domain-less cookie will be used for http://dev411.com and the wildcard domain cookie will be used for all subdomains.

Catalyst 5.7007 will only set one cookie per cookie name, however, this solution works best when you can set both cookies with the same name but different cookie domains. I put together a quick patch for Catalyst::Engine to allow multiple cookies when the cookie value is set to an arrayref.

Typo - Upgrading to 4.1.1

John Wang — Sat, 16 Jun 2007 17:36:00 -0500

I finally got around to upgrading from Typo 4.0.0 r1188 to Typo 4.1.1 and it was pretty smooth. I had held off for a while because Typo was changing a lot under the covers with some much needed refactoring and I have a few hacks I didn't feel like modifying with every minor update.

I ran into some initial issues because I was installing from the tarball and not the gem. I had an older version of Rails and Typo 4.1.1 needs Rails 1.2.3. Running "rake migrate" doesn't check the Rails version and would just abort. Eventually I guessed the problem reading the --trace output and I was on my way. The other curiosity was that Gem's --install-dependencies didn't work for me. I still had to install/upgrade rake, activerecord and a number of other packages before installing rails using gem. I think it would be nice if --install-dependencies did install those or at least showed all the packages that were needed in one report instead of just showing one and aborting. Perhaps there was something wrong with my setup. With CPAN, you get to see all the required dependencies in the first report and it will install them all for you in one shot. However, compared to gem, CPAN might show too much information by default. Perhaps the majority of the information CPAN shows should be moved to a non-default verbose mode.

I have a few hacks running on this blog so the update consisted of the following:

Theme: This blog runs a modified version of Azure which used a table that no longer exists in 4.1.1. Because of this Typo wouldn't start. To get around this I did a manual SQL update of the settings column in the blogs table to reset the theme to Azure before migrating my mods over. The settings field is an aggregate field with serialized information delimited by carriage returns. I prefer using JSON to serialize complex data structures stored in a single db field which I think is much more maintainable.
Categories Sidebar: This had moved from ./components/plugins/sidebar/category to ./vendor/plugins/category_sidebar. Now that the sidebars are stand-alone Rails plugins, it makes more sense for me to turn my custom Category sidebar into its own thing instead of modifying the existing one.
Notable Links: I put together some social bookmarking links a while back for Typo 4.0.0 and it was reported to no longer function with 4.1.1. A little checking showed that article.location was no longer available and replaced by article.permalink_url. Both 4.1.1 and 4.0.0 versions of the Notable view are now available. The method call used to display the article body in ./views/articles/read.rhtml had also changed. This is used as a reference point to insert new code.
Table of Contents: The Table of Contents solution I had put together had also broken and is now fixed. It is interesting to see the progression of link creation from 2.6.0 to 4.0.0 to 4.1.1. The previous two used Rails' link_to helper but 4.1.1 creates the HTML manually.

The rest of the changes were pretty straight-forward to carry across, including the category icons and routes.rb mods I use.

Overall, the upgrade was smooth after I figured out I needed to upgrade Rails from the rake migrate failure. I like the refactoring of the plugins and look forward to making some.

Frédéric de Villamil, the current Typo maintainer, menioned that 5.0 is coming and will have the following features:

Plugin Manager: to download and install plugins from the official repository
Advanced Theme Manager: to download and install themes from the official themes repository
Real Multi-User Support
OpenID Support
and more....

I've been pleasantly surprised with the development activity happening around Typo and can't wait for version 5.0.

Displaying Dates and Times Using JavaScript

John Wang — Mon, 05 Feb 2007 18:28:00 -0600

Some considerations when displaying dates and times on a website include showing delta times, customized timezones and caching. Often it's nice to show a delta time like "10 minutes ago" or "5 days ago" to give readers a frame of reference instead of an absolute date. When the date is far enough in the past and an absolute date becomes desired, customizing the date to the user's timezone is useful. And if your site grows large enough that caching becomes useful, finding a way to display customized deltas and timezone information in a cacheable static page becomes an ideal solution.

JavaScript is an ideal solution for all three issues. With JavaScript you can place an absolute date in the web page and have the JS dynamically update it when the page is loaded. This can be used to calculate delta times and accommodate timezones as well. The result is that the page can embed the same date every time and thus becomes more cache-friendly.

The Typo blog engine (which runs this blog) comes with a useful MIT-licensed JavaScript in it's typo.js script. Just copy three of the JS date/time functions, wrap your dates with spans (using the appropriate class name and absolute date in the span title) and then call show_dates_as_local_time() when your page is finished loading. The two other functions you'll need are get_local_time_for_date(time) and distance_of_time_in_words(minutes). This is what I did for Planet Catalyst's Plagger theme a while back.

Although it's pretty easy to accommodate timezones, the Typo script doesn't do that. I've done this for some projects and might post some code in the future but it's not hard.

Customization and cacheability, two great advantages for using JavaScript to handle dates and times.