Combining SCRYPT + a short crc

Question

I'm considering using SCRYPT for password storage. (I'm open to PBKDF2 as well, or bcrypt by itself).

The issue is that I don't want this to become a potential point for a DDOS attack, given the overhead of the actual computation.

I was thinking something VERY weak with a lot of collisions as a sanity check first (like CRC8) against the SALT+PASSPHRASE might be a good idea. (then using a wait before returning the failure to guard against timing attack).

This assumes a minimum length of 8, with a 3 of 4 requirement for:

• Uppercase Alpha
• Lowercase Alpha
• Number
• Non Alpha-numeric

How much would this would actually reduce the effectiveness of SCRYPT in a brute force attack should data be compromised?

Answer 1

You shouldn't mess with the algorithm like this. I can't think about what the impact of this method is but it does scream insecurity. At the very least, it would allow an attacker to move roughly 256 times as fast since CRC is a relatively simple math function and then of course faster on the database part. You're a few whiteboard coding exercises away from somebody dumping all your passwords if they get DB access.

Instead, issue a token using a cheap function that is rate-limited per client address or client address prefix and require that token with the username and password. That will allow you to rate limit how often you perform the expensive password checking process.

Answer 2

I upvoted Jeff's answer. Architecturally, you are better off creating some independent gate keeping functions that are tied to client address and which run when the client side login input screen is called. Keep this separate from your authentication routines. You can limit try rates or max tries before flagging the account in some fashion, and that does not require you to muck around with the core of the authentication.

Crypto implementations are a function the weakest link, and CRC is not even really a true cryptography hashing primitive. Its pretty bad in this regard. Storing CRC checksums creates problems because it allows an attacker who gets the database to utilize an easily paralleled process to reduce the work to attack each password in the database. Putting the CRC of the salt+pass phrase right there with the final scrypt hashes works for an attacker as a sort of a sieve. The attacker can run a fast routine that begins a brute force effort with no other object but to find strings that checksum to your stored CRC. Only strings that pass this sieve step have to run the gauntlet through the computationally and memory intensive scrypt hashing. Its even faster if the attacker is running dictionaries.