[
https://issues.apache.org/jira/browse/SOLR-16077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502240#comment-17502240
]
Eric Pugh commented on SOLR-16077:
----------------------------------
Security in Solr has been slowly evolving... It's only in the most recent 8.x
versions of Solr that there is an Admin screen for managing security! For a
very long time I found it incredibly opaque.... I would not be surprised
however if in the not too distant future, Solr comes with a "default user"
account that you have to set up ;-), and that security is enabled by default
and something you have to disable...
My general approach is to deploy a solr with no configs, and just a simple
security.json just to enable the security admin gui, and make Solr security
possible. Then, as a seperate step, using security and accounts, deploy all
the configs, create the collections, load the data.
I'd love to see any patches or changes you make, as I find myself *frequently*
lost in the Security section of the Ref Guide.
> Solr basic authentication is undocumented and a bit strange
> -----------------------------------------------------------
>
> Key: SOLR-16077
> URL: https://issues.apache.org/jira/browse/SOLR-16077
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication
> Reporter: Ben
> Priority: Major
> Labels: documentation, easyfix, security
>
> I'm working with Solr 7 because reasons, but the issue also seems to persist
> in the current code base.
> h2. Documentation
> Here's the Solr 8.1 documentation for the [Basic Authentication
> Plugin|[https://solr.apache.org/guide/8_1/basic-authentication-plugin.html]].
> In the security.json example, we see
> {code:java}
> "credentials":{"solr":"IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0=
> Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="}, {code}
> but the only explanation given for this is "A user called 'solr', with a
> password {{'SolrRocks'}} has been defined."
> What's missing is:
> * Explanation of how to produce such a credential string. In psuedocode,
> this amounts to:
> **
> {code:java}
> encode_base64(sha256(sha256(salt + password))) + " " +
> encode_base64(salt){code}
> * The salt used, in addition to the password used, so that users can test
> that their produced credentials will match Solr's handling.
> I've spent a good bit of searching through articles and watching videos, and
> I couldn't find any that actually explained this until I saw the source code.
> The only explanation I've seen for adding users was to first stand up an
> unauthenticated instance, and then add them via the API, which doesn't
> translate well into automated deployments.
> h2. Code
> Let's get back to that pseudocode.
> {code:java}
> encode_base64(sha256(sha256(salt + password))) + " " +
> encode_base64(salt){code}
> Strangely, we're hashing twice! Here it is in [the
> source|https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/security/Sha256AuthenticationProvider.java#L129].
> In more detail:
> {code:java}
> if (saltKey != null) {
> digest.reset();
> digest.update(Base64.getDecoder().decode(saltKey));
> }
> byte[] btPass = digest.digest(password.getBytes(StandardCharsets.UTF_8));
> digest.reset();
> btPass = digest.digest(btPass);
> return Base64.getEncoder().encodeToString(btPass); {code}
> Some observations:
> * Nit: the salt is base64'd before being passed to the function then
> immediately unbase64'd again, but that's beside the point.
> * The salt is added to the message, then the password, and then digest() is
> called. This produces a SHA256 hash digest.
> * digest() [basically calls
> reset()|https://docs.oracle.com/javase/8/docs/api/java/security/MessageDigest.html],
> so there's no need to call reset()
> * The previous digest is then hashed again! This is surprising. Is there a
> reason?
> h2. Outro
> I'm not too familiar with secure coding practices, especially in Java, so
> perhaps this was to work around some sort of limitation with
> java.secure.MessageDigest when this particular code was produced 7 years ago.
> It certainly seems strange to do this in terms of code quality, but I feel
> like my more immediate issue is that it's incredibly non-obvious to an end
> user just trying to secure a Solr instance.
> Is there a reason it's coded this way? How should end-users learn how to
> configure security.json? If the code is updated to use only a single round of
> SHA256 hashing, how will existing Solr deployments update smoothly?
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
