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
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 Sorce * Red Hat, Inc * New York
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code