LWN.net Weekly Edition for December 8, 2011

Channels for community communications

In the dim and distant past, even before the 0.01 Linux kernel was posted, developers communicated with each other via email, often sent over the UUCP-based USENET network. It had its challenges; life was better for those who could arrange a link to a machine owned by a company that paid little attention to its phone bills, and the need for senders to manually determine the routing of their message made communications uncertain at times. Your editor received a full netnews feed over a 2400-baud modem, and everybody complained that there was far too much traffic to keep up with. But a lot of collaboration was done over this medium, and a lot of early free software was developed and distributed that way.

Happily, the days of broadcasting software releases over modem-based connections are long behind us. But the free software community still relies on electronic mail for the bulk of its communications, despite the fact that a great many alternatives have become available. Email has a lot of advantages: we have developed a lot of tools for working with it (complaints about the quality of free email clients notwithstanding), it works well for multi-sided communications, it is distributed and can be dealt with offline, it is easily searched, and it is readily managed and archived on non-proprietary sites. It is not surprising that email has been the tool of choice for so long, especially when one looks at some of the alternatives.

Recently, your editor received a grumpy communication (via email, naturally) from a prominent community member who was unhappy about a recent quotes of the week article that included a quote posted on the Google+ site. Posting to links on Google+ legitimizes it as a valid place for community discussions, your editor was told; it makes it more likely that more conversations - perhaps more useful ones than the one chosen by LWN - will move to that site. And this was seen as a bad thing.

There are certainly reasons to be concerned about engaging in community discussions on a site like Google+. The site is corporate-owned, making it subject to all of the usual types of pathological corporate behavior, in the present or in the future. Its owner will make use of the content of messages and the whole "circles" structure for targeted advertising and any number of other purposes. Governments seem to feel free to help themselves to the information held by these sites at will. There are no tools to help readers deal with messages on the site, no RSS feeds, and no ability to read messages offline.

But the biggest complaint of all seemed to be that when sites like Google+ (or even LWN) host conversations of interest, they spread those conversations out and make it harder to keep up with what is being said. The result is a more fragmented community with groups that no longer communicate with each other and with people who are left in the dark about important discussions and decisions. It would be better, this correspondent said, to improve the mailing list experience if need be and keep the useful discussions there.

Your editor understands these concerns and is all for improving the email experience whenever possible. But he is less clear on whether it has ever been possible to concentrate community communications into a single channel, or whether it is a desirable goal.

Consider, for example, the venerable IRC channel. IRC is clearly an important part of how members of our community work together. But IRC, too, works poorly offline; it also often - and often by design - lacks a permanent record. Extracting information from IRC logs when they are available is a tedious exercise at best. IRC involvement can also be incompatible with actually getting work done, so some people find that they need to avoid it. IRC, in other words, is a channel that is available to parts of the community part of the time, but it has its value anyway.

An even more exclusive resource is the famed conference hallway track, where a lot of real work gets done. Your editor's job would be much facilitated by readily-accessible logs of conference hallway (and pub) conversations; the "quotes of the week" section, in particular, would benefit mightily. But no such logs exist, and that is certainly for the best. There is also a lot of valuable conversation to be found in vast numbers of bug trackers, patch trackers, weblogs, retail site comment areas, and, sadly, forum sites.

In other words, community discussions are already widely fragmented. The key is communicating important decisions back to the wider group and making people aware of useful discussions. Often that can be achieved with an email to a prominent development list; one might also hope that sites like LWN can help in this regard. Indeed, one might argue that pointing to something interesting on Google+, rather than encouraging fragmentation of our community, actually serves to help pull it back together.

That said, the other concerns about a platform like Google+ remain. If anything important was ever posted on Google's "Wave" or "Knol" platforms, it will disappear early next year. The same fate could certainly befall discussions on Google+. That platform also excludes anybody who is unwilling to provide yet more information to Google about his or her activities and connections on the net. Google+ might serve as a sort of stand-in for a conference hotel bar, but it is not suitable as a piece of significant community infrastructure. One could name any of a number of other proprietary platforms that are equally unsuited, if not more so.

It seems that there is a place in our lives for a service with which we can post updates on our development projects, air travel horror stories, silly cat pictures, desktop environment flames, lazyweb requests, cooking experiments, new techno-toys, and musings on how Cher songs relate to the harsh life of NMI watchdog handlers. What we seem to be missing is the ability to create such a platform for ourselves and, crucially, to get a critical mass of people to give it a try. Even back in the USENET days, we demonstrated that we can create distributed communications services when we set our minds to it. Someday we'll solve that problem again for the contemporary net; until then, we're limited to the channels that exist, some of which are not all we would like them to be.

Comments (33 posted)

Google Authenticator for multi-factor authentication

The security-conscious will tell you that a multi-factor authentication scheme involves requiring items from two or more of the categories "things you know," "things you have," and "things you are." Passwords and passphrases both fall under the "things you know" umbrella, and while there are commercially viable options for the latter two categories — security dongles and biometric fingerprint scanners, for example — neither have taken off with the general public. Partly that is a cost issue, to be sure, but the complexity of public-key infrastructure (PKI) smart cards does not help, either.

Late in 2010, however, Google unveiled an open source project called Google Authenticator that allowed the common smartphone to serve as the "thing you have" factor. The search giant subsequently rolled out support for the scheme for its web applications, but its standards-based functionality and Pluggable Authentication Module (PAM) support have brought it success in a variety of third-party systems as well.

Client

On the smartphone side, the Google Authenticator project provides application software for Android devices, Apple iPhones, and Blackberry handsets. Because these applications are software and generate authentication strings for the user to enter at login time, however, there is some question whether or not they truly "count" as a second factor. Traditionally, hardware authentication tokens must be physically connected to the computer to authenticate a user, though some one-time password (OTP) generators are standalone. Unlike the Android app, however, those devices are meant to make it difficult to extract the key without destroying them. Accessing the key from a phone, then running the app elsewhere (e.g. an Android emulator) would circumvent the "things you have" requirement.

The project's official tagline is "Two-step verification," a subtle acknowledgment of its distinction from a strict definition of multi-factor authentication. But to narrow that security risk, the system generates OTPs that are only valid for a short duration (generally no more than one minute). That does not stop an attacker who steals your device from getting a valid OTP from the application, but it makes it more difficult for an attacker to forge a login through eavesdropping. Specifically, it prevents replay attacks (such as wandering eyes behind you in line at the coffee shop jotting down the passcode) and makes interceptions (such as wandering eyes paired with extremely fast fingers) highly unlikely. Using an OTP will help against credential-stealing attacks, such as those used to compromise kernel.org.

Google Authenticator supports both the Hashed Message Authentication Code (HMAC)-based OTP (HOTP) and the Time-based OTP (TOTP) specifications, both of which were developed by the Initiative for Open Authentication (OATH). Both algorithms use a pseudo-random seed value or key that is known only to the server and the client; the seed is concatenated with a "moving factor" — the piece of the puzzle that makes the password one-time-use only — and the result hashed to create the expected passcode.

HOTP, the older of the two, uses an integer counter that increments for every new passcode. TOTP uses a timestamp as the moving factor instead, with provisions for the server to define whatever time window it wishes to accept as valid. That value enables humans to type in the passcode at a convenient speed, and also allows for clock drift between server and client. Although TOTP is regarded as more secure, HOTP is already finalized as RFC 4226, while TOTP was still at the draft stage when the Google Authenticator project was launched (it has since become RFC 6238).

The mobile clients provided by Google support storing multiple HOTP and TOTP credentials, and can be used to generate passwords for any compliant implementation of the algorithms. There are two mechanisms for entering the seed value associated with each saved account: devices with a camera can take a photograph of a key in an appropriately-formatted QR code, or the user can manually enter the key as a Base32 string.

Server

For the server side of the system, the project provides a command-line tool to provision new keys, and a PAM module — although "server" is not quite accurate; the module will work on traditional desktop Linux distributions as well. According to the user comments on the module's wiki page, Linux appears to be the only operating system supported out of the box; there is a patch reported to work on FreeBSD 8.2 and another for OpenSolaris, but no luck yet for Mac OS X or other PAM-supporting OSes.

The key provisioning tool is called google-authenticator. When run, it generates a new key (primed from /dev/urandom), along with a "verification code" and five "emergency scratch codes." The verification code is used by Google to associate an account with a cellular number via SMS message, and the scratch codes are eight-digit numeric strings designed for use in account recovery — neither is part of the core algorithm. The google-authenticator tool writes the key and the emergency scratch codes into the ~/.google_authenticator file. If libqrencode is installed, it will also generate a QR code formatted for consumption by the mobile applications — the format includes metadata for use by the application, including the hostname, user name, and key type ("totp" or "hotp"). It also writes a URL to stdout containing an HTTPS link to Google's online QR code generator, with the same information as the payload (although, obviously, using the online generator does send your secret key and user/host data to a Google web server...).

The PAM module is named pam_google_authenticator.so, and can be enabled by editing the PAM configuration file for the appropriate service (typically located in /etc/pam.d/). Simply adding

    auth required pam_google_authenticator.so

to, for example, /etc/pam.d/gdm will activate the Google Authenticator module for all accounts; it will request the HOTP or TOTP passcode after asking for the username and account password. Because the keys are stored in $HOME by default, workarounds are required to use the module with encrypted home directories. The project README recommends rearranging the PAM configuration to decrypt home directories earlier, or storing the keys in a different location (which must then be passed to the module as an argument in the configuration file line).

There is a patch available that will require the Google Authenticator module only if a .google_authenticator file is present. This approach could be used to partition accounts into "high-security" and "low-security" groups, but it could also come in handy if something goes haywire during setup. TOTP can handle a certain degree of clock shift, but the last thing you want to do is activate it for all of your login accounts before thoroughly testing it. To that end, the project also provides a demo utility for testing TOTP passcodes, and an interactive online debugger to ferret out clock and interval problems.

Authenticating in practice

Of course, the GDM example above is not Google Authenticator's intended use-case. Securing SSH and other remote-access methods makes more sense for those whose machines are safely tucked away in an office or closet; any attacker with physical access to a local login prompt has many other attractive opportunities. Any PAM-aware application can take advantage of the module, however — including Apache, which opens the door for many multi-user, web-based applications.

Indeed, there are already numerous third-party projects to integrate Google Authenticator into WordPress, Drupal, and other Content Management Systems (CMS), as well as instructions to use the PAM module for security-conscious packages like OpenSSH and OpenVPN.

Perhaps the more pressing question is whether or not it is wise to introduce a dependence on an application available only for iPhone, Android, and Blackberry devices. As popular as these platforms are, they still leave some users out in the cold, and there may be times when you need to log into a machine and your phone is unavailable for any number of reasons — from job site security, to accidental loss, to simple battery failure. USB security fobs do not suffer from the same limitations.

To that end, however, Google Authenticator benefits from the existence of other HOTP and TOTP implementations. While there are not many to choose from, there are a few: OATH Toolkit, multiOTP, and LinOTP are all free software. I tested Google Authenticator TOTP codes against OATH Toolkit's command-line oathtool. You can perform a passcode-generation hash by running:

    oathtool --totp --now="the_current_time" your_secret_key

The passcodes matched, once I figured out how to correctly convert the Base32 encoding produced by Google Authenticator into the hexadecimal required by oathtool — namely, that the Base32 encoding scheme defined by RFC 4648 is not the same as base-32 mathematical notation (because the encoding avoids easy-to-confuse characters like I and O).

Thus, there are options for users who cannot or will not carry a device with an official Google Authenticator client application. The availability of compatible command-line options is not a completely secure solution for the lost-phone emergency scenario, though, because it requires you to store the secret key in a third (or fourth, or fifth, etc.) location.

Nevertheless, as the CMS extensions and wrappers for various languages demonstrate, the Google Authenticator project has taken off to a degree that other OTP utilities have not (and there are several using other algorithms, including OTPW and Mobile OTP, both of which have PAM support). That makes the project a net gain for system security, perfect multi-factor authentication or not. The code is packaged for Debian and Ubuntu, and there are contributed builds available for OpenSUSE and Fedora, although there does not appear to be an official package for either of the latter distributions. If the distributions come on-board in force, perhaps OTP adoption will one day be commonplace.

Comments (53 posted)

2011 Linux and free software timeline - Q2

Here is LWN's fourteenth annual timeline of significant events in the Linux and free software world for the year. We will be breaking the timeline up into quarters, and this is our report on April-June 2011. Over the next few weeks, we will be putting out timelines of the other quarters of the year.

• January-March 2011

---

This is version 0.8 of the 2011 timeline. There are almost certainly some errors or omissions; if you find any, please send them to timeline@lwn.net.

LWN subscribers have paid for the development of this timeline, along with previous timelines and the weekly editions. If you like what you see here, or elsewhere on the site, please consider subscribing to LWN.

For those with a nostalgic bent, our timeline index page has links to the previous thirteen timelines and some other retrospective articles going all the way back to 1998.

April

Texas Linux Fest is held April 2 in Austin (LWN articles: HeliOS and The mobile ecosystem).

Mozilla reabsorbs Mozilla Messaging, which makes the Thunderbird email client, after spinning it off in 2007 (announcement).

Camp KDE is held in San Francisco April 4-5 (LWN coverage: Qt open governance, Using Slackware to investigate KDE 4, and Geolocation).

The Linux Filesystem, Storage, and Memory Management Summit is held April 4-5 in San Francisco (LWN coverage: Future storage technologies and Linux plenary session, the rest of Day 1, and Day 2).

The Yocto Project releases version 1.0 of the embedded distribution builder (announcement, release notes).

GNOME 3.0 is released (press release, release announcement, Grumpy Editor review).

LLVM 2.9 is released as the last in the 2.x series from the compiler and toolchain project. (announcement, release notes).

The Linux Foundation Collaboration Summit is held April 6-8 in San Francisco (LWN coverage: Linux penetration, Yocto, and hardware success stories, Kernel panel, Project Harmony, and Building the kernel with Clang).

Pamela Jones announces the end of Groklaw, which is supposed to happen May 16, though, instead of shutting down, Mark Webbink takes over (LWN blurb).

CyanogenMod 7.0 is released bringing Android 2.3.3 ("Gingerbread") to the alternative firmware for mobile devices (announcement, LWN Grumpy Editor review).

The Embedded Linux Conference is held April 10-12 in the second week of multiple conferences held at the Hotel Kabuki in San Francisco (LWN coverage: Linaro power management work and A PREEMPT_RT roadmap).

Stefano Zacchiroli is re-elected as Debian project leader in an uncontested election (announcement).

The MySQL Conference & Expo is held April 11-14 in Santa Clara, California, and covers much more than just MySQL (LWN article).

The first Android Builders Summit is held April 13-14 in San Francisco (LWN coverage: Android beyond the phone and The guts of Android

FVWM releases version 2.6 after nearly 10 years of development on the window manager (announcement, LWN review).

Oracle announces that OpenOffice.org will become a "community-based project", which is the start of the move to Apache (press release).

The US Department of Justice announces a change to Novell's patent sale to CPTN Holdings (owned by Microsoft, Oracle, Apple, and EMC), which is aimed at allowing free software implementations of things covered by those patents (press release).

Google falls prey to the patent troll Bedrock Technologies for the Linux routing table implementation based on a 1997 patent on what is essentially open hashing (LWN article).

LWN offers a "maniacal supporter" subscription level for those who would like to pay $50/month—a surprising number of folks signed up at that level, but we can always use more ... (announcement).

WebM announces a cross-license initiative that is meant to operate as a kind of patent pool for users and developers of the video format (announcement).

Slackware 13.37 is released (announcement, LWN review).

Ubuntu 11.04 ("Natty Narwhal") is released with Unity as its default shell (announcement, press release).

LinuxFest Northwest is held in Bellingham, Washington on April 30 and May 1 (LWN coverage: Getting HTTPS everywhere).

May

OpenBSD 4.9 is released (announcement, list of changes).

Mozilla refuses a request from the US Department of Homeland Security to remove an add-on, which routes around domain seizures made by the agency, because there is no court order to do so (blog posting).

The Ubuntu Developer Summit is held in Budapest, Hungary May 9-13 along with the Linaro Development Summit (LWN coverage: UDS keynotes, Mark Shuttleworth interview, ARM platform consolidation (from LDS), UDS security discussions, LTTng in the Ubuntu kernel, and Linaro keynotes).

The Netherlands Unix Users Group (NLUUG) Spring conference is held May 12 in Ede (LWN article: Open telephony).

The Libre Graphics meeting is held May 10-13 in Montreal, Canada (LWN articles: Krita talks and Adaptable GIMP).

The LyX document processor releases version 2.0 (announcement, LWN pre-review).

Perl 5.14.0 is released (announcement, perldelta details).

Linux 2.6.39 is released (announcement, KernelNewbies summary, development statistics).

Miguel de Icaza announces the formation of Xamarin to create Mono-based products for Android and iOS after the Mono team is laid off by Attachmate as part of the Novell acquisition (announcement).

Former Red Hat general counsel Mark Webbink officially takes over Groklaw (announcement, parting interview with Pamela Jones at The H).

PGCon, the PostgreSQL conference, is held in Ottawa, Canada May 19-20 (LWN article).

Linus Torvalds starts considering a kernel version number change, which eventually results in 3.0 instead of 2.6.40 (lkml posting).

Fedora 15 is released (announcement, feature list).

MeeGo 1.2 is released in what turns out to be the last major MeeGo release (announcement).

The MeeGo conference is held in San Francisco May 23-25, presumably the last of those as well (LWN coverage: MeeGo's openness and transparency and MeeGo 1.2 on the N900).

Linux Mint 11 is released (announcement, LWN review).

openSUSE renames the openSUSE Build Service to the Open Build Service, changing the focus a bit while preserving the OBS acronym (announcement).

June

LinuxCon Japan is held in Yokohama June 1-3 (LWN coverage: A conversation with Linus and Android, forking, and control).

LibreOffice 3.4.0 is released (announcement, release notes, Michael Meeks's look at the cleanups that went into 3.4.0).

Mageia 1, the community-driven fork of Mandriva, is released (announcement, release notes).

Ubuntu's first long-term support release, 6.06 ("Dapper Drake") reaches its end of life (announcement).

Oracle starts the process of donating OpenOffice.org to the Apache Software Foundation (LWN blurb and article).

The venerable Kermit serial communications program is finally released as free software under a BSD license (LWN article).

Karen Sandler is named as the new GNOME Foundation executive director, succeeding Stormy Peters (announcement, LWN interview with Sandler).

Mozilla releases Firefox 5 (announcement).

AVM vs. Cybits case heard in Berlin, Germany, which is an important test of the GPL for embedded devices running Linux. A decision will have to wait until November (Free Software Foundation Europe press release, Harald Welte's blog post).

Nokia releases the MeeGo-ish N9 handset (LWN blurb and article).

GNU Awk (Gawk) 4.0 is released (announcement, LWN review).

Comments (none posted)

Page editor: Jonathan Corbet

Inside this week's LWN.net Weekly Edition

• Security: Loading signed kernel modules; New vulnerabilities in colord, glibc, nginx, qemu-kvm, ...
• Kernel: Per-cgroup TCP buffer limits; Irked by NO_IRQ; Validating Memory Barriers and Atomic Instructions.
• Distributions: Distribution "popularity"; Cerowrt, Red Hat, Ubuntu, ...
• Development: A proposal for a LibreOffice UI overhaul; Buildroot, GNUnet, LLVM, PostgreSQL, ...
• Announcements: SFLC, EFF seek DMCA exemptions; linux.conf.au, SCALE, ...

Next page: Security>>