[Engine-devel] Dropping encryption of database password
Hello, Currently we store database password encrypted using org.picketbox.datasource.security.SecureIdentityLoginModule. This is reverse encryption with common knowledge shared secret. Using encryption with common knowledge shared secret is close to void protection. So far we also stored the password as plain text at /etc/ovirt-engine/.pgpass, this is going to be removed as no component actually uses the .pgpass, however we do need to store non-java specific password in for utilities. In master (aiming to 3.3), we store the database connection details in own file /etc/ovirt-engine/engine.conf.d/50-setup-database.conf owned by ovirt user and not world readable. I would like to use the same 50-setup-database.conf to store plain text password and remove the java specific reversible encrypted password usage. Bottom line... 1. We drop the .pgpass file. 2. We store database connection information in /etc/ovirt-engine/engine.conf.d/<file> that is readable only by ovirt usage. 3. We drop the java specific reversible encryption in favor of plain text. Thoughts? Alon
Why not do use the same technology like JBoss DataSource password encryption? http://docs.jboss.org/jbosssecurity/docs/6.0/security_guide/html/Encrypting_... On Wed, May 1, 2013 at 3:45 AM, Eli Mesika <emesika@redhat.com> wrote:
----- Original Message -----
As I wrote: 1. Out project is not java specific, we need to access the database in other tools as well, example: python. 2. Reversible encryption is a total void, what benefit is there to encrypt password which can be decrypted by anyone? 3. We currently store the same password at two files, one which is .pgpass as plain text and another is at the service configuration which is encrypted, what is the benefit in this duplication? Thanks! Alon
In another words you are for storing password as plain text.... :)
If the file is protected , I don't mind that the password is in plain text...
Hi all, Itamar pointed me at this thread. I'm part of the Red Hat Product Security Team, we exist to help various projects and products with security needs (such as advice in this instance). I can't really comment on this without understanding some of the background (sorry for not being up to speed, I don't have time to research this today and I'm away tomorrow so my replies may be slow). Can you explain to me what the passwords in question are used for? Thanks. -- Josh Bressers / Red Hat Product Security Team
Ahh, so the subject is quite literal. So in an instance like this it's not uncommon to store this password as plaintext in a file. The important part is then to ensure that the file is protected and can only be accessed on a need-to-know basis. Using various scrambling techniques don't really provide any additional security. Some claim it makes things worse as it provides a false sense of security. I would suggest you make a note about what processes and users can view or modify this file and for what reasons. This should help identify things in the future that should or shouldn't have this level of access. Let me know if you have any questions. Thanks. -- Josh Bressers / Red Hat Product Security Team
----- Original Message -----
We are using the original .pgpass file that is in 0600 mode ( have access only to root) If the file does not have this mode , it is ignored by Postgres I see no security issue in that ... Please see details in http://www.postgresql.org/docs/9.0/static/libpq-pgpass.html
----- Original Message -----
I am going to drop the .pgpass file in favor of other configuration file and produce .pgpass on will. This is because: 1. The proprietary format of .pgpass is not friendly to parsing. 2. It does not hold the SSL setting. 3. It does not hold the SSL host validation setting. 4. It will be more difficult to modify user password. This file is also 0600 owned by engine but in key=value format, so no change as far as security is concerned. Thanks! Alon.
On Tue, Apr 30, 2013 at 03:41:20PM -0400, Alon Bar-Lev wrote:
+1. Obfuscating passwords only gives a false sense of security. However, many applications, such Firefox in its signons.sqlite, do that to avoid revealing the password during a casual browse of the filesystem.
participants (6)
-
Alon Bar-Lev -
Dan Kenigsberg -
Eli Mesika -
Josh Bressers -
Keith Robertson -
Liran Zelkha