2

I've been using jBCrypt version 0.3 out-of-the-box now since it came out in 2010. I use the default getsalt() method which sets the number of "log_rounds" to 10. Given the progression of password cracking hardware and methods, is this value still appropriate as a default, or should i be looking at some higher value.

Info from the javadoc...

String pw_hash = BCrypt_v03.hashpw(plain_password, BCrypt_v03.gensalt());
String strong_salt = BCrypt_v03.gensalt(10)
String stronger_salt = BCrypt_v03.gensalt(12)

The amount of work increases exponentially (2**log_rounds), so each increment is twice as much work. The default log_rounds is 10, and the valid range is 4 to 31.

mikej
  • 65,295
  • 17
  • 152
  • 131
pjklauser
  • 1,156
  • 11
  • 13

1 Answers1

5

I made a little test class to check the performance of checkPw() under differing salt log_rounds. 

public void testCheckPerformance() {
    int MULT = 1;
    for( int i = 4; i < 31; i++) {
        String salt = BCrypt_v03.gensalt(i);
        String hashpw = BCrypt_v03.hashpw("my pwd", salt);
        long startTs = System.currentTimeMillis();
        for( int mult = 0; mult < MULT; mult++) {
            assertTrue(BCrypt_v03.checkpw("my pwd", hashpw));
        }
        long endTs = System.currentTimeMillis();
        System.out.println(""+i+": " + ((endTs-startTs)/MULT));
    }
}

My PC is an 8 core i7 2.8GHz. The results are:

log-rounds: time in millis.
4: 3
5: 3
6: 6
7: 11
8: 22
9: 46
10: 92
11: 188
12: 349
13: 780
14: 1449
15: 2785
16: 5676
17: 11247
18: 22264
19: 45170

Using the default log_rounds=10 means that a single thread can check a login in 0.1s. This potentially limits the number of login checks per second that a single server can achieve.

So i guess the question becomes how much time are you prepared to spend per password check vs how many password checks per second you want to size the system to cope with.

pjklauser
  • 1,156
  • 11
  • 13