[ 
https://issues.apache.org/jira/browse/CASSANDRA-14678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16597353#comment-16597353
 ] 

Stefan Podkowinski commented on CASSANDRA-14678:
------------------------------------------------

BCrypt is used for making hashing operations computation expensive by design. 
The trade-off is brute force safety vs authentication performance. You can't 
have both: make password checks inexpensive and fast will also increase chances 
to have password cracked by brute force attacks. Users who won't be able to use 
long living sessions and thus need to authenticate very frequently may decide 
to lower the number of rounds using the  
{{cassandra.auth_bcrypt_gensalt_log2_rounds}} system property, but also change 
passwords on regular basis.

> 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to