Skip to main content

Two factor authentication

Two factor authentication, how hard can it be?

Two factor authentication has two components: something you know, and something you have. Something you know is usually username&password and gives you the first factor. Something you have is a second factor and it isn't usually implemented.

One can argue that private/public key encryption is strong, but it's not two-factor authentication into the computer systems. An ssh key or SSL certificate can be password protected, but it's still just a file on the computer usually. And you don't want someone to compromise user's laptop, take as long as they need to decrypt the password and use that to get access to your intranet.

The criteria are:
  • two-factor authentication
  • open standard
  • vendor independent
  • free software stack available
  • secure
  • user friendly
  • low-cost
So let's start running down the systems available today for the two factor authentication:
  1. Smartcards / Tokens using PKCS #11 API & PKCS #15 standard
  2. Hardware / Software Tokens using OATH HOTP or TOTP standard
  3. Yubikey Token with Yubikey Validation standards
Smartcards, while common in everyday live are not very convenient. You need smartcard reader with you, you get authentication prompts from you browser which look different across all platforms. There is cost of buying smartcards & smartcard readers. Not sure how that would work with SSH. Can't use it on your mobile. This is probably a good solution in managed enterprise networks with single sign on implemented with Kerberos. So it's not an easy solution. And I haven't looked much into it.

OATH is Open Authentication initiative behind the one-time password (OTP) authentication using event or time based. It's a simple nice algorithm, which you can read about here. It generates 6-8 digit long one time password using a seed (initial secret) and variable. In event based form it's just a sequential counter, in time based it's the time. There are many hardware and software tokens available on the market. So it's one contender I'm looking into.

YubiKey is a battery-less USB token with touch sensitive button. It simulates a usb keyboard and "types" passwords. It can be configured to produce: 32 character yubikey OTP, 6-8 digit OATH HOTP or long static password. Later yubikeys also added challenge-response functionality as well. The cool thing is that the hardware design and yubikey OTP documentation is published. And all the software around it is Open Source. There isn't another hardware vendor though.

Now implementation details. For my use case I need: central validation server, pam authentication module, over the network authentication, authentication plugins for specific applications (e.g. OpenERP, Drupal, etc.).

For Yubikey: there are multiple opensource validation servers, multiple pam modules (including those that work against validation server over the network), multiple plugins for many applications out there. There is an investment cost for the Yubikeys ($25 each, cheaper if buying in bulk +VAT +Shipping) and you are locked to a single vendor of the keys.

For OATH: found only one validation server, which is a dead work of a dead original... there is oath-toolkit with pam module, but it means storing the secret seeds on each machine where you want to authenticate, cause it doesn't talk securely to a validation server over the network.

Underdog is yubikey-yubiserve which is OATH HOTP/YubiKey validation server using YubiKey validation protocol (REST API over SSL with client API signatures). But they aren't HOTP pam modules which know how to talk over YubiKey validation protocol.

I'm thinking to modify c-yubico-pam module to accept OATH HOTP and use yubikey-yubiserve. Then I get open source stack, vendor independence, awesome user experience with yubikey OTP, worse user experience with OATH HOTP, but at least I will be able to mix and match ;-)

ps. fedora project and CERN are using yubikeys, so maybe it's not that bad. any takers for software yubikey generators for JavaME / Android / iPhone / MeeGo / Desktop?


  1. This is really great work you're doing, and I applaud it.

    I'm ignorant about most of the security issues, but would it be possible to use an XMPP server with OTR to send the OTP? That seems it would mean the widest uptake by devices (so that you didn't need to write apps for each device you wanted to support). Then you could count on Android, Blackberry, or iOS to supply the OTP to the user. Google's SMS method seems to work well enough, but SMS charges could be avoided by the use of XMPP.

    Just a thought. I'm sort of against a solution which requires specific hardware (Yubikey) to participate.

  2. We invite you to check out our (free) offering at Duo Security:

    Drop-in open-source integrations for Unix, web, etc. and support for HOTP OTPs, phone callback, SMS OTPs, and smartphone push. :-)

  3. I have recently tried a paper-based OTP solution, specifically It is simple and works like a charm with PAM. At first, paper seems a little low-tech, but it IS cheap.

    This is on one server, so I do not know about the central auth server part.

  4. Two factor authentication has two components: something you know, and something you have. Something you know is usually username&password and gives you the first factor. Something you have is a second factor and it isn't usually implemented. Complete agree! Cheap SSL | RapidSSL

  5. This comment has been removed by the author.

  6. Hi Dmitrijs,

    Have you made any advances on this?

    Have you tried Google Authenticator ? It has a PAM module...

    Any tests with OpenERP ?


  7. I want to run my own server. Google Authenticator is simply a client to generate OTP codes locally. The pam module doesn't provide a server that you can authenticate against remotely.

    OpenERP supports multiple authentication methods, but it's not an OTP server. E.g. you plugin is one of the auth_* modules and OpenERP will listen to what that says.


Post a Comment

Popular posts from this blog

How to disable TLS 1.0 and TLS 1.1 on Ubuntu

Example of website that only supports TLS v1.0, which is rejected by the client Overivew TLS v1.3 is the latest standard for secure communication over the internet. It is widely supported by desktops, servers and mobile phones. Recently Ubuntu 18.04 LTS received OpenSSL 1.1.1 update bringing the ability to potentially establish TLS v1.3 connections on the latest Ubuntu LTS release. Qualys SSL Labs Pulse report shows more than 15% adoption of TLS v1.3. It really is time to migrate from TLS v1.0 and TLS v1.1. As announced on the 15th of October 2018 Apple , Google , and Microsoft will disable TLS v1.0 and TLS v1.1 support by default and thus require TLS v1.2 to be supported by all clients and servers. Similarly, Ubuntu 20.04 LTS will also require TLS v1.2 as the minimum TLS version as well. To prepare for the move to TLS v1.2, it is a good idea to disable TLS v1.0 and TLS v1.1 on your local systems and start observing and reporting any websites, systems and applications that

Ubuntu 23.10 significantly reduces the installed kernel footprint

Photo by Pixabay Ubuntu systems typically have up to 3 kernels installed, before they are auto-removed by apt on classic installs. Historically the installation was optimized for metered download size only. However, kernel size growth and usage no longer warrant such optimizations. During the 23.10 Mantic Minatour cycle, I led a coordinated effort across multiple teams to implement lots of optimizations that together achieved unprecedented install footprint improvements. Given a typical install of 3 generic kernel ABIs in the default configuration on a regular-sized VM (2 CPU cores 8GB of RAM) the following metrics are achieved in Ubuntu 23.10 versus Ubuntu 22.04 LTS: 2x less disk space used (1,417MB vs 2,940MB, including initrd) 3x less peak RAM usage for the initrd boot (68MB vs 204MB) 0.5x increase in download size (949MB vs 600MB) 2.5x faster initrd generation (4.5s vs 11.3s) approximately the same total time (103s vs 98s, hardware dependent) For minimal cloud images that do not in

Ubuntu Livepatch service now supports over 60 different kernels

Linux kernel getting a livepatch whilst running a marathon. Generated with AI. Livepatch service eliminates the need for unplanned maintenance windows for high and critical severity kernel vulnerabilities by patching the Linux kernel while the system runs. Originally the service launched in 2016 with just a single kernel flavour supported. Over the years, additional kernels were added: new LTS releases, ESM kernels, Public Cloud kernels, and most recently HWE kernels too. Recently livepatch support was expanded for FIPS compliant kernels, Public cloud FIPS compliant kernels, and as well IBM Z (mainframe) kernels. Bringing the total of kernel flavours support to over 60 distinct kernel flavours supported in parallel. The table of supported kernels in the documentation lists the supported kernel flavours ABIs, the duration of individual build's support window, supported architectures, and the Ubuntu release. This work was only possible thanks to the collaboration with the Ubuntu C