Hacker News Reader

Comment by tptacek | Hacker News Reader

If you can't understand the significance of these two results (and this is with the default cost factor for BCrypt), you're just arguing to hear yourself talk.

  t1 = Time.now.to_i
  100.times { BCrypt::Password.create("ugh8&eat") } 
  puts Time.now.to_i - t1
  => 12

  t1 = Time.now.to_i
  100.times { Digest::SHA1.hexdigest("ugh8&eat") } 
  puts Time.now.to_i - t1
  => 0

I could raise the number of iterations to bring SHA1 above the measurement floor, but I don't want to lock my computer up with pointless BCrypt cycles.

View on HN

Using these numbers, it would take your computer roughly 12 years to check 32M passwords against that string. That's a long time, but feasible (with additional power), and more specialized systems can bring it within reach.

In contrast, assuming a 40-character (20 in config, 20 in database) alphanumeric salt, an attacker would have to perform 704423425546998022968330264616370176 digests per row to check 32M passwords.

Unless you believe that is an insufficient barrier, implementing BCrypt is merely degrading the user experience (12-second logins? come on) for no real improvement.

I think that the salient detail is this:

    t = Time.now.to_i
    1000000.times {Digest::SHA1.hexdigest("ugh8&eat")}
    puts (Time.now.to_i - t).to_s
    =>3

Sure, 120ms is a bit long, but I think it would be beneficial to security to require more than 3µs.

Edit: I match my parent's problem with 32M checks taking 12 years with my personal computer taking 132.86 seconds to calculate 32M SHA1s.

There are lots of ideas which are beneficial, but not particularly useful. For example, requiring passwords to be at least 120 characters would (in theory) make passwords more difficult to compromise, but in practice users are just going to type "password" 15 times.

Increasing the digest time prevents an attacker with simultaneous access to the server and database from cracking very weak passwords, but at the cost of tripling or quadrupling how much time each request takes. There are some cases where this could be useful -- for example, running a dissident website in an authoritarian country -- but it's user-hostile to implement it anywhere else.

Calculating a BCrypt hash with the default cost factor takes about as long as reading an uncached file off a conventional filesystem. What a silly thing to try to optimize. Really? It's killing you to spend 100ms on password hashing? Ok, dial it down to 50ms. BCrypt is tunable.

His computer is taking 12 seconds for 100 iterations. The time spent checking the password would be more like 120 ms, totally in the order of a decently fast http request.

Reply on news.ycombinator.com