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?


2 Answers 2


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.

  • I know it was probably a stupid idea... was mainly as a thought experiment, as I wanted to use a stronger hashing/kdf system, but also wanted to avoid a relatively heavy DDOS vector... Will likely use redis for keeping a list of recent tries per account as suggested, and also send some sort of challenge to limit all around tries by IP address.
    – Tracker1
    Feb 2, 2015 at 23:48
  • @Tracker1 Yeah, sorry, but you're approaching that problem wrong. The purpose of a strong KDF is to be slow because of the kind of attacks they aim to prevent. DDoS's are a different kind of attack and require different preventative/response methods. Feb 3, 2015 at 6:00

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .