DEV Community

Discussion on: How to Properly Hash and Salt Passwords in Golang Using Bcrypt 🔒

Collapse
 
vhiuwhfqowuhef profile image
vhiuwhfqowuhef • Edited

There is a really significant flaw here that makes this advice actually harmful.

Use of bcrypt.MinCost (a value of 4) renders BCrypt nearly useless. It is exactly the wrong value to use for actually storing passwords securely. The entire point of BCrypt is to be slow, choosing the lowest possible cost makes BCrypt fast, completely defeating the purpose of using BCrypt in the first place. You should only ever use the minimum cost in your test suite, to avoid slowing down tests. MinCost should never be the default value you reach for.

In fact, the bcrypt.DefaultCost of 10, which is meant to be a safe default to use, is still too low by today's standards. You should be defaulting to 12 at this point, and ideally measuring and picking the highest possible value you can afford, based on how much latency it adds during login/signup.

Anybody copy-pasting this code into their app is going to be producing extremely insecure password hashes. Even when BCrypt was first introduced more than 20 years ago, the cost factor recommended was 6 for normal users and 8 for super users, which are respectively four and sixteen times slower than a cost of 4.

See labs.clio.com/bcrypt-cost-factor-4... which shows how dangerous low costs are, and note that the lowest they bother to test is 6, which is still 4x slower than the MinCost you're recommending here.