Most developers know that you should never store passwords in plain text, and know that they should be hashed. Only slightly fewer know that they should be stored utilizing a “salt” to append to the password to prevent time trade-off attacks (1). Fewer know what hash function they should use, and it seems lately, the majority don’t know that they shouldn’t just be salting and hashing at all, and instead should be using a key derivation function such as PBKDF2, or scrypt. We will be exploring utilizing PBKDF2, but scrypt is a perfectly viable option. The current draft of the new NIST guidelines says (2):
Verifiers SHALL store memorized secrets in a form that is resistant to offline attacks. Secrets SHALL be hashed with a salt value using an approved hash function such as PBKDF2 as described in [SP800-132]. The salt…
I recently ran into an issue while working on a project dealing with an external, rate limited, REST API. We wanted to perform an action on several thousand local objects which required hitting this external service and getting back a response. Running in an iterative pattern wasn’t an option for us because it would take too long, and guessing the number to try per minute wasn’t an option either because we might incur extra charges from the provider of the external API. The solution was to create a rate limited ThreadPool in our C# application to perform the requests, and a BlockingCollection to store the responses.