Password Mapping

Lenz Weber mail at lenzw.de
Sun Feb 12 21:52:55 CET 2017


we really need some kind of FAQ on this - this question is asked about
once a month.

first of all: if you try to encrypt file names, there is not any
advantage of using one file for each password any more. You might just
switch to a completely different product as pass might just not be the
tool for you.

now let's take a look at your threat model. There are three cases:
1) someone has access to your git and can see your folder structure.
2) someone has access to your harddisk
3) someone has access to your system while it is on and can read your
home directory

1) ecrypt your git. git-remote-gcrypt might be the tool for you
2) encrypt your harddisk, or the folder with pass in it. there are
plenty of tools
3) in this case, the attacker can also read your memory, log your
keystrokes and wait for you to unlock your passwordstore to steal all
your passwords. no need to care about metadata. you are royally fucked.

in this light, all that is left is security theater. you might feel more
secure, but in the end you aren't. you are just trading simplicity and
interoperability for security through obscurity.

regards,
lenz



Am 12.02.2017 um 21:40 schrieb Johannes Marbach:
> Hi everyone,
> 
> I couldn't find anything about this in the list archives so if this has
> been brought up before, I sincerely apologize.
> 
> I really like pass's simplicity but one thing that worries me is that
> the file and folder structure is kept in plain text. To illustrate what
> I mean consider the following password store
> 
> $ pass
> Password Store
> ├── cards
> │   ├── amex
> │   └── visa
> ├── mail
> │   └── gmail
> └── sites
>     └── last.fm <http://last.fm>
> 
> which is translated 1:1 to files and folders
> 
> $ tree .password-store/
> .password-store/
> ├── cards
> │   ├── amex.gpg
> │   └── visa.gpg
> ├── mail
> │   └── gmail.gpg
> └── sites
>     └── last.fm.gpg
> 
> I think this potentially increases the surface for an attacker. Even
> though the files are still securely encrypted, I wouldn't even want
> someone to know that I have e.g. a Visa credit card or a gmail account.
> 
> What I've seen people do to avoid this is a combination of random IDs
> and a mapping in a separate encrypted file.
> 
> $ pass generate -c $(pwgen 8 1) 20
> Copied aidei2OY to clipboard. Will clear in 45 seconds
> $ pass insert mapping --multiline # or "pass edit mapping" for further
> changes
> # Add "aidei2OY: gmail" or something similar
> 
> This is pretty clever and hides any information beyond the number of
> folders and files inside them from an attacker. However, it makes any
> further access to the passwords more cumbersome as the mapping has to
> reversed (e.g. using "pass grep") to find the correct file.
> 
> My question is whether it wouldn't make sense to build this into pass
> itself? Upon password insertion, the mapping could be created and then
> all further commands could automatically resolve the IDs. Keeping with
> the above example this would mean that I could, for instance, use "pass
> gmail" instead of "pass aidei2OY".
> 
> I'd really like to hear people's thoughts on this.
> 
> Thanks,
> Johannes
> 
> 
> _______________________________________________
> Password-Store mailing list
> Password-Store at lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/password-store
> 


More information about the Password-Store mailing list