Why is BCrypt more secure than just storing a salt and an encrypted password in the database?

Question

I am reading this article and it seems like BCrypt is:

slow to compute a hash from a password (a good thing)
doesn't store a salt in the database but just in the password directly
uses a log_rounds parameter which says how many times to compute the internal hash function.

So the hash would look something like this:

hashed = hashpw(plaintext_password, gensalt(log_rounds=13))
print hashed
'$2a$13$ZyprE5MRw2Q3WpNOGZWGbeG7ADUre1Q8QO.uUUtcbqloU0yvzavOm'

But if that's what's stored in the database, if the database gets hacked, aren't we still vulnerable? The BCrypt hash contains the salt and the encoded password and so why is this better than just storing the salt and the password in the database (The article calls it bad solution #4)?

Is the major difference the slowness of BCrypt's hashing mechanism which makes it hard and expensive to BCrypt a long list of common passwords?

as far as i read about BCrypt security it is really based on his slowness because the better the encryption is you use they slower it gets. One thing no one has is time. especially if you are trying to brutforce passwords — WiiMaxx

mjsa mjsa · Accepted Answer · 2015-09-24T23:46:33

You can't just hash a password, if you do that it will be vulnerable to dictionary attacks; therefore you salt the password before hashing it; this is what BCrypt does.

Password salts can be public, however they must be unique for each password. The point of them is to prevent dictionary attacks on hashes (so you can't look through a list of premade hashes which corresponds to passwords).

Like PBKDF2, Bcrypt is an adaptive function; you can increase iterations later on to make the hash less vulnerable to brute force attacks as more computing power comes out. Despite this Bcrypt is harder to accelerate on GPUs than PBKDF2.

Why is BCrypt more secure than just storing a salt and an encrypted password in the database?

1 Answers