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 < rajinisiva...@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 SCRAM-SHA-512. 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 passwords). If nothing else, it may be worth mentioning some of this in the KIP and/or documentation. Ismael [1] http://www.isode.com/whitepapers/scram.html
