[Freeipa-devel] Password Vault Implementation

[Simo Sorce]

On Thu, 2014-07-31 at 16:13 -0500, Endi Sukma Dewata wrote:
> On 7/31/2014 1:30 PM, Simo Sorce wrote:
> >>>> http://www.freeipa.org/page/V4/Password_Vault_Implementation
> 
> > I was thinking whether we should use a single attribute for each vault,
> > and format the data within the vault as a json blob, to organize the
> > data within the blob.
> >
> > This would allow us to encrypt everything including names and
> > descriptions of the single secrets. This way we also do not need to
> > verify the password, as there is a single encrypted blob and not
> > multiple ones.
> 
> > I am more concerned about an admin just seeing the secrets descriptions,
> > or someone finding a backup etc...
> > I was considering the vault as a unit to which either you have or not
> > access based on encryption, not on access control done in LDAP. See
> > above my proposal also that goes in this direction.
> 
> The "compartment" concept was actually proposed by Dmitri to help manage 
> the secrets. I translated that into "vault" since a vault is essentially 
> a compartment.
> 
> We can certainly change the design to use separate password for each 
> secret. But suppose you have many secrets, you will be responsible to 
> remember the password for each secret. Would that be a reasonable 
> requirement for people in general? Encrypting the secret metadata is a 
> separate issue, we can do that either way. See comments below.
> 
> Vault as a compartment will help reduce that burden by using the same 
> password for multiple secrets. It also can help if you're sharing 
> multiple secrets with the same group of people. You can also create 
> separate vaults for each secret if necessary, or the server can be 
> configured to limit the number of secrets in each vault.

I think you misunderstood what I was proposing.
I was proposing the vault is the unit of encryption, as a single blob of
data. But the vault would still contain multiple secrets, simply
formatted into a json object.

Something like:

plaintext:
    {
        { id: "email",
          data: "Passw0rd",
          description: "my email password"
        },
        { id: "redhat.com",
          data: "Secret5",
          description: "redhat.com website password"
        },
      ...
    }


> >> Or we can make the access control more granular. Only owners can see the
> >> list of secrets.
> >
> > I am not sure listing the secrets within the vault w/o decrypting the
> > vault is necessarily valuable.
> 
> Any concern about the crypto operations being computationally expensive, 
> or retrieving the whole blob just to see the metadata would waste bandwidth?

How big do you think the vault would be ?
It is not meant to contain anything more than a bunch of passwords, do
we really have a problem if the blob is a few tens of kilobytes ?

> Even if we encrypt individual secrets with the metadata, the secret name 
> itself will still be visible to the admin, and it might give out clues 
> as to what is in the secret. You can use cryptic names for the secrets, 
> but you'll have to maintain it on your own.

Only if you have separate objects per secret which is what I was arguing
against.

> Let's see if the analogy with safe deposit box in a bank makes sense:
> 
> 1. Use one box (vault) to store multiple items (secrets). You will have 
> one key (vault password) and you will need it to see what's inside.

This is what I am proposing indeed.

> 2. Like #1, but the bank keeps a list of items (metadata) in the box and 
> only share it with authorized people (vault members). You can identify 
> yourself as a member with an ID (Kerberos principal), but you still need 
> a key (vault password) to get the items.

I do not like this much :)

> 3. Use a separate box to store each item (separate password for each 
> secret). You will have to manually keep track which key for which box/item.

This is really bad, not advocating at all.

> >>> * Why services are in the /shared/ namespace ?
> >>
> >> Services don't seem to be something that you want to associate with a
> >> specific user.
> >
> > Not with a user, with a service.
> > /services/openvpn at foo.example.com/
> 
> We probably can add new commands (or repurpose the commands) to manage 
> the namespace. So initially there will be /users and /shared, but you 
> can add others such as /services.
> 
> >>   So in that case it's put under the /shared namespace.
> >> Even so, the vault membership can still be limited to certain
> >> users/service instances. Being in /shared doesn't mean it's open for public.
> >
> > Understood, but if you have the same "service" on multiple machines then
> > it quickly becomes difficult to sort it out, I would prefer a logic
> > similar that of the user, just with fully qualified service names under
> > a /services/ namespace
> 
> The vault namespace is hierarchical, so you can organize it in any way 
> you want:
> * /services/<service name>@<server name>
> * /shared/services/<server name>/<service name>
> 
> In the current wiki page the service admin can pick the vault name 
> (/shared/services is just an example), but the secret names in it are 
> generated from the service principal (to make sure the service admin and 
> the service instance use the same secret name).

Given service passwords is an actual use case I think /services should
be a top level namespace available by default.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York