On 20/02/14 14:47, Radomir Dopieralski wrote: > On 20/02/14 14:10, Jiří Stránský wrote: >> On 20.2.2014 12:18, Radomir Dopieralski wrote: > >>> Thinking about it some more, all the uses of the passwords come as a >>> result of an action initiated by the user either by tuskar-ui, or by >>> the tuskar command-line client. So maybe we could put the key in their >>> configuration and send it with the request to (re)deploy. Tuskar-API >>> would still need to keep it for the duration of deployment (to register >>> the services at the end), but that's it. >> >> This would be possible, but it would damage the user experience quite a >> bit. Afaik other deployment tools solve password storage the same way we >> do now. > > I don't think it would damage the user experience so much. All you need > is an additional configuration option in Tuskar-UI and Tuskar-client, > the encryption key. > > That key would be used to encrypt the passwords when they are first sent > to Tuskar-API, and also added to the (re)deployment calls.
Are we even sure we need to store the passwords in the first place? All this encryption talk seems very premature to me. > > This way, if the database leaks due to a security hole in MySQL or bad > engineering practices administering the database, the passwords are > still inaccessible. To get them, the attacker would need to get > *both* the database and the config files from host on which Tuskar-UI runs. > > With the tuskar-client it's a little bit more obnoxious, because you > would need to configure it on every host from which you want to use it, > but you already need to do some configuration to point it at the > tuskar-api and authenticate it, so it's not so bad. > > I agree that this complicates the whole process a little, and adds > another potential failure point though. > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev