Хранение адресов электронной почты анонимно

Question

Я запускаю службу, где пользователи могут войти в систему, но мне никогда не понадобится отправлять им электронные письма.Я стараюсь сохранить пользовательские данные как можно более анонимными.Я не заинтересован в отслеживании пользователей, продаже данных и т. Д. Я знаю, что для этого вопроса будут более простые решения, такие как «не использовать адреса электронной почты в первую очередь», но они делают хороший идентификатор входа в систему, потому что они являются GUID.,Мой сервис проходит через процесс, когда пользователь проверяет адрес, это единственное письмо, которое я когда-либо отправляю.

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

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

Хотя я обеспокоен тем, что это все еще уязвимо для радужных столов.Этих 5 символов достаточно для поиска возможных входных данных, и злоумышленник уже знает, что действительными будут только входные данные, похожие на адреса электронной почты.У них все еще было бы достаточно, чтобы определить адрес электронной почты, учитывая первую часть несоленного хеша и весь соленый хеш.

Хотя я слишком обдумываю это?Для записи, я использую pgsql и php в этом случае, но это на самом деле подробности реализации.

Обновление : я все еще не уверен, собираюсь ли я идти впередс этим, но для любого любопытного, проблема с радужными таблицами здесь может быть решена довольно легко.Вместо того, чтобы хэшировать всю электронную почту и брать первые несколько символов хеша, используйте первые несколько символов электронной почты в качестве ввода хеша и сохраните весь хэш.Он достигает того же эффекта, но в лучшем случае радужный стол покажет только первые несколько символов.

Answer 1

Я думаю, вы думаете об этом.Вы заявили, что вам не нужно отправлять электронное письмо пользователям в будущем, поэтому мой вопрос к вам: зачем вам вообще хранить электронную почту?Вы упоминаете, что это хороший GUID, но если вы обеспокоены безопасностью данных, не будет ли проще позволить пользователям определять имя пользователя при проверке электронной почты?

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

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

Все это говорит о том, что я не думаю, что это необходимо.Как вы сказали, электронная почта - это отличный GUID.Что делает его отличным GUID, так это то, что он так широко известен и доступен.Риски, связанные с выпуском открытого текста, намного меньше и менее опасны, чем риски, связанные с открытым текстом.Я считаю, что наше время как разработчиков лучше оставить для защиты личных данных, а не общедоступных данных.

Answer 2

Мне кажется, что да.Вы упускаете из видуНезависимо от того, насколько сильна ваша структура, всегда есть небольшой шанс нарушения, потому что никто не совершенен и не может быть сценарием, созданным человеком.Я думаю, вам следует выбрать лучший вариант, который вам нужен, и затем придерживаться его.

Некоторые вещи лучше оставить на произвол судьбы.

Удачи