Контрольная сумма для SSN

Question

У меня есть проект, который требует проверки на внешнем интерфейсе для американского номера социального страхования (формат ddd-dd-dddd). Одним из предложений будет использование алгоритма хеширования, но, учитывая небольшой набор символов ([0-9]), это будет иметь катастрофические последствия. Было бы приемлемо с некоторой высокой вероятностью проверить правильность числа и позволить бэкэнду выполнить окончательную проверку ==, но мне нужно сделать это намного лучше, чем "имеет девять цифр" и т. Д.

В поисках лучших альтернатив я наткнулся на контрольные суммы проверки для номеров ISBN и UPC . Они выглядят как отличная альтернатива с высокой вероятностью успеха на фронтенде.

Учитывая эти ограничения, у меня есть три вопроса:

1. Есть ли способ доказать, что алгоритм, такой как ISBN13, будет работать с другой категорией данных, такой как SSN, или он более или менее соответствует цели с точки зрения безопасности? Контрольная сумма кажется разумной для моей довольно большой выборки одного реального SSN, но я бы не хотел узнать, что они по какой-то причине неприменимы.
2. Является ли это где-то решенной проблемой, так что я могу просто использовать существующую схему проверки для решения проблемы?
3. Существуют ли какие-либо такие алгоритмы, которые также могли бы с легкостью приспособиться к проверке последних 4 цифр SSN, не предоставляя слишком много дополнительной информации?

Спасибо, как всегда, Джо

---

UPDATE:

В ответ на вопрос ниже немного подробнее. У меня есть введенный ранее SSN клиента, который надежно хранится на сервере приложения. Что мне нужно сделать, так это проверить (в максимально возможной степени), что клиент снова ввел то же самое значение на этой странице. Проблема заключается в том, что мне нужно предотвратить случайное раскрытие информации интерфейсу в случае, если какой-то посторонний человек сможет получить доступ к странице.

Именно поэтому хеш MD5 / SHA1 не подходит, а именно: его можно использовать для получения полного SSN без особых затруднений. Контрольная сумма (скажем, по модулю 11) почти не предоставляет информации внешнему интерфейсу, в то же время обеспечивая высокую степень точности для проверки поля. Однако, как указано выше, у меня есть сомнения по поводу его общего применения.

Answer 1

Википедия не лучший источник для подобных вещей, но, учитывая это предостережение, http://en.wikipedia.org/wiki/Social_Security_number говорит

В отличие от многих похожих чисел, контрольная цифра не включена.

Но перед этим упоминаются некоторые широко используемые фильтры:

SSA публикует последний номер группы, использованный для каждого номера области.Так как номера групп назначаются в обычном (если необычный) шаблон, можно идентифицировать невыданный SSN, который содержит недопустимый номер группы.Несмотря на эти меры, многие мошеннические SSN не могут быть легко обнаружены с использованием только общедоступной информации.Для этого существует множество онлайн-сервисов, которые предоставляют проверку SSN.

Answer 2

Простое решение.Возьмите номер мод 100001 в качестве контрольной суммы.Существует 1 / 100_000 вероятность того, что вы случайно получите правильную контрольную сумму с неправильным номером (и она будет очень устойчива к устранению ошибок из одной или двух цифр), и 10000 возможных SSN, которые могут быть, чтобы вы не раскрылиSSN для атакующего.

Единственным недостатком является то, что легко определить 10 000 возможных других SSN.Если человек может получить последние 4 из SSN из другого места, то они, вероятно, могут выяснить SSN.Если вас это беспокоит, вы должны взять номер SSN пользователя, добавить соль и хэшировать его.И намеренно используйте дорогой алгоритм хеширования для этого.(Вы можете просто перебрать более дешевый алгоритм, такой как MD5, фиксированное число раз, чтобы увеличить стоимость.) Затем используйте только определенное количество бит.Дело в том, что, хотя кто-то может пройти через все миллионы возможных SSN, чтобы получить ограниченный список возможностей, это будет стоить им дороже.Надеюсь, что они не потрудятся.

Answer 3

Восстановление базовых требований:

• Достаточно сильная контрольная сумма для защиты от простых человеческих ошибок.
• "Ожидаемая" контрольная сумма отправляется с сервера -> клиент, что позволяет клиентской сторонепроверка.
• Контрольная сумма не должна раскрывать слишком много информации о SSN, чтобы минимизировать утечку конфиденциальной информации.

Я мог бы предложить использовать криптографическое значение (SHA-1 и т. д.), но не отправляет полное значение хеша клиенту.Например, отправьте только младшие 4 бита из 160-битного результата хеширования [1].Отправив 4 бита контрольной суммы, вы сможете обнаружить ошибку ввода данных 15/16 - это означает, что вы будете обнаруживать ошибки в 93% случаев.Обратная сторона, однако, заключается в том, что вы «просочились» достаточно информации, чтобы уменьшить их SSN до 1/16 пространства поиска.Вы сами решаете, стоит ли эта утечка удобства на стороне клиента.

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

Наконец, учитывая ваши требования, я подозреваю, что этот компромисс между удобством и утечкой является неотъемлемой проблемой: конечно, вы могли бы использовать более сложный алгоритм крипто-вызова / ответа (как подсказывает Ник ODell).Однако для этого потребуется отдельный запрос туда-обратно - то, что, как вы сказали, вы пытались избежать в первую очередь.

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