Насколько безопасно хранить криптографический хэш конфиденциальной информации?

Question

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

Однако дата рождения и SSN не изменяются. Я думаю о хранении комбинации date_of_birth-ssn в качестве криптографического хеша, чтобы однозначно идентифицировать контакт и объединять дубликаты.

Мое понимание заключается в том, что математически «невозможно» изменить хеш, поэтому «безопасно» хранить ssn таким образом.

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

Есть ли лучшее решение для однозначной идентификации людей, которые не использовали бы конфиденциальную информацию, такую ​​как ssn?

Answer 1

Это решительно не сейф.

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

С 365 днями в году и всем, кому не исполнилось 100 лет, существует только около 36500 возможных DoB (хорошо, некоторым людям более 100, но не вашим контактам - фактическое количество возможных DoB, вероятно, составляет около 20 000). SSN составляет 9 цифр, поэтому только 1 000 000 000 возможных значений (на самом деле намного меньше).

Все сказали, что возможны 20 000 000 000 000 возможных комбинаций. Звучит как много? Это не. Этот ноутбук, который я использую, может выполнять более 11 миллионов хэшей в секунду на ядро. Он может тестировать все возможные комбинации за 1 707 026 секунд или 19 дней. С одним 4-летним ядром ноутбука. Мощный сервер с 20 ядрами, который стоит несколько тысяч долларов (без специализированного оборудования), может подготовить эту таблицу в часах. И тогда я могу изменить не хеш-функцию, а подмножество выходов, которое вы можете увидеть.