[
https://issues.apache.org/jira/browse/SOLR-4392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16218863#comment-16218863
]
Nicholas DiPiazza commented on SOLR-4392:
-----------------------------------------
Gerald is correct. Got confirmation from the openssl mailing list as well:
> 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.
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
