User: Password:
Subscribe / Log in / New account

Passwords in home?

Passwords in home?

Posted Mar 26, 2012 10:31 UTC (Mon) by migpc (guest, #24484)
Parent article: Shadow hardening

The proposal of having user's local password in a separate folder per user is very interesting. However, the locations suggested /etc/tcb or /etc/hardened-shadow are machine related, not user related; and passwords are user related. Wouldn't make sense to have passwords stored in a secured folder under user's home directory (like /home/linus/.shadow/)?. This would ease a lot machine migrations, backups and even local validation using shared directories.

Do you find any caveat to this alternative?

(Log in to post comments)

Passwords in home?

Posted Mar 26, 2012 13:46 UTC (Mon) by anselm (subscriber, #2796) [Link]

Your setup might require authentication to actually get at the user's home directory in the first place, in which case you would have a chicken-and-egg problem if you needed to access the user's home directory in order to do the authentication.

Also, if you wanted to enforce restrictions on passwords (e.g., minimum length, aging, …) that would be difficult if a user's password was stored in a place that was under the user's control so they could mess with it in whatever way they desired. You could try to work around this by signing and/or encrypting the password file but that would not only make things a lot more complicated but would probably introduce another machine dependency (the keys to do the signing/encryption), at which point you'd be back where you started.

Passwords in home?

Posted Mar 27, 2012 16:41 UTC (Tue) by phajdan.jr (subscriber, #83686) [Link]

Right, those are real issues with the indeed interesting suggestion.

1. The user directory may not yet be mounted. Suppose it's mounted from an encrypted volume, and the password for that volume is the user's password. It's a pretty legitimate use-case and I'm pretty sure many people already do something similar using PAM.

2. The ways user can mess with the directory under his home are somewhat limited. If the protected directory has at least one file, the user won't be able to delete the directory. However, he can rename it, and create a new one with the same name. Now we can check the permissions of the dir (user can't chown to root), and it even shouldn't be racy thanks to openat calls. The problem is that the account's aging info would be inside that protected directory, so by moving it out of the way the user could cause some trouble with loss of that management data.

Anyway, it may be worth to try more and find some solutions for those problems, maybe by using some slightly different approach. Such discussion is certainly welcome, either here or on the project's mailing lists - see

Passwords in home?

Posted Mar 27, 2012 17:21 UTC (Tue) by jspaleta (subscriber, #50639) [Link]

As to 1)

There is already a similar real-world situation with ssh keys.
Normally ssh keys are handled in a per user fashion and are stored in $HOME/.ssh/ on traditional multi-user linux distribution.

On linux distributions which encourage the use of ecryptfs for home directories.. the default ssh configuration which looks for ssh keys stored in $HOME/.ssh/ no longer works if the user is not already logged in via another means. Password login via ssh still works (if its enabled) because the pam stack for ssh is looking at the systemwide passwd/shadow information. If the user password was in the home directories, then ecryptfs-like encyption of home directories would have to be re-engineered.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds