Secure password storing • www.martinstoeckli.ch • 9/13

Salting makes it definitively more difficult to recover the passwords, but there is still the problem with the fast video cards. Investing 3 seconds of computing power seems not a too big obstacle.

This is the reason why **Bcrypt** was invented. It originates from the encryption
algorithm Blowfish, nevertheless it is a real hash-function.

- Bcrypt uses a lot of
**computing time**, which makes a brute-force attack or building of rainbow-tables impracticable. - With a cost factor one can determine
**how much**time is needed. - The cost factor can be increased, to
**adapt**to later and therefore faster hardware.

For comparison: Even if we need only 1 ms computing power per hash-value, the creation of our example rainbow-table needs 8 months instead of 2.5 seconds.

The cost factor determines, how many times the Bcrypt function is called consecutively.
The cost factor will be raised to the power of 2, that means, increasing the cost factor by 1,
will **double** the computing time.

$numberofRounds = 2 ^ $costFactor

Of course the cost factor has to be stored as well in the database. This makes it possible to adapt the cost factor and to store a new hash-value.

Often hash-values are generated with a utility like **crypt** (Unix), a range of
computer languages like PHP have adopted this format. It writes the used
algorithm, the cost factor, the
salt and the hash-value to a string of length 60.
That string fits smoothly in database field.

$2y$10$nOUIs5kJ7naTuTFkBy1veuK0kSxUFXfuaOKdOKf9xYT0KKIGSJwFa

There are other algorithms which can be used for password hashing, all of them offer a cost factor. Recommended ones are BCrypt, SCrypt, PBKDF2 and the youngest one Argon2.