| Blog and stuff | https://tobtu.com |
| GitHub | https://github.com/Sc00bz |
I just learned that JS has the exponential operation **:
Math.pow(a, b) == a ** b
I remember when I was like fuck it "a ^ b" in Excel and was like wait that worked? This is that moment for me but for JS. I remember having Excel 97 and Excel XP (or 2003). I assume 97 didn't have ^ but XP (or 2003) did... I'm not old you're old.
Or just recreate these with better settings and have it take ~43 days on an RTX 4090. 96% success rate, 2 perfect tables, 942651571967 chains/table (before perfecting), chain length of 630000, <3 TB (RTI2), 6 steps. These are twice as fast to use too.
OK or ~100 days on an RTX 4090. 99.9% success rate, 4 perfect tables, 1265875614643 chains/table (before perfecting), chain length of 720000, 3.95 TB (DIRT) (or 5.56 TB (RTI2)), 10 steps. These take 1.443x longer to use but if you only use 2 tables it's 1.386x faster and higher success rate 96.84% (vs 94.75%).
Rainbow tables aren't that hard. Woof 94.75% success rate, 1 imperfect table, unsorted RT files, sequential start points, 549755568128 chains, chain length of 881689, 8 TiB. Effective rate is 89.77%.
You'll need to run rtsort on all the tables, then rtmerge, then rt2rti2 to make it 4 TiB instead of 8 TiB. If only they knew what they were doing.
https://cloud.google.com/blog/topics/threat-intelligence/net-ntlmv1-deprecation-rainbow-tables/
@atoponce That's an AI vibe coded company and that article has massive errors besides hallucinating the whole issue. Since none of those algorithms (properly implemented) can DoS. Here's a fun vulnerability they created:
> 1. User sends a 1MB password.
> 2. Server computes `temp_hash = SHA-256(password)`.
> 3. The output of SHA-256 is always a fixed 32-byte string.
> 4. Server computes `final_hash = Bcrypt(temp_hash)`.
In PHP, this is broken because of C strings in the library that does bcrypt.
P.S. The contact page has this:
> InstaTunnel Inc.
> 123 Tech Street
> Suite 100
> San Francisco, CA 94105
> United States
> Phone: +1 (555) 123-4567
@dangoodin Three things the paper got wrong:
* Bitwarden has a minimum of 5000 iterations (https://github.com/bitwarden/clients/blame/e262441999e4e243f903c8a781fcefc7906fa60c/libs/key-management/src/models/kdf-config.ts#L18).
* 1Password's "KDF Parameter Downgrade" attack doesn't exist because they use a PAKE (SRP6a).
* The mitigations for "KDF Parameter Downgrade": "Further, authenticating security-critical user settings like PBKDF parameters (such as the iteration count) would mitigate the KDF attacks (BW07, LP04). The client can use the server-provided KDF parameters to derive the authentication key, use it to verify the integrity of the parameters themselves, and – in case of a mismatch – abort before any further communication with the server." (page 17)
(Edit: The authentication for the KDF settings is sent after the user logs in. So instead of being dangerous it is worthless because the malicious server will say it's the wrong password, drop the connection, or return an HTTP server error like 500 or 503. [See edit history for the original removed text.])
Also this is all I really looked at because I was wondering if they found the downgrade attacks I've been complaining about for ~15 years.
Bitwarden client apps (web, browser extension, desktop, and cli). - Blaming clients/libs/key-management/src/models/kdf-config.ts at e262441999e4e243f903c8a781fcefc7906fa60c · bitwarden/clients
@dchest They also suggest this for Bitwarden and LastPass. So it's exactly the same as that.
"Further, authenticating security-critical user settings like PBKDF parameters (such as the iteration count) would mitigate the KDF attacks (BW07, LP04). The client can use the server-provided KDF parameters to derive the authentication key, use it to verify the integrity of the parameters themselves, and – in case of a mismatch – abort before any further communication with the server."
