Hi Vinodh, I don't know of any way to encrypt the credentials in "basicAuth.conf", and looking at the code that loads that file I don't see any logic to handle that sort of thing. So I'm near positive there's no way to avoid plaintext here.
But, that said, I don't think this should really be that concerning. To read this file, an adversary would need (1) access to the machine Solr runs on and (2) access to the user/group running Solr. If an adversary has those two things, the credentials are besides the point. They could kill your Solr process directly. Or read the index data files directly. Or edit them. etc. There may be edge cases around using network drives or HDFS where encrypting this file is useful, I haven't thought that side of things through entirely. But for most use-cases I'm not sure encrypting basicAuth.conf provides anything beyond security theater. Best, Jason On Thu, Nov 14, 2019 at 9:49 AM Mark H. Wood <mw...@iupui.edu> wrote: > > On Thu, Nov 14, 2019 at 11:35:47AM +0000, Kommu, Vinodh K. wrote: > > We store the plain text password in basicAuth.conf file. This is a normal > > file & we are securing it only with 600 file permissions so that others > > cannot read it. We also run various solr APIs in our custom script for > > various purposes using curl commands which needs admin user credentials to > > perform operations. If admin credentials details from basicAuth.conf file > > or from curl commands are exposed/compromised, eventually any person within > > the organization who knows credentials can login to admin UI and perform > > any read/write operations. This is a concern and auditing issue as well. > > If the password is encrypted, then the decryption key must be supplied > before the password can be used. This leads to one of two unfortunate > situations: > > o The user must enter the decryption key every time. This defeats > the purpose of storing credentials at the client. > > - or - > > o The decryption key is stored at the client, making it a new secret > that must be protected (by encrypting it? you see where this is > going....) > > There is no way around this. If the client system stores a full set > of credentials, then anyone with sufficient access to the client > system can get everything he needs to authenticate an identity, no > matter what you do. If the client system does not store a full set of > credentials, then the user must supply at least some of them whenever > they are needed. The best one can usually do is to reduce the > frequency at which some credential must be entered manually. > > Solr supplies several authentication mechanisms besides BasicAuth. > Would one of those serve? > > -- > Mark H. Wood > Lead Technology Analyst > > University Library > Indiana University - Purdue University Indianapolis > 755 W. Michigan Street > Indianapolis, IN 46202 > 317-274-0749 > www.ulib.iupui.edu
