Password - Binary Modular Crypt Format

Question

Password - Binary Modular Crypt Format

Navigation

#1 by (2 votes)

3

I find myself at this point reducing the size of a database and several techniques are used. However I have a question about the decision to make at one point and I would like someone to help me.

In the model in question and in the user table a BCRYPT password is used, this 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 it's worth, not in the sense of security but in the work of reducing the database.

For an algorithm in PHP will I be right? In other words, a "layer" on high availability servers will put some latency, but if it keeps the current MCF and taking into account that the password is not an "INDEX" field of the database will it be worth it? / p>

Are you aware of other alternative techniques?

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

php mysql

asked by anonymous 16.09.2014 / 15:41

1 answer

What is the Journal file for Android Can I return a struct by initializing it inside a return in ANSI C?

score 2 · Accepted Answer

Because I have not gotten any answer to my question, I have put my decision in the hope that it will be useful for someone.

My starting point was to reduce the size of the database that is shared by several SHARDS and that even then the diagnosis will soon burst through the seams. Before putting up a new server and splitting the various SHARDS across the servers, my effort was to reduce what was possible.

Many were the aspects considered and after my analysis, I achieved in many tables a reduction near 33% ... that is in tables of almost 1TB reduce only with optimizations of fields and some changes of PHP code inclusivé was reason for already win a medal ... heheheh (sorry for the aside)

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

Reducing a 60-byte field from a BCRYPT password to 40 can actually be done and the gain in a simplistic analysis is to run and neither look back.

However, this process had some bad points:

adds another layer to the system for recording and reading

the recording must happen in a BINARY field

The content is no longer a STANDARD

Now, in the case the PASSWORD field is not an index field and whoever deals with MYSQL knows of some problems that are encountered when writing fields in BINARY. Having already managed to reduce the size of the registry I have chosen to only change a field VARCHAR(60) to CHAR(60) BINARY and thus keep the standard taking into account that BCRYPT ...

is an already very secure process and the resulting hash is much more than a hash

The evaluation to know if the password needs rehash is immediate after reading without need another layer

the same as point 2 but for the "salt"

Changing VARCHAR to CHAR seems obvious to me, and the BINARY TAG is only so that it is not considered _bin so that no character translation occurs.

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

Conclusion I kept the size!