Как хешировать email при регистрации пользователя и проверять при восстановлении?

Question

[Кирилл Красин]

Доброго.

Задача: При регистрации пользователя хешировать указанный email и вносить его в таком виде в БД.
email используется в двух сценариях:
— Для отправки письма при регистрации (письмо формируется ДО внесения в БД, на этом этапе проблем нет).
— Для восстановления доступа к учетной записи. На данный момент email не хеширован, просто сверяю наличие указанного адреса в БД, и при совпадении отправляю письмо с ссылкой на восстановление.

С восстановлением пароля соответственно появляются проблемы. Как вариант использовать тот-же password_hash для внесения в БД, и проверять через password_verify сопоставляя хеш и указанный в форму email. Но не уверен насколько это правильное и вообще рабочее решение.

Заморочки данные от связанны с требованиями по хранению персональной информации. Хочется вообще оградить себя от данных нюансов, и не хранить ничего кроме хешей.

Comments

[alexalexes]

При регистрации пользователя хешировать указанный email и вносить его в таком виде в БД.

Какая цель сего действа? Предотвратить утечку фактов, что такие-то юзеры пользуются вашей системой?
Обычно, хешированием обрабатывают пароль. Логин хранят как есть.

[Adamos]

Вообще-то сильно шифровать почту (в частности, солить хэш) совершенно необязательно.
Даже если базу украдут - вряд ли у кого-то есть радужные таблицы по часто используемым адресам почты.
А несоленые хэши по базе ищутся без проблем.

[Кирилл Красин]

alexalexes, чуть ниже ведь написал:

Заморочки данные от связанны с требованиями по хранению персональной информации. Хочется вообще оградить себя от данных нюансов, и не хранить ничего кроме хешей.

[Кирилл Красин]

Adamos, основная цель, со стороны БД вообще оградить себя от персональных данных в открытом виде.
Пароль хешируется необратимо через password_hash.

[Adamos]

Кирилл Красин, вы не тому отвечаете.
Я просто предложил использовать для почты не индивидуальный хэш.

[Рамис]

Интересно, есть ли вероятность что хеши совпадут с разными email?

[Кирилл Красин]

Adamos, прошу прощения, не в ту сторону воевать начал)

[Кирилл Красин]

Рамис, если я правильно помню, там более миллиарда записей нужно чтобы вероятность появилась. но это не точно))

[Adamos]

Рамис, стало интересно, проверил на таблице в 100 тысяч уникальных мыл.
Коллизий среди 32-символьных MD5 не случилось.

[Кирилл Красин]

Adamos, ну password_hash() с алгоритмом BCRYPT (дефолт) генерирует 60 символьный хеш, вроде как a-Z0-9, минус начальный ИД $2y$, и кажется там еще доп символы.

[Adamos]

Кирилл Красин, а еще он, начиная с PHP 8, принудительно заново генерирует соль при каждом вызове, так что результат вы в таблице не найдете, не прогнав ее всю через password_verify.

[Кирилл Красин]

Adamos, это я знаю.

if (password_verify($_POST['pw'], $u['pw'])) {
    if (password_needs_rehash($u['pw'], PASSWORD_DEFAULT)) {
        $reHash = password_hash($_POST['pw'], PASSWORD_DEFAULT);
        $stmt = pdo()->prepare('UPDATE `tbl` SET `pw` = :password WHERE `uname` = :username');
        $stmt->execute([
            'username' => $_POST['u'],
            'password' => $reHash,
        ]);
    }
    $_SESSION['uid'] = $u['id'];
    die;
}

[mayton2019]

Не спец в PHP, но если тебе надо усилить хеш-функцию - ты можешь сделать композицию из двух.

$data = "[e-mail]";
$hash = sha1($data) + md5($data);

По формуле вероятностей тут будет произведение верятности коллизии sha1 и md5 на твоем объеме данных.
Тоесть если раньше она была например 0.00000001 то в произведении будет соотвественно нулей после
зяпятой еще больше. И это уже - космос. Вероятнее тебя скушает акула чем такая коллизия выскочит.

[Adamos]

Кирилл Красин, не понял, к чему это здесь, просто повторюсь: для заявленных целей эти танцы в гамаке на хрен не нужны, md5 за глаза.

[Кирилл Красин]

mayton2019, да мне не усилить нужно, а захешировать так, чтобы доступа к данным не иметь, но при этом сверять хеш, с вводимыми данными при попытке восстановить доступ.

По факту мне в базе email пользователя вообще не нужен. Но пока не могу сообразить как при этом секурно иметь возможность пользователю сбросить пароль без него.

[szQocks]

Кирилл Красин, если будешь хэшировать почту в бд, то можешь забыть о рассылке

[Кирилл Красин]

szQocks, это и не нужно. Как написано в вопросе, почта для двух сценариев:

— Для отправки письма при регистрации (письмо формируется ДО внесения в БД, на этом этапе проблем нет).
— Для восстановления доступа к учетной записи.

[Dmitry Bay]

Кирилл Красин,
В данном случае, с вашей стороны - не сможете.

Но, со стороны клиента, в момент запроса, сверить ваш md5, и если есть в базе - то у вас есть ид пользователя и его емайл. Добавьте туда hash поле для идентификатора восстановления (или через отдельную таблицу).
И восстанавливайте доступ клиенту.

[szQocks]

Кирилл Красин, для регистрации и восстановления, хэшировать почту для генерации ссылки - тоже как вариант, но не для чего-либо другого, если это устраивает - хэшируй

но в целом сама почта в бд так же должна храниться и не захешированной, для каких-либо других целей

хотя по факту для создания ссылок, можно хэшировать и не почту, а просто генерировать какой-либо uuid

[mayton2019]

Кирилл Красин, я думаю что хеширование на 100% закрывает все вопросы к тебе со стороны аудита.
Технические нюасны типа - а можно ли полным перебором по словарю имен найти емеил
и хеш - не будут звучать в повестке проверяющих органов.

Они попросят логи. Ты покажешь им что в логах никакого емейла нет. И на этом все.

Вопрос исчерпан.

[Кирилл Красин]

szQocks,

но в целом сама почта в бд так же должна храниться и не захешированной, для каких-либо других целей

В том-то и дело, я хочу избежать хранения персональных данных вообще. email попадает под категорию Общих персональных данных. Чтобы согласно 152-ФЗ вообще не парится насчёт оформления политики конфиденциальности, не касаться РКН и не регистрироваться оператором персональных данных.

https://vc.ru/legal/497180
https://texterra.ru/blog/komu-nuzhna-politika-konf...

[Виталий Артемьев]

Для чего хешировать? Как вы собираетесь потом получать оригинальный email?

[szQocks]

Кирилл Красин, там штраф то копеечный, тем более тут простая почта, запариться проще с политикой чем с этим дерьмом с хешами почты ( скорее всего это аукнется в будущем, хэширование почты )

[Кирилл Красин]

Виталий Артемьев, Выше описал для чего. Оригинальный email мне не нужен.

[szQocks]

Кирилл Красин, оригинальный емейл нужен, раз по почте восстанавливать собираешься и регать юзера, это как одеть носки не имея носков

[Дмитрий]

szQocks, да зачем ему оригинал? Пользователь пищит почту на которую забыл пароль, ты же хэшируешь и делаешь запрос в базу. Да есть такой товарищ, вот тебе письмо на мыло. Если солить, то фокус не удастся, так же ведь пароль проверяется

[Кирилл Красин]

Я видимо сам себя перемудрил. Как писали выше, просто прогнал через md5, хеш сохранил в бд, на введённый в input email отправил письмо с подтверждением регистрации.
На странице сброса пароля, тоже, взял из input email, прогнал через md5, сверил наличие в БД, если есть - отправил на почту из input письмо с ссылкой на сброс.

В итоге оригинальный email нигде кроме страницы регистрации и сброса пароля не используется, в базе данных его нет.

По факту сам себе нагородил проблему)

Благодарю за дискуссию и ответы. Adamos , szQocks , Дмитрий

[Adamos]

Кирилл Красин, вы таки будете смеяться, но хэш от почты все равно подпадает под определение ФЗ "любая информация, относящаяся к прямо или косвенно определенному или определяемому физическому лицу".
Согласно ст. 3 п. 9 того ФЗ можно считать такие данные обезличенными. Однако засада в том, что никаких послаблений насчет хранения обезличенных данных ФЗ, насколько я вижу, не предусматривает.

[Кирилл Красин]

Adamos, там есть такой нюанс, это да. Но еще мне интересно вот это:

обезличивание персональных данных - действия, в результате которых становится невозможным без использования дополнительной информации определить принадлежность персональных данных конкретному субъекту персональных данных;

А именно про дополнительную информацию. Что попадает под определение доп. информации с помощью которой можно засшифровать хеш.

[Adamos]

Кирилл Красин, это определение говорит про дополнительную информацию, необходимую для того, чтобы сопоставить данные персоне, а не о каких бы то ни было расшифровках.
У вас хэш привязан к аккаунту, а значит - и к пользователю, но без знания конкретной почты нельзя определить, к какому.

[Кирилл Красин]

Adamos, я возможно не совсем понимаю трактовку, или вас) В базе хранится рандомный числовой ID, хеш пароля, хеш email, логин (указанный пользователем). Как на основании этого можно идентифицировать человека, или хотя бы узнать еmail для данного пользователя.

[Дмитрий]

Кирилл Красин, узнать нельзя, но посмотреть есть ли пользователь с таким мылом можно, причём прям на форме регистрации, почта занята, возможно вы хотите востановить пароль

[Кирилл Красин]

Дмитрий, в таком случае пожалуй просто буду генерировать ключ восстановления, отправлять его на мыло и писать в БД. И восстанавливать доступ проверкой связки логин/ключ.

[Adamos]

Кирилл Красин, это же не айти, это же юриспруденция.
Такая информация, как "Кирилл Красин", внезапно, тоже отнюдь не позволяет идентифицировать человека.
А вот нагнуть человека (который посмел хранить эту архиважную персональную информацию) - позволяет.
(а если очень захотеть - то и меня, посмевшего ее обработать...)