How to use adaptive hashes without making yourself vulnerable to DoS attacks

No ratings

Presented at LASCON 2014 by

Amit Sethi

In recent years, several organizations have had to deal with their users’ hashed passwords being stolen. Although adding salts to hashes can prevent some attacks (e.g. rainbow tables), this approach does not slow down brute force attacks. With increases in attackers’ computational capabilities, brute force attacks have become a real possibility. As a result, security experts now recommend using adaptive hashing functions. However, adaptive hashing functions are computationally more expensive than traditional hashes. This added expense can be abused by attackers to cause a Denial of Service. The most common approach to avoid a Denial of Service involves shifting most of the work to the client side, which is less secure. This talk will present a different solution that can prevent Denial of Service attacks resulting from attackers exploiting computationally intensive adaptive hash verification routines. The solution uses a proof of work scheme and separates Denial of Service protection from password protection in a way that minimizes delays observed by users during the authentication process. Separating the two protections allows the client-side computational requirements to be scaled dynamically based on whether the server is being attacked. Using threat modeling, this talk outlines relevant attack vectors. Next, the talk walks the audience through alternatives in secure design comparing each from security and performance perspectives. The talk answers the questions: * Is it okay to simply move adaptive hashing to the client side? * Is it okay if we leak salts to clients so that they can compute hashes? * Can we keep adaptive hash computation on the server side, but still protect the server from Denial of Service attacks? Audience members will leave with specific guidance to share with developers.