[
https://issues.apache.org/jira/browse/CASSANDRA-14678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16597911#comment-16597911
]
Aleksey Yeschenko commented on CASSANDRA-14678:
-----------------------------------------------
bq. I think "preventing crackers from brute-forcing by slowing down" should be
done on client side at the expense of cracker's computing resource, not the
service/server's (just like Jay said, protected from potential DDoS attack).
Also, salted hash should be computed at client side and sent to server, to
avoid plaintext being sent over non-secure network.
That's fair, although in this case you'd still be sending the plaintext hash
over unsecure network, which will be sufficient for anyone else to log in by
intercepting just that.
> Propose reducing the default value for PasswordAuthenticator number of
> hashing rounds
> -------------------------------------------------------------------------------------
>
> Key: CASSANDRA-14678
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14678
> Project: Cassandra
> Issue Type: Wish
> Components: Auth
> Reporter: Shichao An
> Priority: Major
>
> We saw performance degradation in some of our Cassandra clusters using
> PasswordAuthenticator. When the clients start connecting to the Cassandra
> nodes, the CPU load increases, and there is a high chance that the host will
> be unable to recover from high CPU usage if the clients retry indefinitely at
> relatively high frequency. In each reconnection, the clients try to initiate
> auth handshakes, but may fail due to timeouts from the overloaded host,
> whereas the sporadic auth handshakes will put more load to the host, so on so
> forth. In our case, the load average can be 1000~3000 on a 32-core host. The
> host is basically unable to serve any traffic.
> We found it is caused by the slow `BCrypt.checkpw` operation, where the
> generated salted hash round is 10 because `GENSALT_LOG2_ROUNDS_PROPERTY`
> defaults 10, which makes it 2^10 rounds of hashing iterations. I changed the
> hashing rounds to 4 by overriding `auth_bcrypt_gensalt_log2_rounds` system
> property and it can effectively solve above-mentioned the CPU issue.
> It took us some time to nail down the cause of this problem. Shall we reduce
> the default value of `GENSALT_LOG2_ROUNDS_PROPERTY` to a smaller value than
> 10? Any suggestions on the tradeoff between performance and cryptographic
> impact?
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
