This site is now 100% read-only, and retired.

Implementing cost effective dual factor authentication

Posted by MaxLock on Tue 20 Mar 2007 at 03:32

A great way to improve security on your systems public services is to add an extra factor to your authentication scheme. Here we'll show what that means and how it works.

An extra factor means that in addition to something you know such as a password, you also have to prove posession of something you own, a physical object.

The physical object can take a number of forms, from a printed grid of passcodes often known as a 'one time pad', to a sophisticated electronic key sometimes implemented as a keychain with an ever changing code on an LCD screen.

When using a one time pad, a user is given a passcode reference, to which he must respond with the correct passcode from the pad. Electronic keys typically use the current time to hash a known secret and the system simply prompts for this.

Each approach to the physical item has it's advantages and disadvantages, for example cost, in the case of electronic keys, or convenience with a pad.

Open source implementations of these schemes have been created such as OTPW but the electronic key type schemes obviously still incur a hardware cost. However due to the increasing capabilites of the ubiquitous cellphone it's possible to implement an electronic key as a java midlet, reducing expenditure on specialised hardware.

FreeAuth implements an electronic key system, utilising a mobile phone. It comprises of two parts, a PAM plugin and a java midlet. First grab a copy of both the FreeAuth code and java midlet, i'd recommend version 2.3.10 upwards of the midlet.

To compile pam_freeauth, you will need to install the pam headers. To get these you can simply run:

apt-get install libpam0g-dev

next unpack the pam_freeauth archive you previously downloaded, and build it:

cd pam_freeauth
make clean
make install

This will place the freeauth pam module in /lib/security. Next copy the file freeauth.conf into /etc/security and update the permissions:

cp -a freeauth.conf /etc/security
chmod 600 /etc/security/freeauth.conf

Lets now setup PAM to use Freeauth for ssh, go to the /etc/pam.d directory, and using your favourite editor, edit the ssh file. Comment out the "@include common-auth" directive, and add the following line above it:

auth required pam_freeauth.so

Now restart the ssh service:

/etc/init.d/ssh restart

Finally you'll need to make sure your clock is accurate on both your phone and your system. I'd recommend installing NTP to keep your system clock accurate:

apt-get install ntp-simple

Now you need to install the java midlet on your cellphone to generate passcodes that freeauth will accept. This process varies wildly between manufacturers and phones, and is beyond the scope of this article. On my Motorola SLVR, the process involved connecting a usb cable, and uploading the midlet using the moto4lin package.

The first time you run the java midlet, you're prompted for a pin number, which you must remember, then 20 random keypresses to create a new shared secret. Next you enter an alias for the secret, such as a domain name. Finally the midlet will display the secret it has generated, this secret must be added to your /etc/security/freeauth.conf file, at the same time removing any example entries that may be there:

# user          secret
username        0123456789abcdef

You're now ready to test. Restart the java midlet. Enter your pin number, and the midlet will display a passcode, and a countdown to the next passcode, there's also a time zone button which controls the timezone and displays the current phone epoch time. This must be set close to the system epoch time. You can display the system epoch time using this command:

echo "`date +%s` / 60" | bc

Finally ssh to your system, when prompted for a passcode, enter the passcode displayed on the phone, and you'll be authenticated. I've used this system for the past few weeks now, and it's proven reliable and very cost effective compared to commercial offerings.

 

 


Re: Implementing cost effective dual factor authentication
Posted by Anonymous (128.143.xx.xx) on Tue 20 Mar 2007 at 20:34
Sounds like a great setup and seems very similar to my own except for choice of packages. I utilized OTPGen on the phone side (http://marcin.studio4plus.com/en/otpgen/index.html) and OPIE which has the advantage of being in apt.

Configuration is equivilent to what you describe but the security in this system is based off of the hash of a secret (RFC 2289) rather than the current time plus a secret.

Dual factor authentication is fantastic, I no longer have to be carrying around an ssh private key if I want to ssh in to my machines (I've been the subject of an ssh brute forcing attempt in the past like I'm sure most here).

Will

[ Parent ]

opie (rfc 2289) and two-factor auth
Posted by undefined (192.91.xx.xx) on Wed 21 Mar 2007 at 22:03
two things:
- i use opie like another poster, but with palmkey (previously on a visor deluxe, now on a palm z22).
- i think calling auth by only a one-time password (however it is generated, in whatever form) "two-factor auth" is a bit stretching.

the downside to rfc 2289 (as implemented in opie):
- a little difficult to set up (opie doesn't seem to be widely used and therefor lacks a depth/breadth of documentation; pam with its different modules and stacking is itself complex)
- i've only ever seen it used in interactive shell-based protocols (ssh, telnet) presumably due to the challenge-response requirement (server issues hash, count, & seed).

supposedly the cyrus sasl library has a 2289 implementation, which means servers using that library should be able to use otp, but no server seems written to display the challenge to the user. even if the server application did display a challenge, would the client know how to relay it to the user. most clients are configured to receive both the username and passphrase from the user at the same time, but the challenge is user-specific and cannot be issued until after the username is submitted. ssh & telnet work because the client just displays directly to the user whatever text is received from the server and the user has the responsibility of interpreting it and responding correctly (whether that is entering a system password, a one-time password, or entering the captha from the displayed ascii art ;-).

2289 seems to be well thought out in theory, but too different from the norm to see wide adoption.

plus opie (not rfc 2289) is minorly broken from a security perspective:
- incorrect answers don't decrement the password count so brute-force attacks are possible (i've heard libpam-opie should, but my installation doesn't)
- user discovery is possible as repeated attempts to log into an invalid account generates random counts & seeds (where a valid account will generate the same or decreasing counts with a constant seed).

freeauth gets around all this by not issuing a challenge. that's somewhat problematic as it is not clear to users what type of authentication is being used (eg "It asked for a password so i just kept entering my pin but it never accepted it.") and the time synchronization cannot be verified (it would be helpful if the server printed at login what it thought the unix epoch was). the freeauth "challenge" wouldn't even need to be displayed between the username and password as with 2289. opie could get rid of the challenge to conform with standard login mechanisms and make the user track what the hash, count, & seed are (palmkey does this as long as you don't press the "clear" button), but that would be problematic for the user. actually, this might be how the opie pam-module works in practice with a login process that ignores challenges.

in custom applications, rfc 2289 and freeauth can probably both be integrated with the same difficulty, but in a system like pam (pluggable authentication modules), they deviate too far from the usual username-passphrase to be widely used.

finally, i wouldn't call one-time passwords "two-factor auth" because there's really only one distinct input given by the user: the hash of time, shared secret, and pin. the pin and shared secret are not really distinct because you combine the two to get your one-time password. i store all my passwords in the keyring password manager (a palm app), which itself is password protected. so is that two factor authentication: it requires the keyring password (something i know) and the keyring database (something i have)? what if all my passwords were 32 characters long, where i memorized the first 4 characters and the remaining 28 were stored on a hardware device? rsa's securid is considered two-factor because the inputs are kept entirely distinct: your pin is unrelated to the time-based one-time password (which is so complex it necessitates a computing device, something you have).

freeauth is essentially cram-md5 auth where the challenge string is not issued (because the time is assumed to be the same by both parties) and the passphrase is broken into two parts: one part remembered by the user and the other part stored on a device. but no one considers cram-md5 "two-factor" no matter how the password is stored by the user.

sorry to be pedantic, but two-factor authentication is not trivial, so i hate to see it trivialized (just as most free-open-source-software advocates hate to see foss trivially refered to as "freeware", though both are practically the same from the non-programmer perspective).

thanks for the freeauth article!

[ Parent ]

Re: opie (rfc 2289) and two-factor auth
Posted by MaxLock (202.73.xx.xx) on Thu 22 Mar 2007 at 01:56
Hiya,

I agree with the comments above totally :) What I should've covered is how to setup pam so that it requires both a regular password _and_ the OTP generated by Freeauth. I'll have a look at it tonight.

[ Parent ]

Re: opie (rfc 2289) and two-factor auth
Posted by Anonymous (80.202.xx.xx) on Sun 1 Apr 2007 at 21:38
To enable both passcode and password, add this to /etc/pam.d/ssh:

auth required pam_unix.so nullok_secure
auth required pam_freeauth.so not_set_pass

and comment out:
@include common-auth

Warning: If you do the same in common-auth, you will need a passcode for all logins, except for "recovery-mode" boot-option in GRUB.

[ Parent ]

Re: Implementing cost effective dual factor authentication
Posted by randallb (68.45.xx.xx) on Thu 22 Mar 2007 at 20:29
I just tried out both FreeAuth and Mobile-OTP, the project which FreeAuth is based on.

I like the simplicity of the Mobile-OTP midlet, however, FreeAuth is definitely more secure, as it does not store the PIN on the server (this is the biggest problem I have with Mobile-OTP's design) and it encrypts the data on the phone (using the PIN).

It amazes me how similar these are to the Safeword token system that I used at a former employer, but without the high price.

[ Parent ]

Re: Implementing cost effective dual factor authentication
Posted by Ledbo (82.16.xx.xx) on Sun 25 Mar 2007 at 21:00
Hopefully this might help someone else.

I've been banging my head against the wall trying to get this to work, playing around with the sshd_config file to see if I was missing an option there and treble checking the time on the phone, etc.

Nothing has worked until I went back and re-read the freeauth README.
That has an additional step not shown here, it says freeauth needs a cache folder.
I created a /var/cache/freeauth folder and it's all working fine.

Has anyone else had the same problem? I'm doing this on a fairly vanilla installation of Etch, with ssh set for shared-key login only.

[ Parent ]

Re: Implementing cost effective dual factor authentication
Posted by Anonymous (80.202.xx.xx) on Sat 7 Jun 2008 at 17:46
Notice: The pam_freeauth module won't work if the sshd_config option:

ChallengeResponseAuthentication

is set to no. To make it work, either comment out the option, or set it to yes.

[ Parent ]