Password - Binary Modular Crypt Format

Question

I am currently reducing the size of a database and several are the techniques used. However, I have a question about the decision to make at a point and I would like someone to help me.

In the model in question and in the user table is used a BCRYPT password that has defined a maximum size of 60 bytes in the database. I know that using techniques BMCF (Binary Modular Crypt Format ) can achieve reductions to 40 bytes... to the detriment of MCF which is the standard.

However this technique adds another "layer" that in the case of passwords I think is worth, not in the sense of safety but in the work of reducing the database.

For a PHP algorithm am I right? That is another "layer" on high availability servers will put some latency, but if you keep the current MCF and taking into account that the password is not an "INDEX" field of the database will be worth it?

Know other alternative techniques?

PS: I know there are others besides BCRYPT but this I can not change.

Answer 1

For not getting any answer to my question I ask what my decision is hoping that it will be useful for someone.

My starting point was to reduce the size of the database that is broken down by several SHARDS and that even so and the diagnosis will soon burst at the seams. Before I put new server and split the various SHARDS among the servers, my effort was to reduce what was possible.

Many were the aspects considered and after my analysis, I managed in many tables a reduction close to 33%... ie in tables of almost 1TB reduce only with field optimizations and some inclusive PHP code changes was reason to already win a medal... heheheh (Sorry for the aside)

However the user table was missing and then after the fight I came across the field of PASSWORD. And it was then that in doubt I put here the question.

Reduce a field of 60 bytes of a BCRYPT password to 40 in reality can be done and the gain in a simplistic analysis is to run and not look back.

However, this process had some negative aspects:

1. adds another layer to the system for writing and reading
2. recording must take place in a BINARY field
3. Content is no longer a STANDARD

However, in this case the PASSWORD field is not an index field and those who deal with MYSQL know of some problems that are obtained when saving fields in BINARY. Having already managed to reduce the size of the record I chose to just change a field VARCHAR(60) for CHAR(60) BINARY and thus maintain the standard taking into account that BCRYPT...

1. is already a very secure process and that the resulting hash is much more than a hash
2. the evaluation to know if the password needs the re-hash is immediate after reading without need one more "layer"
3. the same as in point 2 but for obtaining "salt"
4. the change from VARCHAR to CHAR seems obvious to me and the BINARY TAG is only so that it is not considered _bin so that no translation of characters happens.

I hope to help others when faced with a similar situation.

Completion kept the size!