[Freeipa-devel] [PATCH] Password vault

[Endi Sukma Dewata]

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

> 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.

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.

> 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 
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?

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.

> Thanks,
> Martin

-- 
Endi S. Dewata