Лучший способ предотвратить дублирующееся использование кредитных карт

Почти хорошая идея.

Хранение просто хеш является хорошей идеей, это служило в мире пароля в течение многих десятилетий.

Добавление соли кажется как справедливая идея и действительно делает атаку перебором что намного тяжелее для взломщика. Но та соль собирается стоить Вам большого дополнительного усилия, когда Вы на самом деле проверяете, чтобы гарантировать, что новый CC уникален: у Вас будут к SHA-1 свои новые времена CC номер N, где N является количеством солей, Вы уже использовали для всего CCS, с которым Вы сравниваете его. Действительно при выборе хороших случайных солей, необходимо будет сделать хеш для любой карты в системе. Таким образом, теперь это - Вы делающий грубую силу. Таким образом, я сказал бы, что это не масштабируемое решение.

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

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

Люди по размышлению дизайна этого, я думаю. Используйте соленое, очень безопасное (например, "в вычислительном отношении дорогой") хеш как sha-256 с уникальной солью на запись.

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

Шаг 1:

Ищут соответствия к последним 4 цифрам (и возможно также дата экспорта, хотя существует некоторая тонкость там, которой, возможно, понадобится обращение).

Шаг 2:

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

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

Sha1 , поврежденный , не является проблемой здесь. Все поврежденное средство состоит в том, что возможно вычислить коллизии (2 набора данных, которые имеют тот же sha1), более легко, чем Вы ожидали бы. Это могло бы быть проблемой для принятия произвольных файлов на основе их sha1, но это не имеет никакого relevence для внутреннего приложения хеширования.

Давайте сделаем немного математики: Номера кредитных карт являются 16 цифрами долго. Первые семь цифр являются 'главной промышленностью' и числами выпускающего, и последняя цифра является luhn контрольной суммой. Это оставляет 8 цифр 'свободными', для в общей сложности 100 000 000 номеров аккаунта, умноженных на количество потенциальных чисел выпускающего (который вряд ли будет очень высок). Существуют реализации, которые могут сделать миллионы хешей в секунду на повседневных аппаратных средствах, поэтому какое соление Вы делаете, это не будет грандиозным предприятием к грубой силе.

По чистому совпадению, при поиске чего-то дающего сравнительные тесты хеш-алгоритма, я нашел эта статья о хранении хешей кредитной карты , который говорит:

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

...

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

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

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

SHA1 поврежден . Курс, нет большой информации о том, какова хорошая замена. SHA2?

При объединении последних 4 цифр номера карты с именем держателя карты (или просто фамилия) и дата истечения срока, у Вас должно быть достаточно информации для создания записи уникальной. Хеширование хорошо для безопасности, но разве Вы не должны были бы хранить/вспоминать соль для тиражирования хеша для дублирующейся проверки?

Соленый хеш должен работать просто великолепно. Наличие системы соленой в расчете на пользователя должно быть большим количеством безопасности.

Да, сравнение хешей должно хорошо работать в этом случае.

@Cory R. Король

SHA 1 не повреждается по сути. То, что показывает статья, - то, что возможно генерировать 2 строки, которые имеют то же значение хэш-функции в меньше, чем время грубой силы. Вы все еще не можете генерировать строку, которая приравнивается к ОПРЕДЕЛЕННОМУ хешу за разумное количество времени. Между двумя существует большая разница.

PCI DSS указывает, что можно сохранить ПАНОРАМИРОВАНИЯ (номера кредитных карт) с помощью сильного одностороннего хэша. Они даже не требуют, чтобы это посолилось. Это сказало, что необходимо посолить его с уникальным на значение карты. Дата окончания срока действия является хорошим началом, но возможно немного слишком короткий. Вы могли добавить в других сведениях от карты, таких как выпускающий. Вы не должны использовать число CVV/security, поскольку Нельзя сохранить его. При использовании даты окончания срока действия затем, когда держатель карты будет выпущен новая карта с тем же числом, это рассчитает как другая карта. Это могло быть хорошей или плохой вещью в зависимости от Ваших требований.

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

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

Сравнение хешей является хорошим решением. Удостоверьтесь, что Вы только солите все номера кредитных карт с той же постоянной солью, все же. Используйте другую соль (как дата истечения срока) на каждой карте. Это должно сделать Вас довольно непроницаемыми для атак с подбором по словарю.

От эта статья Coding Horror:

Добавляют длинную, уникальную случайную соль к каждому паролю, который Вы храните. Точка соли (или данный случай, если Вы предпочитаете) должна сделать каждый пароль уникальным и достаточно длинным, что атаки перебором являются пустой тратой времени. Так, пароль пользователя, вместо того, чтобы быть сохраненным как хеш "myspace1", заканчивает тем, что был сохранен как хеш 128 символов случайной строки unicode + "myspace1". Вы теперь абсолютно неуязвимы для нападения таблицы радуги.

Не не хранить простой SHA-1 номера кредитной карты, это было бы способом легко взломать (тем более, что последние 4 цифры известны). У нас была такая же проблема в моей компании: вот как мы ее решили.

Первое решение

1. Для каждой кредитной карты мы сохраняем последние 4 цифры, дату истечения срока действия, длинную случайную соль (длиной 50 байтов), и соленый хеш номера CC. Мы используем хэш-алгоритм bcrypt, потому что он очень безопасен и может быть настроен так, чтобы загружать процессор по вашему желанию. Мы сделали это очень дорогим (около 1 секунды на хэш на нашем сервере!). Но я думаю, вы могли бы использовать SHA-256 и повторять столько раз, сколько необходимо.
2. Когда вводится новый номер CC, мы начинаем с поиска всех существующих номеров CC, которые заканчиваются одинаковыми 4 цифрами и имеют одинаковый срок действия. Затем для каждой совпадающей CC мы проверяем, совпадает ли ее сохраненный соленый хеш с соленым хешем, вычисленным из ее соли и нового номера CC. Другими словами, мы проверяем, есть ли hash (stored_CC1_salt + CC2) == stored_CC1_hash .

Поскольку в нашей базе данных примерно 100 000 кредитных карт, нам нужно вычислить около 10 хэшей, поэтому мы получаем результат примерно через 10 секунд. В нашем случае это нормально, но вы можете немного настроить bcrypt. К сожалению, если вы это сделаете, это решение будет менее безопасным. С другой стороны, если вы настроите bcrypt на еще более интенсивную загрузку ЦП, потребуется больше времени для сопоставления номеров CC.

Хотя я считаю, что это решение лучше, чем простое хранение несоленого хеша номера CC, оно не помешает очень мотивированному пирату (которому удается получить копию базы данных) взламывают одну кредитную карту в среднем от 2 до 5 лет. Так что, если в вашей базе данных 100 000 кредитных карт, и если пират имеет много ЦП, то он может восстанавливать несколько номеров кредитных карт каждый день!

Это приводит меня к убеждению, что вы не должны вычислять хэш самостоятельно: вы должны делегировать это кому-то другому. Это второе решение (мы находимся в процессе перехода на это второе решение).

Второе решение

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

1. для каждой кредитной карты, вы просто сохраняете все, что хотите сохранить (например, последние 4 цифры и дату истечения срока действия) плюс псевдоним номера кредитной карты.
2. при вводе нового номера кредитной карты вы связываетесь со своим платежным провайдером и дайте ему номер CC (или вы перенаправляете клиента поставщику платежей, и он вводит номер CC прямо на веб-сайте поставщика платежей). Взамен вы получаете псевдоним кредитной карты! Вот и все. Конечно, вы должны убедиться, что ваш платежный провайдер предлагает эту опцию и что сгенерированный псевдоним действительно безопасен (например, убедитесь, что они не просто вычисляют SHA-1 для номера кредитной карты!). Теперь пират должен взломать вашу систему плюс систему вашего платежного провайдера, если он хочет восстановить номера кредитных карт.

Это просто, это быстро, это ' безопасен (ну, по крайней мере, если ваш платежный провайдер безопасен). Единственная проблема, которую я вижу, заключается в том, что это связывает вас с вашим провайдером платежей.

Надеюсь, это поможет.