I usually store it in hexadecimal number but realize I could save half of the space if I store it in binary inside MySQL. Are there any issues I should be aware of if I decide to store it in binary?
-
1Not sure if this really answers the question, but in modern PHP applications, using [`password_hash()`](https://www.php.net/manual/en/function.password-hash.php) is probably a better alternative than worrying about if it should be binary or hex - [How to use PHP's password_hash to hash and verify passwords](https://stackoverflow.com/questions/30279321/how-to-use-phps-password-hash-to-hash-and-verify-passwords) – Nigel Ren Jun 27 '20 at 11:41
-
This is actually a duplicate of [storing-hexadecimal-values-as-binary-in-mysql](https://stackoverflow.com/questions/1712934/storing-hexadecimal-values-as-binary-in-mysql). IMHO both questions would be off-topic today. And the answers here are even more off-topic. – Paul Spiegel Jul 01 '20 at 07:15
4 Answers
How many passwords are you expecting to store? Does half the space mean that much to you really?
You are probably representing the passwords in hexadecimal form in your application, so storing them in binary adds another layer of complexity and processing overhead when you perform any operations on those passwords.
My opinion is that you should store them in a way that is convenient for you to work with, rather than one that saves you tiny amounts of space.
Edit:
Going to make some assumptions and take the opportunity to help you a little further.
Since your passwords are in hex, I'm going to assume you're not using crypt
, and if you're not, you should be. Worst case scenario, you're using md5... and god is killing kittens.
There's a lot of questions and answers about bcrypt on stack overflow already, so I'll not cover the information again here.
The question SHA512 vs. Blowfish and Bcrypt is a good place to start though.
Also have a read of a couple of @ircmaxell's blog posts on the subject:
-
Good point, you would have to unpack them to hex each time you pulled the record from the database. – Xeoncross Aug 08 '12 at 18:46
-
Or you pack the password you want to compare with the saved hash. I don't think, that it is very difficult. However, I don't think either, that it isn't worth it. – KingCrunch Aug 08 '12 at 18:47
-
I've also encountered one issue in the past with a badly dumped DB using binary fields, required so much work to get it to restore. – Leigh Aug 08 '12 at 18:49
-
-
-
4
-
@Leigh Just to comment on your edit, I am using SHA512 iterated to a million. I actually have a question about it which is apparently snubbed http://stackoverflow.com/questions/11869407/is-stretching-hash-several-times-basically-the-same-as-bcrypt – IMB Aug 08 '12 at 19:33
From a usability standpoint, it's probably best to store the hash as a hexadecimal. Storing them in binary means one more step is required to compare a plain text input to the stored password. It also has the potential to add a layer of confusion to anyone who make work on your project after you've moved on. "Why is this password stored in binary?"

- 752
- 3
- 13
-
1Binary is super annoying if not encoded correctly, and as an additional down-side, it cannot be viewed or copy-pasted easily. – tadman Aug 08 '12 at 18:55
Disclaimer: Let's be real, this question must be on the border of being closed as purely opinion based. So any answer you get is a matter of preference and expierence.
Just to add my common sense answer to this question: You should store it the way you get it from your encryption tool/method.
Any good encryption has an encrypt
and a decrypt
or compare
method. Normally the output of the encrypt
is what you need to pass as input to the decrypt
/compare
.
Whatever output encrypt
is producing, should be the prefered way of storing it.
You can convert the output to whatever you like, whether it is binary, hex, base64 or write it down using pen and paper, the encrypted value will not become more or less secure. Somebody that finds the value, will need the encryption keys to decrypt it.
But everytime you convert something, you also need to convert it back to it's previous state. Which means you add a new layer of potential problems and add overhead on the whole proces. However negligible it might be, it still is more complex/slower then not doing it at all.

- 13,803
- 5
- 45
- 72
-
"Let's be real, this question must be on the border of being closed as purely opinion based." Imo, that's sad. This a decision virtually every developer working on a semi-serious app has to make, yet we don't have a decent answer to refer to. Sure, I have my speculation, but I don't know if I am missing something. – VSO Jun 30 '20 at 15:14
-
4There is a programming stackexchange for these kinds of discussions. Stackoverflow is for solveable coding questions – Hugo Delsing Jun 30 '20 at 17:39
The main motive when it comes to password is How secured it is rather than just scaling for the sizes or space taken by it in the databases and because of this your password must contain all the security entities such as Algorithm , Algorithm Options (for eg: time cost, memory cost, threads),Salts,Hashed Password.This all together make your password far more stronger than a simple hex or binary password.
References:
And as per the first link The suggested algorithm to use when hashing passwords is Blowfish, which is also the default used by the password hashing API, as it is significantly more computationally expensive than MD5 or SHA1, while still being scalable.
You can use the
echo password_hash("rasmuslerdorf", PASSWORD_DEFAULT);
Output
$2y$10$.vGA1O9wmRjrwAVXD98HNOgsNpDczlqm3Jq7KnEd1rVAGv3Fykk1a
Here your password consists of all Algorithm , Algorithm Options (for eg: time cost, memory cost, threads),Salts,Hashed Password

- 2,495
- 2
- 9
- 25