Re: encrypted file and directory names?

[Kevin Lyda]

Encrypted path and filenames would be an extreme complication for zero
gain. Pass is a simple wrapper around git and gpg and works very well
because of that.

If someone is on your system and can look in your $HOME then they can find
the sites you visit from you shell history files, browser history and cache
files, SSH config files, mysql history files and so forth.

The files are encrypted because even with that information (which you
should assume they know) they still can't get the secrets.

Overcomplicating security tools makes them harder to use, which makes them
less used, which reduces security overall. So please don't do that.

Kevin

On Sat, 4 Feb 2017, 17:51 Adam Spiers,  wrote:

> Hi all,
>
> I was delighted to discover this project recently.  It seems to be
> almost exactly the perfect solution needed to avoid the unpleasant
> situation of being reliant on a proprietary password manager.
>
> There is one feature which I consider pretty essential, and as far as
> I can see, it's not supported by pass yet, which is to keep the entire
> metadata encrypted, including the directory names and file names.
> Without this it doesn't seem to provide 100% privacy protection, since
> for example it potentially exposes which websites you use.  Is that
> right, or am I missing something?
>
> If I'm right, would this be an easy thing to solve architecturally?
> For example, the directory names and file names could be converted
> into some kind of digest (e.g. SHA-256), and then a mapping between
> digests and the original names could be tracked in a separate
> encrypted file at the top level of the store.
>
> Thanks!
> Adam
> ___
> Password-Store mailing list
> Password-Store@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/password-store
>
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

Re: encrypted file and directory names?

[Brian Candler]

On 05/02/2017 21:22, Adam Spiers wrote:
The first thing to note is that if the mechanism for calculating 
obfuscated filenames is a simple hash such as SHA-256, then in order 
to implement

   pass show google.com
we simply perform SHA-256 on "google.com", and then look for a file 
called
~/.password-store/d4c9d9027326271a89ce51fcaf328ed673f17be33469ff979e8ab8dd501e664f 

The trouble with this discussion is that no threat model has been 
proposed, so we can just argue round in circles.


You said you are worried about certain types of attack (e.g. an 
untrusted sysadmin on the same machine, who is able to read system 
memory) - IMO such an attack is meaningless to try to defend against. If 
the attacker has root on the system you're using, you are toast whatever 
you try to do.  There are a million ways they can intercept what you're 
doing.


I gather than you don't want people to learn which websites you have 
visited. Well, if they have root on your system they will learn this 
anyway. So if that's not it, perhaps the threat is from people who don't 
have access to your machine, but do have access to the git repo?


If they have access to the repo, even if the filenames are encrypted or 
salted and hashed, they'll be able to infer useful things from the 
number of subdirectories, the number of files in each subdirectory, and 
the commit history in each subdirectory.


(You could keep everything in one flat directory, but then you lose the 
ability to encrypted to different sets of keys, with a different .gpgid 
file in each subdirectory)


So if your paranoia level is high, then as others have said, it may make 
more sense to encrypt the whole directory tree rather than each file 
individually.


I like pass because it's simple, it's open, it does the job I care 
about, and its security model is abundantly clear. I worry that adding 
obfuscation will make it not really any more secure, but less practical 
to use.


Regards,

Brian.
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

Re: encrypted file and directory names?

[Sebastian Reuße]

Adam Spiers  writes:

> I got the impression that the point of pass was to provide an
> additional line of defence above what the filesystem already provides.
> If the filesystem can be trusted to keep things secure then you could
> simply store all your credentials in it in plaintext, and there would
> be no need for pass. Maybe I misunderstood something?

When using an encrypted container, you may very well store your
passwords in plain text and achieve the same level of defense for your
(non-meta) data as offered by pass and its GnuPG backend, at least if
you opt to re-lock the container after use. In this case, any sort of
metadata encryption built into pass would not offer any substantial
advantages.

Best regards,
SR
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

Re: encrypted file and directory names?

[Sebastian Reuße]

Marin Usalj  writes:

> There's still syncing those passwords over the wire and across
> different filesystems. I don't fully trust cloud VPS fs encryption
> either.

In that case you may want to consider the git-remote-gcrypt extension.
This will allow you to encrypt the remote git repository end-to-end
using gpg, so there’s no need to trust the hosting provider.

Regards,
SR
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

Re: encrypted file and directory names?

[Lenz Weber]

Doing any of these and obfuscating filenames would destroy a lot of what
makes pass great.
Pass stores it's passwords in files that can be simply used with pass,
or without pass by just using gpg. Changing filenames to something the
user did not chose destroys this simplicity.
Also, there is no specification of what to put into a pass file (except
the recommendation that the first line should be a password), so storing
file name information in the password files is another no-no, as it
would break with many of us.

Pass is very unixy in that you can combine it with other tools.
Depending on your attack vector, encfs was mentioned, git-remote-gcrypt
was mentioned and a tomb extension has just been suggested.
All those methods work without destroying the pass philosophy.

If you want a "one-tool-to-do-everything" pass might simply not be for you.

Am 05.02.2017 um 22:22 schrieb Adam Spiers:
> On Sun, Feb 05, 2017 at 08:26:18AM +, Brian Candler wrote:
>> On 05/02/2017 03:53, HacKan Iván wrote:
>>> I thought the same, but implementing it is a real pain in the ass.
>>> I'm currently working on something I'll send soon, and then I'm gonna
>>> work on an extension to do just that :) 
>>
>>
>> If this is implemented I'd definitely prefer to see it as an
>> extension, because I like the way pass works today.  My threat model
>> is different to yours :-) 
> 
> I can totally sympathise with that.  An extension would be fine for me.
>> I'd say that the main benefit of putting separate passwords in
>> separate files is that you can have independent changes to the git
>> repository and they are less likely to cause merge conflicts. If you
>> added a single encrypted file at the top of the repository, mapping
>> password name to token, that benefit would be lost. 
> 
> Not really.  Firstly, changes within existing files (e.g. changes to
> passwords) would not require any change to the common encrypted index
> file.  Secondly, whilst you are right that the use of a single encrypted
> index file would mean that additions / deletions of files (including
> renames) could cause merge conflicts, that was just my first naive
> proposal for how to implement this.  I am sure it is possible to come up
> with a smarter design that minimises or even eliminates this merge
> conflict issue; here are some initial suggestions ...
> 
> The first thing to note is that if the mechanism for calculating
> obfuscated filenames is a simple hash such as SHA-256, then in order to
> implement
>pass show google.com
> we simply perform SHA-256 on "google.com", and then look for a file called
>   
> ~/.password-store/d4c9d9027326271a89ce51fcaf328ed673f17be33469ff979e8ab8dd501e664f
> 
> in the store and decrypt that.  In that case, there is no need for any
> index, so there is no risk of merge conflicts.  However, this prevents
> traversal of the unencrypted pass-name (filename) namespace, so it would
> break functionality like:
>pass find google
> But this can be solved easily.  One possibility would be to store each
> pass-name within its corresponding encrypted file.  In fact this is more
> or less already recommended by https://www.passwordstore.org/ anyway,
> where it describes the multi-line strategy:
>For example, Amazon/bookreader might look like this:
>Yw|ZSNH!}z"6{ym9pI
>URL: *.amazon.com/*
>Username: amazonianchic...@example.com
>Secret Question 1: What is your childhood best friend's most bizarre
> superhero fantasy? Oh god, Amazon, it's too awful to say...
>Phone Support PIN #: 84719
> 
> Then running "pass find" would decrypt every file in the store to find
> the one(s) you are looking for.  Of course this would slow it down a
> lot.  But "pass grep" already has the same complexity, so if that's
> tolerable (which it probably is, given that most stores presumably won't
> have more than a few hundred entries at most), then perhaps that's not a
> big deal.
> If this increased complexity was an issue, one solution would be to keep
> the index but minimise the frequency of merge conflicts, by splitting
> the index into buckets hashed by (say) the first character of the
> unencrypted pass-name (filename), or by its length.  Then you'd only get
> a merge conflict when two or more changes affected pass-names with the
> same first character, or of the same length.
> But actually, a better approach would be to keep the index as a single
> encrypted file but simply avoid committing it to git.  Ta-da!  No merge
> conflicts :-)  But, I hear you cry, how would changes to the index file
> in one git working tree get propagated to the index file in another
> (remote) git working tree?  Simple - the index can simply be
> automatically rebuilt each time the store changes.  So effectively it
> would be nothing more than an encrypted cache of the mapping between
> pass-names and digests.  I think this is a much cleaner solution.  It
> could even be automated using git hooks.
> In order to be able to build this index, 

Re: encrypted file and directory names?

[Adam Spiers]

On Sun, Feb 05, 2017 at 10:27:58AM +0100, Sebastian Reuße wrote:

Adam Spiers  writes:

There is one feature which I consider pretty essential, and as far as
I can see, it's not supported by pass yet, which is to keep the entire
metadata encrypted, including the directory names and file names.
Without this it doesn't seem to provide 100% privacy protection, since
for example it potentially exposes which websites you use. Is that
right, or am I missing something?


This is already implemented as far as I see it. In order to protect your
local data, you can store the git repository on a fully-encrypted disk
or alternatively store it inside an encrypted container like ecryptfs.
To protect the data stored on remotes, use the git-remote-gcrypt
extension.


I got the impression that the point of pass was to provide an
additional line of defence above what the filesystem already
provides.  If the filesystem can be trusted to keep things secure then
you could simply store all your credentials in it in plaintext, and
there would be no need for pass.  Maybe I misunderstood something?
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

Re: encrypted file and directory names?

[Adam Spiers]

On Sun, Feb 05, 2017 at 08:26:18AM +, Brian Candler wrote: 
On 05/02/2017 03:53, HacKan Iván wrote: 
I thought the same, but implementing it is a real pain in the ass. 

I'm currently working on something I'll send soon, and then I'm 
gonna work on an extension to do just that :) 



If this is implemented I'd definitely prefer to see it as an 
extension, because I like the way pass works today.  My threat model 
is different to yours :-) 


I can totally sympathise with that.  An extension would be fine for 
me. 

I'd say that the main benefit of putting separate passwords in 
separate files is that you can have independent changes to the git 
repository and they are less likely to cause merge conflicts. 
If you added a single encrypted file at the top of the repository, 
mapping password name to token, that benefit would be lost. 


Not really.  Firstly, changes within existing files (e.g. changes to 
passwords) would not require any change to the common encrypted index 
file.  Secondly, whilst you are right that the use of a single 
encrypted index file would mean that additions / deletions of files 
(including renames) could cause merge conflicts, that was just my 
first naive proposal for how to implement this.  I am sure it is 
possible to come up with a smarter design that minimises or even 
eliminates this merge conflict issue; here are some initial 
suggestions ...


The first thing to note is that if the mechanism for calculating 
obfuscated filenames is a simple hash such as SHA-256, then in order 
to implement 

   pass show google.com 

we simply perform SHA-256 on "google.com", and then look for a file 
called 

   ~/.password-store/d4c9d9027326271a89ce51fcaf328ed673f17be33469ff979e8ab8dd501e664f 

in the store and decrypt that.  In that case, there is no need for any 
index, so there is no risk of merge conflicts.  However, this prevents 
traversal of the unencrypted pass-name (filename) namespace, so it 
would break functionality like: 

   pass find google 

But this can be solved easily.  One possibility would be to store each 
pass-name within its corresponding encrypted file.  In fact this is 
more or less already recommended by https://www.passwordstore.org/ 
anyway, where it describes the multi-line strategy: 

   For example, Amazon/bookreader might look like this: 


   Yw|ZSNH!}z"6{ym9pI
   URL: *.amazon.com/*
   Username: amazonianchic...@example.com
   Secret Question 1: What is your childhood best friend's most bizarre 
superhero fantasy? Oh god, Amazon, it's too awful to say...
   Phone Support PIN #: 84719

Then running "pass find" would decrypt every file in the store to find 
the one(s) you are looking for.  Of course this would slow it down a 
lot.  But "pass grep" already has the same complexity, so if that's 
tolerable (which it probably is, given that most stores presumably 
won't have more than a few hundred entries at most), then perhaps 
that's not a big deal. 

If this increased complexity was an issue, one solution would be to 
keep the index but minimise the frequency of merge conflicts, by 
splitting the index into buckets hashed by (say) the first character 
of the unencrypted pass-name (filename), or by its length.  Then you'd 
only get a merge conflict when two or more changes affected pass-names 
with the same first character, or of the same length. 

But actually, a better approach would be to keep the index as a single 
encrypted file but simply avoid committing it to git.  Ta-da!  No merge 
conflicts :-)  But, I hear you cry, how would changes to the index file 
in one git working tree get propagated to the index file in another 
(remote) git working tree?  Simple - the index can simply be 
automatically rebuilt each time the store changes.  So effectively it 
would be nothing more than an encrypted cache of the mapping between 
pass-names and digests.  I think this is a much cleaner solution.  It 
could even be automated using git hooks. 

In order to be able to build this index, we'd need to store each 
pass-name within the encrypted file, similar to the suggestion in the 
multi-line approach above, either by reducing the URL to a canonical 
form like "amazon.com" and computing the digest of that, or by relying 
on the presence of a separate, manually entered "Name" field, e.g. 


   Yw|ZSNH!}z"6{ym9pI
   Name: amazon.com
   URL: *.amazon.com/*
   Username: amazonianchic...@example.com
   Secret Question 1: What is your childhood best friend's most bizarre 
superhero fantasy? Oh god, Amazon, it's too awful to say...
   Phone Support PIN #: 84719

Some policy would have to be decided in advance for how this canonical 
form is calculated.  It would probably be best to use the "Name" field 
if present, and otherwise fall back to massaging the URL pattern into 
canonical form. 

Finally, I should note that there is another problem with using a 
straight digest algorithm like SHA-256: it's vulnerable to dictionary 
attacks and rainbow tables.  For example 

Re: encrypted file and directory names?

[Sebastian Reuße]

Adam Spiers  writes:

> There is one feature which I consider pretty essential, and as far as
> I can see, it's not supported by pass yet, which is to keep the entire
> metadata encrypted, including the directory names and file names.
> Without this it doesn't seem to provide 100% privacy protection, since
> for example it potentially exposes which websites you use. Is that
> right, or am I missing something?

This is already implemented as far as I see it. In order to protect your
local data, you can store the git repository on a fully-encrypted disk
or alternatively store it inside an encrypted container like ecryptfs.
To protect the data stored on remotes, use the git-remote-gcrypt
extension.

Kind regards,
SR
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

Re: encrypted file and directory names?

[Brian Candler]

On 05/02/2017 03:53, HacKan Iván wrote:

I thought the same, but implementing it is a real pain in the ass.

I'm currently working on something I'll send soon, and then I'm gonna 
work on an extension to do just that :)



If this is implemented I'd definitely prefer to see it as an extension, 
because I like the way pass works today.  My threat model is different 
to yours :-)


I'd say that the main benefit of putting separate passwords in separate 
files is that you can have independent changes to the git repository and 
they are less likely to cause merge conflicts.


If you added a single encrypted file at the top of the repository, 
mapping password name to token, that benefit would be lost. In fact, you 
might as well just keep all your passwords in a single file (instead of 
name -> token it would contain name -> password)


Regards,

Brian.

___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

Re: encrypted file and directory names?

[HacKan Iván]

I thought the same, but implementing it is a real pain in the ass.

I'm currently working on something I'll send soon, and then I'm gonna work on 
an extension to do just that :)

Cheers!

On February 4, 2017 2:50:46 PM GMT-03:00, Adam Spiers  
wrote:
>Hi all,
>
>I was delighted to discover this project recently.  It seems to be
>almost exactly the perfect solution needed to avoid the unpleasant
>situation of being reliant on a proprietary password manager.
>
>There is one feature which I consider pretty essential, and as far as
>I can see, it's not supported by pass yet, which is to keep the entire
>metadata encrypted, including the directory names and file names.
>Without this it doesn't seem to provide 100% privacy protection, since
>for example it potentially exposes which websites you use.  Is that
>right, or am I missing something?
>
>If I'm right, would this be an easy thing to solve architecturally?
>For example, the directory names and file names could be converted
>into some kind of digest (e.g. SHA-256), and then a mapping between
>digests and the original names could be tracked in a separate
>encrypted file at the top level of the store.
>
>Thanks!
>Adam
>___
>Password-Store mailing list
>Password-Store@lists.zx2c4.com
>https://lists.zx2c4.com/mailman/listinfo/password-store

-- 
HacKan || Iván
GPG: 0x35710D312FDE468B___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

encrypted file and directory names?

[Adam Spiers]

Hi all,

I was delighted to discover this project recently.  It seems to be
almost exactly the perfect solution needed to avoid the unpleasant
situation of being reliant on a proprietary password manager.

There is one feature which I consider pretty essential, and as far as
I can see, it's not supported by pass yet, which is to keep the entire
metadata encrypted, including the directory names and file names.
Without this it doesn't seem to provide 100% privacy protection, since
for example it potentially exposes which websites you use.  Is that
right, or am I missing something?

If I'm right, would this be an easy thing to solve architecturally?
For example, the directory names and file names could be converted
into some kind of digest (e.g. SHA-256), and then a mapping between
digests and the original names could be tracked in a separate
encrypted file at the top level of the store.

Thanks!
Adam
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store