where the options have been specified according to the usbadm man page under cipher.
The fs= option tells pam_usb what filesystem to try to use to mount and read the USB drive. If your users have different filesystems on their USB drives, you'll have trouble with this. Simply specify whatever filesystem is used on your USB drives.
Once you've made the configuration changes to su's PAM configuration, it's time to set up a cryptographic key pair for each user using the system. Initially, this is done simply with:
usbadm keygen /path/to/mounted/usb/drive keysize
where keysize is the size (in bits) of the keys you want to generate and /path/to/mounted/usb/drive is the—you guessed it—path to the root of your mounted USB drive. For my setup, I chose a key size of 4,096 bits, which should be adequate to prevent even determined brute-force attempts against your key pair. RSA Labs recommends that DSA keys be no smaller than 2,048 bits, so at a minimum use a 2,048-bit key size. The usbadm program generates files in the root of your USB drive called .auth/$USER.$HOST, where $USER is the user name that executed the usbadm command and $HOST is the hostname of the machine on which the keys were generated. A corresponding set of keys in ~$USER/.auth must be present to authenticate with the USB token.
If a USB drive is lost, as is bound to happen, you can remove the user's ~/.auth/id_pub file and follow the instructions above to regenerate the key pair. Be certain you don't lose root's private keys or you'll have to boot to safe media, disable two-factor authentication and go through the whole setup process again to restore functionality.
Having freshly minted your key pair, you now are ready to test pam_usb and two-factor authentication with su. Insert your USB drive and try to su to a user who has a valid key pair; it's best to test this from a non-root account. You should be prompted for your user name as before, but instead of being prompted for your password immediately, you now should see a USB error as pam_usb tries to mount /dev/sda, or whatever base device you told it to try. Provided pam_usb was able to locate your USB drive, you should be prompted for the user's password, which if entered correctly, should result in a shell for that user account. You can make sure that the two-factor authentication worked by checking the pam_usb log file and verifying that somewhere near the last line is a line that reads Access granted. If you see that line in the pam_usb.log file, congratulations—su now is configured to use two-factor authentication.
Once you are satisfied with the functionality of pam_usb for su, you can duplicate the configuration for su with other applications that you want to set up with two-factor authentication. Be sure to issue all users the necessary keys and thoroughly test things before you log off the system and/or reboot.
As with any authentication system, two-factor authentication is not without its weaknesses. This particular implementation is vulnerable to private key theft, because it's easy to copy the contents of the USB drive. In the March 15, 2005, Crypto-Gram, Bruce Schneier writes a rather scathing article detailing why two-factor authentication is not the end-all-be-all of authentication—the crux of his point is that people are using two-factor authentication to achieve things it wasn't meant to achieve. With that in mind, remember that two-factor authentication is meant to address the age-old problems of password-based attacks. pam_usb achieves that end very well, and if properly configured, it can effectively improve the security of a given workstation.
Resources for this article: /article/8528.
Corey Steele is a security expert with six years of experience; he received CISSP certification in 2004. His primary interests in the security arena are access control and network security. He works in the financial sector for a company that makes core banking software. He has been an active member of the Free/Libre/Open Source Software community, having contributed to various projects, since 1995. In his spare time, he likes to write code and lecture on security topics.
Webinar: 8 Signs You’re Beyond Cron
11am CDT, April 29th
Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.Join us!
- New Products
- Not So Dynamic Updates
- Users, Permissions and Multitenant Sites
- Flexible Access Control with Squid Proxy
- Security in Three Ds: Detect, Decide and Deny
- Tighten Up SSH
- DevOps: Everything You Need to Know
- Non-Linux FOSS: MenuMeters
- Solving ODEs on Linux
- Android Candy: Bluetooth Auto Connect