По результатам чтения вот этого:
http://habrahabr.ru/blogs/infosecurity/130965/Вот смотрите... Если хэшировать данные напрямую, то, на примере номера свидетельства пенсионного страхования (СНИЛС) мы имеем 11 цифр. Фактически мы имеем 9 цифр, т.к. 2 из них - контрольный номер. Таким образом, подбор нужного значения по имеющемуся хэшу является вполне реальным. Что нежелательно.
ИНН имеет 12 знаков, 3 из которых относительно предсказуемы (обозначают регион). Т.е., фактически, тоже 9 знаков. Минус ИНН в том, что его нужно получать в налоговой.
Однако, хэширование объединенной строки СНИЛС+ИНН дало-бы уже достаточно сильную защиту от перебора.
Я прикидывал как можно использовать номер паспорта или другого идентифицирующего документа в этой системе... В принципе, возможно. Даже если такой номер меняется, старые данные в ключе остаются и все-равно выполняют роль защиты от дублирования. Просто добавляется еще один идентификатор для такой защиты.
Например, можно использовать связку "Номер паспорта"+"СНИЛС". Тогда мы получаем, если не брать в расчет серию паспорта, 6+9=15 цифровых позиций. В общем-то не очень хорошо (на перебор всех вариантов по оценкам из статьи нужно будет 11 дней), но тем не менее. Кроме того, тут-же можно использовать еще и номер свидетельства о рождении. Тогда, в комбинации "Свидетельство о рождении"+"Паспорт"+"СНИЛС" защита от перебора будет вполне достойной.
Вход
FAQ
Поиск
Номер свидетельства о рождении показывать вроде-бы безопасно. Но нам нужен какой-то единообразный способ идентификации. Поэтому предлагаю все-таки все это в хэш пихать. А уж субъекты сами введут данные которые требуется для них открывать. Причем, думаю, номер свидетельства о рождении и социальный идентификатор открывать они не смогут (естественно на уровне рекомендации). Это нужно для того, что-бы при открытии части данных из хэша не было возможности легко вычислить остальные данные.