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.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Peppermint 7 Released
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Sony Settles in Linux Battle
- Libarchive Security Flaw Discovered
- Maru OS Brings Debian to Your Phone
- Understanding Ceph and Its Place in the Market
- Profiles and RC Files
- Snappy Moves to New Platforms
- The Giant Zero, Part 0.x
- Git 2.9 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide