Why should a bcrypt() hash be stored in (var)binary?

Question

In our php application, we generate password hashes with password_hash() (using bcrypt).

bcrypt hashes should be stored in BINARY or VARBINARY (MySQL).

I totally understand this requirement if the comparison and/or search is done inside the database. (collation, case sensitive vs case insensitive).

If the database is only used as storage, and the comparision is done on the php application with password_verify(), can we stay with CHARor VARCHAR?

IF not, why?

Do you have to keep it in binary. I think it should be whatever's convenient. You can probably store space with binary but it's probably not going to be a massive gain — jpopesculian, Apr 27 '16 at 17:59
Actually we would prefere (var)char. But I read this and could not find use cases with mysql: http://stackoverflow.com/a/5882472/125075 — Toto, Apr 27 '16 at 19:03

score 3 · Accepted Answer · answered Apr 27 '16 at 18:08

You can store the result of password_hash() is something you can save in a normal VARCHAR(255) column, it's not binary data, just a string that looks like:

$2y$10$.vGA1O9wmRjrwAVXD98HNOgsNpDczlqm3Jq7KnEd1rVAGv3Fykk1a

These are, of course, case sensitive but they'll never use anything but regular letters, numbers, and a select few bits of syntax.

This column does not need to be indexed, in fact that would make almost no sense. The password_verify() function works against a specific password and is deliberately slow, testing versus every user in the system would take a long time. This is to make it harder for people to brute-force guess passwords.

Why should a bcrypt() hash be stored in (var)binary?

1 Answers1