Rainbow Table Attack in Cassandra
How Rainbow Table Attack Manifests in Cassandra
Cassandra is often used as a durable store for application data, including user credentials. When developers store passwords using a fast, unsalted hash (e.g., MD5 or SHA‑1) directly in a Cassandra table, they create the conditions for a rainbow table attack. An attacker who gains read access to the users table (through a misconfigured API, an exposed CQL endpoint, or a compromised backup) can copy the hash column and run it through pre‑computed rainbow tables to recover the original passwords.
Typical vulnerable code path looks like this in a login service:
// Pseudocode showing the vulnerable flow
String email = request.getParameter("email");
String password = request.getParameter("password");
ResultSet rs = session.execute(
"SELECT password_hash FROM users WHERE email = ?", email);
Row row = rs.one();
if (row != null) {
String storedHash = row.getString("password_hash");
// Unsalted MD5 – vulnerable to rainbow tables
String inputHash = DigestUtils.md5Hex(password);
if (MessageDigest.isEqual(storedHash.getBytes(), inputHash.getBytes())) {
// grant access
}
}
Because the hash is deterministic and lacks a per‑user salt, identical passwords produce identical hash values across all rows. An attacker can build a single rainbow table for the hash algorithm and reuse it against every user in the table, dramatically reducing the effort required to crack passwords compared to brute‑forcing each hash individually.
This pattern maps to OWASP API Security Top 10 2023: API2:2023 Broken Authentication (weak credential storage) and to the broader OWASP Top 10 2021 category A02:2021 Cryptographic Failures. Real‑world incidents such as the 2019 exposure of MongoDB backups containing unsalted password hashes (CVE‑2019‑10160) illustrate the impact when storage layers are not properly hardened.
Cassandra-Specific Detection
Detecting unsalted or weak password hashes in Cassandra starts with inspecting the schema and the data stored in credential tables. Look for columns named password, passwd, pw_hash or similar that contain short, fixed‑length strings (e.g., 32 hex characters for MD5, 40 for SHA‑1). The absence of a separate salt column or of algorithm identifiers (e.g., $2a$ for bcrypt) is a strong indicator.
From an API perspective, middleBrick can help by scanning the unauthenticated surface of endpoints that handle user registration, login, or password reset. If the API returns a password hash in plaintext (e.g., in a JSON response) or if the hash matches known weak patterns, middleBrick will flag it under the Data Exposure and Input Validation checks.
Example of using the middleBrick CLI to test a registration endpoint:
middlebrick scan https://api.example.com/register \
--method POST \
--header "Content-Type: application/json" \
--body '{"email":"[email protected]","password":"Test123!"}' \
--output json
The resulting JSON report will include a finding such as:
- Finding: Password hash returned in response appears to be unsalted MD5 (length 32 hex chars).
- Severity: Medium
- Remediation Guidance: Replace the hash with a strong, salted algorithm (bcrypt, scrypt, or PBKDF2) and never return the hash to the client.
Additionally, you can run a simple CQL query to audit existing data:
SELECT password, COUNT(*) FROM users GROUP BY password HAVING COUNT(*) > 1;
If this query returns rows, identical hashes exist across multiple accounts — a sign of missing salts and a potential rainbow‑table target.
Cassandra-Specific Remediation
The fix is to replace fast, unsalted hashes with a slow, salt‑dependent algorithm before writing to Cassandra. The hash itself (including its salt) can be stored as a plain text column because the algorithm already incorporates the salt. Below is a realistic Java example using the DataStax driver and the widely‑audited bcrypt library.
import com.datastax.oss.driver.api.core.CqlSession;
import com.datastax.oss.driver.api.core.cql.SimpleStatement;
import org.mindrot.jbcrypt.BCrypt;
public class UserRepository {
private final CqlSession session;
public UserRepository(CqlSession session) { this.session = session; }
public void createUser(String email, String plainPassword) {
// Generate a salt and hash the password with bcrypt (default workload 10)
String hashed = BCrypt.hashpw(plainPassword, BCrypt.gensalt());
String cql = "INSERT INTO users (email, password_hash, created_at) " +
"VALUES (?, ?, toTimestamp(now()))";
SimpleStatement stmt = SimpleStatement.newInstance(cql, email, hashed);
session.execute(stmt);
}
public boolean checkCredentials(String email, String plainPassword) {
String cql = "SELECT password_hash FROM users WHERE email = ?";
SimpleStatement stmt = SimpleStatement.newInstance(cql, email);
var rs = session.execute(stmt);
var row = rs.one();
if (row == null) return false;
String storedHash = row.getString("password_hash");
// bcrypt includes its own salt; compare directly
return BCrypt.checkpw(plainPassword, storedHash);
}
}
Key points in the example:
- The password is never stored in plaintext; only the bcrypt hash (which embeds a per‑user salt) is written to Cassandra.
- During authentication, the stored hash is retrieved and
BCrypt.checkpwperforms the constant‑time comparison, preventing timing attacks. - Because bcrypt is intentionally slow (default cost factor 10), building a rainbow table becomes infeasible.
If you prefer to stay within the Cassandra ecosystem, you can also leverage user‑defined functions (UDFs) to call a Java‑based hash function directly in CQL, but note that UDFs are disabled by default for security reasons and must be explicitly enabled with enable_user_defined_functions=true in cassandra.yaml. The safer approach is to perform hashing in the application layer as shown above.
Finally, harden the Cassandra cluster itself: enable client‑to‑node encryption (ssl in cassandra.yaml), restrict access to the system_auth keyspace, and use role‑based access control (RBAC) so that only trusted services can read the users table. Combining strong application‑level hashing with proper Cassandra configuration eliminates the rainbow‑table threat vector.
Frequently Asked Questions
Does enabling Cassandra’s internal authentication protect against rainbow table attacks on application passwords?
Can middleBrick detect if my API is returning a bcrypt hash instead of an MD5 hash?
$2a$, $2b$, or $2y$ followed by a 22‑character salt and 31‑character hash), it will be recorded as a finding with a low severity, indicating that the hash is strong and appropriately salted.