kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ismael Juma <ism...@juma.me.uk>
Subject Re: [VOTE] KIP-84: Support SASL SCRAM mechanisms
Date Thu, 01 Dec 2016 16:22:40 GMT
Hi Rajini,

Sorry for the delay. For some reason, both of your replies (for this and
KIP-85) were marked as spam by Gmail. Comments inline.

On Mon, Nov 28, 2016 at 3:47 PM, Rajini Sivaram <
rajinisivaram@googlemail.com> wrote:
> 1. I think you had asked earlier for SCRAM-SHA-1 to be removed since it is
> not secure :-) I am happy to add that back in so that clients which don't
> have access to a more secure algorithm can use it. But it would be a shame
> to prevent users who only need Java clients from using more secure
> mechanisms. Since SHA-1 is not secure, you need a secure Zookeeper
> installation (or store your credentials in an alternative secure store)..
> By supporting multiple algorithms, we are giving the choice to users. It
> doesn't add much additional code, just the additional tests (one
> integration test per mechanism). As more clients support new mechanisms,
> users can enable these without any changes to Kafka.

Yes, I remember that I asked for SCRAM-SHA-1 to be removed. I probably
wasn't clear. My suggestion was not to add that back, but whether we needed
so many variants. For example, we could support SCRAM-SHA-256 and
Would that be sufficient? It's true that the cost is not that large for us,
but every other client also has to pay that additional extra cost and I am
not sure sure about the benefit of some of the options.

3. I am assuming that ZK authentication will be enabled and ZK
> configuration will be done directly using ZK commands. This is true for
> ACLs, quotas etc. as well?

Right, I also thought that ACLs was the closest example. However, it seems
like getting read access to the SCRAM DB has potentially worse consequences:

"For a specific secret compromised, if an exchange is obtained from the
wire by some mechanism, this gives sufficient information for an imposter
to pose as the client for that server (but not another one using the same
password). Note that this interception is only useful if the database has
been compromised – SCRAM is safe against replay attack. This is the primary
SCRAM weakness, and why it is important to protect the secret database
carefully and to use TLS."[1]

Also, because we are using fast hashes (instead of slow ones like bcrypt,
scrypt, etc.), we are more susceptible to dictionary attacks (potentially
mitigated by a reasonably large iteration count combined with good quality

If nothing else, it may be worth mentioning some of this in the KIP and/or


[1] http://www.isode.com/whitepapers/scram.html

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message