Is Your Security Friend

Discussion in 'Linux Security' started by Eric Hansen, Sep 24, 2013.

  1. Eric Hansen

    Eric Hansen Moderator Staff Writer

    Likes Received:
    Trophy Points:
    PAM (Pluggable Authentication Module) is a mechanism very popular with Linux systems that allows not only Linux itself to provide user validation but easily make it so third-parties can as well. With the growing use of two-factor authentication being used for various services now there’s been a healthy dose of plugins for PAM as well. However, I want to discuss one of the original plugins:

    In short, is what authenticates you when you log in to a system (local, remote, some other weird mean that might be developed), so when you’re being prompted for your account’s password and it stealthly lets you enter it, is hard at work! While making PAM modules is a fun task (which I might do an article on soon), we’ll cover the internals later.

    There is an Easter egg of sorts (considering not a lot of people read man pages) in that pam_unix offers a lot more in terms of security than most would think. There’s a lot of options that can be passed to pam_unix in the /etc/pam.d/login file (and others that use pam_unix ;) ). I’ll be covering some of the better/more secure/useful/etc… ones.


    Originally there was “nullok”, which basically allowed empty passwords to be allowed through and users with such passwords could access the system. The way this is more secure though is if the TTY being used is the same as what’s set in /etc/securetty. This is beyond the scope of this guide but while it still shouldn’t be used, it adds a slight edge to the security side of things.


    If a module is ran before pam_unix, it will try to use the password from that module first before prompting the user. Useful? Sometimes, but I dislike the password being stored in memory longer than it actually needs to be so this doesn’t help any.


    Similar to above, with the exception being that the user is never prompted for a password if the previously-passed one does not work. Meaning that the user will be denied access without the system caring.


    Know those moments where you log in, or think you did, to sit and wait for a few seconds before it kicks back stating invalid username or password? This cuts down the wait time to 0 (zero) so you instantly know.


    Any options that deal with previous or future password use (i.e.: how try_first_pass will attempt the password provided to another plugin before prompting) is nullified and void with this. It basically tells pam_unix to not even care if they exist. Essentially this would make use_first_pass always deny the user access, for example.


    Replace n with a number and pam_unix, when changing passwords, will not allow the past n passwords to be used. These are saved in /etc/security/opasswd so keep that in mind if you use this. I don’t use this feature personally so I don’t know if data is encrypted or not (overall, it should be logically).


    Man pages say “try to maintain a shadow based system”. Only thing I can gather from this is to enforce /etc/shadow instead of /etc/passwd, which is the default these days anyways. Legacy option?

    sha512 / blowfish

    They do the same thing but are two different options. Not sure if you can combine them, but would be interesting.

    Basically when a user changes their password, it’ll be hashed to sha512, blowfish, etc… There’s a few options but I’m most familiar with sha512 and blowfish and suggest them. If crypt (which is used to hash the password) can’t recognize the hash algorithm then it’ll switch to md5 (original default).


    Set the number of rounds pam_unix/crypt should go through when hashing the password. This is valid for SHA256, SHA512 and BlowFish, which most guides will tell you to use 5. Personally I like to test how big I can make the rounds before my system begins to choke. I’d set it to 10 and increment by 10’s if you have the patience and time.


    Similar to rounds=n and remember=n, specifies the minimum length allowed for a password. The default is 6 (so if you pass minlen without the “=n” part it’ll enforce a 6-character minimum). While nice it may or may not be necessary.


    This is kind of a weird option in a way but essentially it performs some extra checks when validating password strength. It goes through a few checks, which are:

    • Palindrome - Makes sure the new password isn’t the reverse of the last password

    • Case Change Only - Similar to palindrome but involves casing instead of reversing

    • Similar - Ensures the old and new one aren’t similar to each other

    • Simple - Complex passwords have to be used instead of “password”

    • Rotated - Similar to palindrome again but checks to make sure your password of “inuxl” isn’t similar to your old one of “linux”

    Attached Files:

Share This Page