[
https://issues.apache.org/jira/browse/CASSANDRA-14678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16597986#comment-16597986
]
Jay Zhuang commented on CASSANDRA-14678:
----------------------------------------
{quote}
The purpose of hashing with bcrypt is to prevent easy decoding of passwords in
case of a database leak, partially. A sleep wouldn't help with that, nor is it
a good idea in general, speaking of DoS.
{quote}
That's true. If the hashed password is leaked, it would be easier to decode.
{quote}
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.
{quote}
One solution is adding timestamp to the salt and the server only check the hash
within {{timestamp +/- [a configurable time]}}.
> 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]
