3 ms·

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

by raldu 11y ago

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

blfr 11y ago
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.
uxcn 11y ago
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.
tbe 11y ago
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/add-encfs.patch https://github.com/equivrel/password-store-encfs/blob/master... Edit: spelling
- INTPenis 11y ago
  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.
  - tbe 11y ago
    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.

by raldu 11y ago

blfr 11y ago

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.

uxcn 11y ago

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.

tbe 11y ago

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/add-encfs.patch https://github.com/equivrel/password-store-encfs/blob/master... Edit: spelling

INTPenis 11y ago
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.
- tbe 11y ago
  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.