Anti-GPU Password Cracking

James+Stephen

Anti-GPU Password Cracking

Making Brute Force Attacks Impractical

In traditional CPU architecture, we typically see 4/8/12 cores inside a processor. However, even an entry-level GPU contains at least 3,000 cores. This presents a significant security concern when someone uses GPUs for brute force password cracking – they can achieve tremendous calculation speedups by deploying multiple GPUs simultaneously.

Consider this: an attacker with 1,000 GPUs (each having 3,000 cores) can potentially achieve a 3,000,000x speedup in brute force calculations. With this kind of computational power, passwords shorter than 14 characters become relatively easy targets.

Memory-Hard Functions: A Smart Defense

Modern hash calculation algorithms counter this threat by incorporating RAM requirements into their foundational calculations. For example, some algorithms require at least 64MB of RAM to complete a single hash operation. While you can still utilize all 3,000 GPU cores, each thread would need to allocate 64MB of RAM, demanding a total of 192GB RAM in the GPU. Without sufficient memory, the operations either stall or queue up waiting for available RAM.

If you increase the parameter to 256MB RAM (easily achievable on modern phones), a GPU would need 768GB of memory – far beyond what’s currently available in consumer hardware. This is the principle behind memory-hard functions that provide anti-brute-force protection.

Current GPUs typically have around 8GB of memory, so a 64MB requirement per hash operation is adequate for security. As GPUs evolve to include more RAM, phones and laptops will likewise increase their memory capacity. By scaling the RAM requirement proportionally to GPU memory increases, we maintain a “security gap” that makes brute-force attacks impractical.

Argon2: A Practical Implementation

Argon2 is one implementation of these memory-hard algorithms. While its memory requirements aren’t perfect, it’s quite effective for current security needs.

However, I discovered an issue when using the official package. If you use the lazy-loading package provided by the author (argon2-bundled.min.js), it attempts to connect to the author’s server. This isn’t due to the WASM file itself but rather the JavaScript wrapper. By avoiding the bundled package and instead using the base argon2.js with manual WASM loading, you can create your own independent version that doesn’t attempt external connections.

My Open-Source Solution

I’ve open-sourced my version called load_argon2.js, which works with the original argon2.wasm and argon2.js files. It automatically loads the WASM module and waits for your function calls.

Implementation requires only two steps:

  1. Call the initialization function: argon2Ready()
  2. Use argon2_calc() to calculate the hash

I’ve also provided a test file, test_argon2_100.html, which runs the calculation 100 times to benchmark performance on your specific platform.

By implementing memory-hard functions like Argon2, we can maintain password security even as GPU capabilities continue to advance.