Hacker News new | past | comments | ask | show | jobs | submit login

This nice solution is minimal, well scripted and very UNIXy. However, one tradeoff is that filenames for the stored password are plain. Running the tree command on the directory where encrypted files are stored would give us something like,

    $ tree .password-store
    irc
    ├── efnet
    └── freenode



For this reason I'm thinking of switching from gpg to encfs. It has an option for auto-unmounting after a period of unactivity. It would also play well with programs that need to read password from a file.

Has anyone else here had the same thought? This guy seems to at least;

https://github.com/equivrel/password-store-encfs/blob/master...

Edit: spelling


Would be much easier and still acceptable to simply mount the password-store on encfs.

Could use autofs to make it auto mount when pass accesses the mount point.


That would mean two stages of password query, which I think might be a con. Also, the file names would either not be encrypted in the git repo or not be compatible with e.g. Android app I guess.

Thanks for the autofs hint, will try it and see how that works out re unlocking.


Yes, it even has a built-in pass ls (which uses tree). It might be a feature, depends on how you look at it.

Frankly, just encrypt the entire drive. Otherwise, there will always be a leak somewhere. If not in the file structure, then in the swap.


You can avoid a lot of these types of issues using a digest for the username and password plus a master key as a salt. It generates a unique and relatively complex sequence for each site and doesn't require any persistent state other than the salt.

The downside is a lack of control over complexity and the issue of passwords being strictly dependent on the salt. So, if one set of credentials is compromised, you would need update them all.

I've seen software that does this, but there are subtle details to consider to actually get it correct.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: