Thanks Jason for sharing the details.
Regards, Vinodh -----Original Message----- From: Jason Gerlowski <gerlowsk...@gmail.com> Sent: Friday, November 15, 2019 12:54 AM To: solr-user@lucene.apache.org Subject: Re: Anyway to encrypt admin user plain text password in Solr ATTENTION! This email originated outside of DTCC; exercise caution. 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 > https://nam02.safelinks.protection.outlook.com/?url=www.ulib.iupui.edu > &data=02%7C01%7Cvkommu%40dtcc.com%7C9dab071571614ae9dff508d7693853 > f6%7C0465519d7f554d47998b55e2a86f04a8%7C0%7C0%7C637093562958117939& > ;sdata=Q0881FOYJhLgLOPOiUUqSpY6UbbIw82vUmVlaSAx0AU%3D&reserved=0 DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
