I would like to have different passwords for my account(s): When (e.g.) a certain USB stick is plugged in then an easy password is to be used. The idea is: If I leave my computer then I take the stick with me and the easy passwords shall be disabled then.

My general idea is:

  1. Detect the stick with udev, maybe detect certain data on it (with a script run by udev) and react accordingly (e.g. create a file which is deleted when the stick is plugged out). This should be easy.
  2. Have PAM check for the existence of this file and select the password database accordingly.

The main question is probably (i.e. if I understand the structure of the problem correctly): Can pam_unix2 be configured to use another shadow file? I just had a look at the man page for pam_unix2 and it seems that this is not possible because this module lets glibc NSS make this decision.

  • 1
    This seems very plausible to me. I would expect it may be completely done just with PAM modules and nothing more. There are conditionals in PAM that would allow for checks to be skipped over if certain criteria weren't met. – slm May 28 '14 at 13:29
  • This looks like what you're asking for: suse.com/communities/conversations/… – slm May 28 '14 at 13:31
  • @slm Interesting but this is about replacing password authentication not about modifying it, isn't it? – Hauke Laging May 28 '14 at 14:00

Both pam_unix and pam_unix2 use libc to look up the password hash, and Glibc has the locations /etc/nsswitch.conf and /etc/shadow hard-coded. It wouldn't even be as simple as recompiling pam_unix or pam_unix2: both go through the normal NSS mechanism to verify passwords, they only use their knowledge of /etc/passwd, /etc/shadow and NIS for password changes.

However, you can use the pam_pwdfile module. I've never used it, but the description looks like exactly what you're after.

This PAM module lets you use an arbitrarily-named text file similar in structure to /etc/passwd to authenticate users.

Alternatively, you could use the pam_userdb, which checks a password in a database in Berkeley DB format with a file name passed as an argument.

Now, to detect the presence of the USB stick, you need another PAM module. pam_listfile looks right for the job. Arrange an udev rule that mounts your USB key, and only that USB key, in a particular location, say /media/authentication-key; create a file users.txt containing the list of user names that are allowed to use a shorter password. If you want a more complex test in the PAM stack, you can use `pam_exec.

Here's a stack that assumes that /etc/shadow contains your strong passwords and /etc/passwd.weak contains your weak passwords. Warning: untested, and I'm not fluent in PAM, so review it carefully.

auth [success=ignore default=1] pam_listfile.so file=/media/authentication-key/users.txt iter=user sense=allow onerr=fail
auth [success=1 default=bad] pam_unix.so
auth [success=ok default=bad] pam_pwdfile.so pwdfile=/etc/passwd.weak
auth requisite pam_deny.so
|improve this answer|||||

It just came to my mind that the difficult part I had in mind could be replaced by a very simple operation:

It is probably not necessary to configure PAM to use either one password file or the other: It should be possible to just replace /etc/shadow by a symlink and have the script which it triggered by the udev add and remove events to replace this symlink so that the normal PAM procedure (implicitly) uses the one or the other version of the file.

This way some accounts can be prevented from logins completely without the hardware token.

|improve this answer|||||
  • This may be a solution but if you have better ideas I am interested. :-) – Hauke Laging May 28 '14 at 14:07
  • I like your question: but if you do so you will change it for all the users. And this will work for each kind (even remote) of login :-S – Hastur May 28 '14 at 14:14
  • One other idea would be to write a /etc/profile.d script that checks for the existence of a filesystem with the UUID that's on the USB stick. If it's present it just exits normally, if it isn't it could prompt for a second harder password. If the password fails, then the user is logged out with a fuser -k $(tty) or something to that effect. – Bratchley May 28 '14 at 14:15
  • 2
    There's also potential for data coherency problems if you have two different shadow file copies. Especially as users are added or removed. – Bratchley May 28 '14 at 14:16
  • @Hastur Remote logins with passwords? :-) But you are right: A real PAM solution would be better. – Hauke Laging May 28 '14 at 14:44

Let's suppose you write a shadow-easy password file with the device UUID that authorizes the substitutions for password, the username, the Not easy password and easy password encrypted.

This only for the users that require easy-password.

It's possible to think about a substitution of the encrypted string only for that specific line on the etc/shadow. Only when an authorized device (with some data....) is plugged in.

When you add/remove users or modify password the 2 encrypted strings will not match and the substitution will not happen. So you need to log with the full password, and after to act in other way.

I don't want to think what can happens when there is a shortage of power when you touch shadow file, or if the script crashes...

It remains the problem that it will function for all the kinds of login even remote. And even if someone will send commands via ssh. But it can function :)

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.