Hello Reindl,
Please see my follow-up below. I find dbmail has great potential.
On 27/06/18 22:22, Reindl Harald wrote:
Am 27.06.2018 um 20:46 schrieb Mauro Mozzarelli:
That is correct. I was looking to secure DB access by encrypting the
credentials in the configuration file.
how do you imagine that to start with?
dbmail needs to authenticate against the database and so it needs the
credentials - frankly - even if you would be able to enter encrypted
passwords in "dbmail.conf" the dbmail processes would need the
password/key to decrypt it and so you just move it from A to B
Correct. Dbmail should include a tool to encrypt the password (the tool
provides encryption only), to then save it into the configuration file
in encrypted form. If you are familiar with JEE Application servers like
JBoss or Websphere, for example, this is the basic security offered.
More advanced security involves a third party key store.
Going for the basic, the tool encrypts the password using a 2 way
encryption and then the dbmail server reads the encrypted password and
decrypts it using the reverse process.
Why should we encrypt the password? This is not only for protections
from malicious access, but so that the dbmail "administrator" role is
not provided un-necessarily with database credentials that would allow
the administrator to gain access to confidential emails. This way a
small/medium/large company can achieve customers' confidential
information protection through separation of concerns. It is a necessary
step to grade a product as adoptable by commercial organizations.
Technically the encryption algorithm and seed/keys are stored inside the
dbmail software package and obfuscated.
The password encryption tool typically would not necessarily be deployed
on the server running dbmail.
I know about setting permissions, but that is quite a lightweight and
ineffective measure.
Unix sockets implies a single tier hardware deployment. That as well
does not suit the multi-tiered, firewall protected deployment to protect
the Database tier. Clearly if I protect the DB tier, and then write the
password in clear in the configuration file of the tier directly exposed
to users, then the security of the DB is also reduced.
This is a security issue.
it is not - dbmail starts as root, reads the config and drops
privileges, if someone can read "/etc/dbmail.conf" which can only be
accessed by root you have lost anyways
Please see above. This isn't only to protect from malicious access, but
also to protect customers' and users' privacy in business organizations,
and thus to protect the brand from the damage caused by confidential
information leaks.
You need to think like a business.
On 27/06/18 07:23, Thomas Raschbacher wrote:
I think Mauro meant if it is possible to have the Database credentials
themselves encrypted in dbmail.conf. - To answer that: I don't think
that is possible, but if you configure permissions properly (0600 or
maybe 0660 then noone but the dbmail user and root should have access
to it) - or depending on which Database you use you could look into
using unix sockets instead of tcp/ip
Regards
On 2018-06-25 08:24, Andrea Brancatelli wrote:
Password encryption is mostly transparent on the application side,
you just have to choose an encryption method when you create an user
with dbmail-users - the password will be encrypted on the db and
DBMail will handle it transparently
_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://lists.nfg.nl/mailman/listinfo/dbmail
_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://lists.nfg.nl/mailman/listinfo/dbmail
