В поле какого типа (mysql) хранить пароль после password_hash?
На сегодняшний день по умолчанию password_hash кодирует через bcrypt (предположим, его и хочу оставить).
PHP предупреждают, что bcrypt может в дальнейшем увеличиться до 255 символов.
MYSQL, в свою очередь, рекомендует хранить хэши в varbinary или blob.
Так какую оптимально длину указывать полю varbinary? На сколько я понимаю, в поле varbinary 2 байта уходит на указание размера поля. Прихожу к выводу, что оптимальное значение = 257. Но google по "varbinary(257)" что-то вообще ничего не находит по данной теме, следовательно, все используют какое-то другое значение. Так какое же?
Измениться может не длина хэша bcrypt, а алгоритм хэширования по-умолчанию (то есть, под PASSWORD_DEFAULT в новых версиях PHP могут подразумеваться алгоритмы, отличный от bcrypt).
Хэши нужно хранить в blob поле только, если сгенерированный хэш находится в бинарном представление (добиться этого можно, передав в функцию hash() последним параметром значение true). Bcrypt же представлен в символьном виде.
Итог: для хранения хэшей bcrypt используем поле VARCHAR(60), а лучше - CHAR(60) - так как строка имеет фиксированную длину.
Спасибо, всё по делу. Да, действительно, ещё раз внимательно прочитал доку PHP, bcrypt будет всегда выдавать 60, это другие алгоритмы могут выдавать больше.
И mysql ещё раз внимательно прочитал:
Many encryption and compression functions return strings for which the result might contain arbitrary byte values. If you want to store these results, use a column with a VARBINARY or BLOB binary string data type. This will avoid potential problems with trailing space removal or character set conversion that would change data values, such as may occur if you use a nonbinary string data type (CHAR, VARCHAR, TEXT).
Да, здесь Вы тоже правы, видимо это касается только случаев, когда функции кодирования возвращают значение в бинарном представлении. Не внимательно читал.
Varchar(60) в данном случае тогда действительно выглядит более логичным, особенно если явно указывать функции password_hash кодировку bcrypt (как защита от внезапной смены дефолтной кодировки).
Ещё вопросик хочу напоследок задать, есть ли в нашем случае у varchar(60) какое-то преимущество перед char(60), или наоборот?
Ещё вопросик хочу напоследок задать, есть ли в нашем случае у varchar(60) какое-то преимущество перед char(60), или наоборот?
Хороший вопрос. Про char я, честно говоря, запамятовал. В данном случае, преимущество у CHAR(60), так как длина строки, генерируемой алгоритмом bcrypt всегда равна 60. Используя CHAR получаем небольшой прирост в производительности.
D3lphi, Кстати я тут ещё немного почитал про MySQL, и я так понял что маловероятно получить + в производительности от использования CHAR, т.к. при наличии в таблице иного поля с varchar, все поля с char будут тоже преобразованы в varchar. А поскольку пароли как правило хранятся в таблице о юзерах, то там, разумеется, будут и логины, и емейлы и ещё куча всего, где есть varchar, соответственно char(60) всё равно будет преобразовано в varchar(60), правильно ли я понимаю?
Barrakuda74, это все детали реализации конкретной СУБД. Тип CHAR по определению является более эффективным, чем VARCHAR, если речь идёт о хранении данных фиксированной длины.
VARCHAR - Строка этого типа хранится в базе данных без изменений (в отличии от char(n)), поэтому нагрузка на процессор при обработке varchar-строк немного меньше, чем при работе с char(n)
Уже голова крУгом))))))
добавлено: хотя, возможно тут лишь идёт речь о случаях, если процессору приходится вмешиваться в преобразование строк char, т.е. в случае если значение короче указанного размера, тогда звучит логично. Если же про все случаи, тогда непонятки)
Средний
