[Freeipa-devel] [PATCH] Password vault

[Simo Sorce]

On Tue, 2015-06-02 at 07:07 -0500, Endi Sukma Dewata wrote:
> On 6/2/2015 1:10 AM, Martin Kosek wrote:
> > Hi Endi,
> >
> > Quickly skimming through your patches raised couple questions on my side:
> >
> > 1) Will it be possible to also store plain text password via Vault? It
> > talks about taking in the binary data or the text file, but will it also
> > work with plain user secrets (passwords)? I am talking about use like this:
> >
> > # ipa vault-archive <name> --user mkosek --data Secret123
> 
> For security the plain text password should be stored in a file first:
> 
>    # vi password.txt
>    # ipa vault-archive <name> --user mkosek --in password.txt
> 
> It's also possible to specify the password as base-64 encoded data:
> 
>    # echo -n Secret123 | base64
>    # ipa vault-archive <name> --user mkosek --data U2VjcmV0MTIz
> 
> But it's not recommended since the data will be stored in the command 
> history and someone could see and decode it. I think passing a plain 
> text password as command line argument would be even worse. The --data 
> parameter is mainly used for unit testing.
> 
> Later we might be able to add an option to read from standard input:
> 
>    # cat password.txt | ipa vault-archive <name> --user mkosek --std-in

Yes please, a way to pass in via stdin is extremely useful, as leaving
files on the filesystem is also a big risk.

> > 2) Didn't we discuss a dependency of IPA/Vault on python-cryptography in
> > the past? I rather see use of python-nss for cryptography...
> 
> Yes. I might have mentioned that it would be in the 2nd (current) vault 
> patch. Actually it will be in the 3rd patch when we add the symmetric 
> and asymmetric vaults. The symmetric and asymmetric encryption will be 
> implemented using python-cryptography. You can also see this in an old 
> patch (#358) but it's obsolete now.
> 
> The standard vault in the current patch uses python-nss for transport 
> encryption because when the KRA interface was written 
> python-cryptography wasn't available on Fedora, it didn't support 
> certificates, and I'm not sure if it supports key wrapping.

It depends on the key wrapping, I have coded in python (jwcrypto)
support for some key wrapping not yet available in python-cryptography
and can lend you the code as needed.

> The symmetric and asymmetric vaults add an additional layer of 
> encryption on top of the standard transport encryption, so it will 
> depend on both python-nss and python-cryptography.
> 
> In the future if the KRA can support python-cryptography without 
> python-nss we may be able to drop the python-nss dependency from vaults.
> 
> > 3) You do a lot of actions in the forward() method (as planned in
> > https://www.freeipa.org/page/V4/Password_Vault#Archival). But how do you
> > envision that this is consumed by the Web UI? It does not have access to
> > the forward() method. Would it need to also include some crypto library?
> 
> If Web UI wants to access vault (not sure if everybody agrees with 
> that), it would have to perform an encryption on the browser side. In 
> that case we will need to use either WebCrypto or a browser-specific 
> extension to implement something similar to vault_archive.forward(), 
> assuming the required cryptographic functionalities are available. In 
> the future PKI might be able to provide a JavaScript interface for KRA.

I so much want to NACK crypto in web browsers ... but we may have to do
it, it stinks soo much though ... Perhaps a plugin ?

> > 4) In the vault-archive forward method, you use "pki" module. However,
> > this module will be only available on FreeIPA PKI-powered servers and
> > not on FreeIPA clients - so this will not work unless freeipa-client
> > gets a dependency on pki-base - which is definitely not something we
> > want...
> 
> In my opinion it should be fine to require pki-base on the client 

NACK look at the dependency chain for that packages.

> because it contains just the client library, unless you have other 
> concerns? Any objections to having pki-nss and pki-cryptography 
> dependencies on the client?

you mean python-nss/python-cryptography ? I see no problem having them
as dependencies on the client.

> Even if we can change the client code not to depend on "pki" module, 
> since in this framework the client and server code are written in the 
> same plugin, the "import pki" still cannot be removed since it's still 
> needed by the server code, and I don't think conditional import is a 
> good programming practice.

conditional import is just fine

Simo.

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