[
https://issues.apache.org/jira/browse/SOLR-4392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16218863#comment-16218863
]
Nicholas DiPiazza edited comment on SOLR-4392 at 10/25/17 3:11 PM:
-------------------------------------------------------------------
Gerald is correct. Got confirmation from the openssl mailing list as well:
{quote}
Use long strong passwords and you will be OK.
This is good because people with access to the XML document can be denied
access to the file containing password2 and therefore cannot decrypt the
database password1 or access the database.
If this is the case then your password2 must be long and complex - it must have
high entropy. If you make it 30 random characters long it will not matter that
openssl enc only uses one iteration. (If you have several databases which Solr
accesses you should write an automated script to create and install a long
random password2 to stop anybody using secret123 as their password2 or
accidentally forgetting to chmod the file.)
Note that you can see the length of password1 in the XML document and you will
therefore need a strong password1 for the database too because it is easier to
guess a password when you know the length.
{quote}
was (Author: ndipiazza_gmail):
Gerald is correct. Got confirmation from the openssl mailing list as well:
{quote}
And this is good because people with access to the XML document can be denied
access to the file containing password2 and therefore cannot decrypt the
database password1 or access the database.
If this is the case then your password2 must be long and complex - it must have
high entropy. If you make it 30 random characters long it will not matter that
openssl enc only uses one iteration. (If you have several databases which Solr
accesses you should write an automated script to create and install a long
random password2 to stop anybody using secret123 as their password2 or
accidentally forgetting to chmod the file.)
Note that you can see the length of password1 in the XML document and you will
therefore need a strong password1 for the database too because it is easier to
guess a password when you know the length.
{quote}
> DIH - Need to externalize or encrypt username/password stored within
> data-config.xml
> ------------------------------------------------------------------------------------
>
> Key: SOLR-4392
> URL: https://issues.apache.org/jira/browse/SOLR-4392
> Project: Solr
> Issue Type: New Feature
> Components: contrib - DataImportHandler
> Affects Versions: 4.0, 4.1
> Reporter: Senthuran Sivananthan
> Assignee: Noble Paul
> Fix For: 5.2, 6.0
>
> Attachments: SOLR-4392.patch, SOLR-4392.patch
>
>
> Today, the connection (database or otherwise) credentials is wide open in
> data-config.xml. Not really an issue until someone sends out the config file
> outside of the server.
> We should look into externalizing the database lookup or providing a way to
> encrypt the username and password.
> The needs are:
> 1/ Some projects want to enable multi-tenancy where data for each core is
> situated in different database servers w/ their own credentials. We need a
> way to expose hooks that will allow implementations to be plugged in. It can
> be done though the "type" attribute on the dataSource, but providing a
> factory might work better.
> 2/ Most orgs are very protective of their credentials and weary of
> plain-text settings.
> {code:xml}
> <dataSource name="jdbc" driver="oracle.jdbc.driver.OracleDriver"
> url="jdbc:oracle:thin:@//hostname:port/SID" user="db_username"
> <!-- This database password is encrypted using AES using the command. pwd.txt
> contains the actual DB password -->
> <!-- openssl enc -aes-128-cbc -a -salt -in pwd.txt -->
> password="U2FsdGVkX18QMjY0yfCqlfBMvAB4d3XkwY96L7gfO2o="
> <!-- Password to decrypt is stored in this file-->
> encryptKeyFile="/location/of/encryptionkey"
> />
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
