[SAC] password store

Committees SAC mailing list
1

Hi all, I've been thinking about replacing our manually crafted
solution for sharing osgeo secrets with a standard tool based
on GPG: https://www.passwordstore.org

The "passwordstore" tool comes as a unix commandline (pass)
distributed pretty much on all standard free u*x systems.

The idea is to replace the "access" directory we currently
have on the "secure" host with a "password store" directory.
The change would be that the files would be stored encrypted
rather than in plain-text, and so all SAC members would need
to provide a GPG key to use for such encryption.

Internally, the encryption will be done using a symmetric key
and the symmetric key itself will be encrypted multiple times
with the key of each SAC member. I've tested this with Jurgen
and it seems to work pretty smoothly.

Such "password store" could then be distributed in a git
repository, which I've started here:

    https://git.osgeo.org/gitea/sac/password-store

The repository is also "private" so you need to be a SAC member
to access it. If you like the idea, please provide your GPG
public key, maybe filing an issue on the above repository,
and start experimenting with it.

Thanks

--strk;

2

The "passwordstore" tool comes as a unix commandline (pass) distributed
pretty much on all standard free u*x systems.

The idea is to replace the "access" directory we currently have on the
"secure" host with a "password store" directory.
The change would be that the files would be stored encrypted rather than

in

plain-text, and so all SAC members would need to provide a GPG key to use
for such encryption.

Internally, the encryption will be done using a symmetric key and the
symmetric key itself will be encrypted multiple times with the key of each
SAC member. I've tested this with Jurgen and it seems to work pretty
smoothly.

Such "password store" could then be distributed in a git repository, which
I've started here:

    https://git.osgeo.org/gitea/sac/password-store

The repository is also "private" so you need to be a SAC member to access

it.

If you like the idea, please provide your GPG public key, maybe filing an

issue

on the above repository, and start experimenting with it.

Thanks

--strk;

[Regina Obe]

I like the idea. Just a couple of questions/ concerns.

1) The access folder contains more than just passwords, it also contains
things like urls and such where one would log into to use those passwords
Would the idea be we'd always have these in wiki.

I like that information being close to the passwords though as it's easier
to reconcile.
I read the convention is to store these kind of things in a hierarchy, but
given that the hierarchy can't easily handle cases such as a password used
in multiple locations, I think a file detailing locations where this is used
is still needed.

2) The GPG setup. So just thinking thru the management of this.

SAC person comes -- we add their GPG

SAC person leaves - we remove their GPG?

Is that how it works or am I missing something.

Thanks,
Regina

3

On Wed, Mar 16, 2022 at 02:45:58PM -0400, Regina Obe wrote:

>
> https://git.osgeo.org/gitea/sac/password-store

I like the idea. Just a couple of questions/ concerns.

1) The access folder contains more than just passwords, it also contains
things like urls and such where one would log into to use those passwords
Would the idea be we'd always have these in wiki.

The pass tool supports this, see the "Data Organization" section
on https://www.passwordstore.org/ - we can put it in the same file
with the password

2) The GPG setup. So just thinking thru the management of this.

SAC person comes -- we add their GPG
SAC person leaves - we remove their GPG?

Is that how it works or am I missing something.

More or less, yes..

Of course upon "SAC person leaves" all the existing passwords
will need to be considered "leaked" (to the leaving person)
so eventually need to be recreated.

On a technical detail, when we remove their GPG I believe we
also need to "rekey" (re-encrypt) the all the files, although
it's kind of a moot point until the passwords are changed.

--strk;

4

The pass tool supports this, see the "Data Organization" section on
https://www.passwordstore.org/ - we can put it in the same file with the
password

> 2) The GPG setup. So just thinking thru the management of this.
>
> SAC person comes -- we add their GPG
> SAC person leaves - we remove their GPG?
>
> Is that how it works or am I missing something.

More or less, yes..

Of course upon "SAC person leaves" all the existing passwords will need to
be considered "leaked" (to the leaving person) so eventually need to be
recreated.

On a technical detail, when we remove their GPG I believe we also need to
"rekey" (re-encrypt) the all the files, although it's kind of a moot point

until

the passwords are changed.

--strk;

[Regina Obe]

I guess it would be more common for gpg keys to change.

1) So in the case say - hey a gpg expires and is not renewed, what happens?
Do we need to do anything
2) In case where someone for whatever reason decides they want to use a new
gpg key
In that case we just remove right, we don't need to reset all the passwords,
just re-encrypt the files?

5

On Wed, Mar 16, 2022 at 04:03:47PM -0400, Regina Obe wrote:

I guess it would be more common for gpg keys to change.

1) So in the case say - hey a gpg expires and is not renewed, what happens?
Do we need to do anything

GPG keys will only be used by whoever is going to either "rekey" the
whole password store or create new entries, I think (should be tested,
and if you send me your GPG key we can start testing it).

2) In case where someone for whatever reason decides they want to use a new
gpg key
In that case we just remove right, we don't need to reset all the passwords,
just re-encrypt the files?

Just re-encrypt the file after importing the new key I guess.

--strk;