bcrypt处理64字符字符串：$cost=6是否可行？理想值需防ASIC/FPGA攻击

Let's break down your bcrypt questions one by one—these are solid, practical security concerns, so let's get straight to it.

Question 1: Is setting $cost to 6 feasible for a 64-character string? #

Technically feasible? Yes. Secure? Not even close.

Here's why:

• Bcrypt can handle input strings up to 72 bytes (for plain ASCII, that's 72 characters). Your 64-character string fits well within this limit, so there's no technical block to using cost=6 here.
• The problem is the cost value itself: cost=6 means bcrypt runs only 2^6 = 64 iterations. On any modern CPU/GPU, this takes microseconds to compute. An attacker with a basic gaming GPU could crack millions of these hashes per second—offering basically zero protection against brute-force or dictionary attacks. Don't use this cost for any production system handling sensitive data like withdrawal keys.

Question 2: What's the ideal $cost to resist brute-force, ASIC/FPGA attacks for your secret key scenario? #

First, let's ground this in your requirements:

• Your $secret_key is a high-entropy, unguessable value (I hope it's a long, cryptographically random string—if not, fix that first, because no hash can save a weak, guessable key!)
• Even if an attacker steals $store_data (the bcrypt hash), they can't reverse it to get $secret_key
• You need to defend against specialized hardware like ASICs/FPGAs

Bcrypt was built to be resistant to ASIC/FPGA attacks (unlike older hashes like MD5 or SHA-1), but that resistance isn't perfect. The ideal cost value balances two things: your application's acceptable latency and maximizing the attacker's time/hardware cost.

Here's how to pick the right number:

1. Test on your production hardware: The cost value is exponential—each increment doubles the number of iterations (2^cost). You want the highest cost that doesn't make user interactions feel sluggish. For example:
   • On a modern server CPU, cost=12 might take ~50-100ms per hash (reasonable for most transactional systems)
   • Cost=14 could take ~200-400ms (still manageable for non-real-time actions like withdrawal verification)
   • Cost=16 would take ~800ms-1.6s (probably too slow for most user-facing apps)
2. Prioritize the highest cost you can tolerate: Higher costs make attacks exponentially harder. Even if an attacker uses an ASIC that's 1000x faster than your CPU, jumping from cost=6 to cost=14 means they have to do 2^14 / 2^6 = 256x more work. That turns a crackable hash in minutes into one that would take years, even with specialized hardware.
3. Handle long secret keys properly: If your $secret_key is longer than 72 bytes (e.g., a 128-character random string), bcrypt will silently truncate it. To preserve all the entropy of your key, first hash it with SHA-256 (to get a 32-byte digest), then pass that digest to bcrypt. This way, you're not wasting any of the key's randomness.

As a 2024 baseline, cost=12 to 14 is a strong starting point, but always test on your actual hardware to find the sweet spot between security and user experience.

内容的提问来源于stack exchange，提问作者Alex Robertson