Просмотр полной версии : [Вопрос] Упакованный хеш
Как-то наткунулся на тему от Daniel_Cortez про упаковку хеша SHA256. Всё тщательно изучил и реализовал. Проблема возникает при сохранении упакованного хеша в базе данных. После сохранение и загрузки упакованного хеша в переменную, оно полностью меняется. После чего игрок не может пройти авторизацию. Вопрос, вообще можно ли сохранять такие строки в базе данных, просто после упаковки они становятся иероглифами. Примечание, в базе данных кодировка UTF-8.
Может быть немного скринов и кода?
Тему можно закрывать, решение не найдено.
Альтернативное решение: использовать UNHEX для хешов в базе данных (@Deimos) <- Но это ещё не протестировано.
использовать UNHEX для хешов в базе данных (@Deimos) <- Но это ещё не протестировано.
*Протестировано и прекрасно работает :)
Хотя, думаю, можно и лучше вариант реализовать (благо в MySQL полно функционала для конвертирования данных), просто я никогда этим функционалом MySQL особо не интересовался и рассказал лишь о том, о чём когда-то читал "вскользь".
Если у кого-то будет что-то добавить касаемо вопроса, можете отписать в личку и отрою тему.
Закрыто.
Daniel_Cortez
28.05.2018, 18:46
Удалил свою тему с функциями упаковки/распаковки хешей - всё равно проку от них немного, если в MySQL есть встроенные средства для хранения хешей в упакованном виде.
К слову о тех средствах...
Тему можно закрывать, решение не найдено.
Альтернативное решение: использовать UNHEX для хешов в базе данных (@Deimos) <- Но это ещё не протестировано.
На самом деле, использование UNHEX совершенно необязательно, понадобится только функция HEX для распаковки бинарных данных обратно в строку.
Скажу сразу, я не работаю с модами на MySQL и у меня нет под рукой сервера с одним из таких модов, чтобы всё протестировать, равно как и нет времени на подготовку всего этого. Всё, что у меня есть на данный момент - это XAMPP с phpmyadmin и сервером MySQL в комплекте; этого должно хватить, чтоб хотя бы проверить работу запросов к БД.
Итак, допустим, у нас есть таблица, в которой одно поле отведено под ID (ключ) и другое под хеш-сумму в бинарном (упакованном) виде.
CREATE TABLE `test` (
`id` INT UNSIGNED NOT NULL AUTO_INCREMENT,
/* SHA-256 выдаёт 32 байта (256 бит) данных,
* поэтому длина бинарной строки тоже должна быть равна 32
*/
`data` BINARY(32) NOT NULL,
PRIMARY KEY (`id`)
)
Едем дальше, упаковка и сохранение хеша в БД должна выглядеть примерно так:
INSERT INTO `test`(`data`) VALUES (0xE3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855)
Как видно из примера, конвертация строки в данные (бинарную строку) производится в обход функции UNHEX - достаточно просто добавить перед хешем префикс "0x".
Т.е. примерно так должен составляться запрос:
static const fmt_str[] = "INSERT INTO `test`(`data`) VALUES (0x%e)";
new string[sizeof(fmt_str) + (-2 + 64)];
SHA256_PassHash(/* ... */, /* ... */, string, sizeof(string));
mysql_format(mysql_connection, string, sizeof(string), fmt_str, string);
И запрос для выгрузки хеша из БД:
SELECT HEX(`data`) FROM `test` WHERE `id`=1
Здесь функция HEX конвертирует бинарные данные в обычную строку, которую можно получить с помощью cache_get_value_name.
Таким нехитрым(?) методом можно заставить хеш занимать в 4 раза меньше места в БД, всё с помощью встроенного функционала MySQL.
Как видно из примера, конвертация строки в данные (бинарную строку) производится в обход функции UNHEX - достаточно просто добавить перед хешем префикс "0x".
Только стоит понимать, что UNHEX, помимо конвертирования данных, занимается ещё и проверкой их валидности, так что не стоит всецело отказываться от данной функции (она нужна там, где нужно работать именно с числами в шестнадцатеричной системе счисления).
Powered by vBulletin® Version 4.2.0 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot