Ismael, 1. Jun had suggested added the full list of SHA-nnn in the [DISCUSS] thread. I am ok with limiting to a smaller number if required.
3. Added a section on security considerations to the KIP. Thank you, Rajini On Thu, Dec 1, 2016 at 4:22 PM, Ismael Juma <ism...@juma.me.uk> wrote: > 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 > -- Regards, Rajini
