0

I am going to be hashing user passwords on the client machine, and I would like the hash to be generated in 0.3 seconds.

Do I need to find the number of rounds myself and make every user use this number, or should the number of rounds depend on the machine?

For example, if I found that 10 rounds took 0.3 seconds on my machine, does this mean every user should use 10 rounds? Or should it be on a per-machine basis. If it's per machine, I will have to send the number of rounds to a server and store the number of rounds on the user machine to make sure this number is always used in the future. Is that ok? Or do things not to be that complex?

user3100783
  • 115
  • 1
  • 4

3 Answers3

0

The tuning of the cost factor for BCrypt is mainly a problem for server side applications. If the cost factor is too high, the server can become very busy only with calculating hashes, when a number of people try to login at the same time. That's why we try to find a suitable number of rounds for this server.

If you are doing the calculation client side, every client has enough cpu power on its own to calculate even a large number of rounds, the power grows with the number of clients. Web applications should calculate the hash server side though.

martinstoeckli
  • 5,279
  • 2
  • 29
  • 32
  • Once javascript offers password hashes with decent performance, even web applications can use client side hashing. – CodesInChaos Jan 31 '14 at 09:32
  • @CodesInChaos - You could at least split the work on client and server, so the client could do the heavy work, while the server could hash with a "lite" algorithm before storing in the database. The question is whether you can rely on JavaScript at client side, but today probably we can. – martinstoeckli Jan 31 '14 at 09:58
  • Suppose I do X rounds for a 0.3 second target on the client and Y rounds for a 0.1 second target on the server (encrypting the hash the client sent). My server is really not powerful, and 0.3 seconds is just too long to do on the server. This would make getting the original plaintext password hard, but getting the hash for authentication not very hard. Is this an acceptable trade? – user3100783 Feb 01 '14 at 19:04
  • @user3100783 - Theoretically it would be ok to calculate the BCrypt hash client side, and only do a fast SHA512 on server side. This works, because the calculated BCrypt hash is a very strong "password", and for strong passwords a simple hash is enough. The problem is, that JavaScript is a slow language for this kind of calculation, so you will probably do fewer rounds and that weakens the security. – martinstoeckli Feb 02 '14 at 14:36
0

If you take a look a this implementation in PHP you will see that the number of round is stored in a database, that mean it is possible to change the number of round if needed.

So as long as you store the number of round somewhere you do not need to have the same number of round for every user.

null
  • 1,203
  • 7
  • 16
0

There is no need for having the same number of rounds everywhere. When hashing again a given password (e.g. when a password is verified), you need to use the same number of rounds as previously (otherwise you don't end up with the same value), so if the number is not hardcoded, then it must be stored along with the salt and hash value. But usual bcrypt implementation do just that: the output is a string which encodes the actual 192-bit output but also the salt and iteration count.

In fact, in most cases where password hashing occurs on the client side, the salt is still stored on the server, so you have to arrange for the sending of the salt as a prior step; you may send the iteration count in the same message.

Note, though, that the extra security against brute force is directly proportional to this iteration count, so instances where you allow the iteration count to be low will be comparatively weaker. This count is a trade-off between security and user convenience: the higher the count, the better the security, but also the longer the human user waits.

Tom Leek
  • 172,594
  • 29
  • 349
  • 481