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

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

Я рекомендую вам использовать соль, а также вычислить второе значение, которое будет добавлено к соли, на основе формулы, включающей каждую цифру номера карты и первое значение соли. Это гарантирует, что если вы потеряете контроль над какой-либо частью, у вас все еще будет разумная уникальность, которая сделает владение списком бесполезным. Формула не должна быть сильно привязана к первым 6 цифрам карты (номеру BIN), однако, 9-значный номер счета
Однозначные списки контрольных сумм Luhn

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

Visa - начинается с 4
American Express - начинается с 34/37
MasterCard - начинается с 5
Discover / CUP - начинается с 6
Diner's Club - от 35 человек
и т. д.

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

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

Вооруженный горсткой BIN, на которую стоит обратить внимание, злоумышленник должен проверять 9 цифр за раз для каждого набора BIN. Это 1 миллиард контрольных сумм и хеш-операций на набор. У меня нет удобных тестов, но я m почти уверен, что 1 миллион операций хеширования в минуту не является необоснованным для MD5 или любого другого варианта SHA на достаточно мощной машине. На взлом всех совпадений в заданном BIN уходит меньше суток.

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

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

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

Используйте SHA1, хеш-коллизии пока не обнаружены.

Если вы обнаруживаете коллизии с MD5, почему бы не использовать лучший алгоритм, такой как SHA1 или SHA256 ?

MD5 НЕ подходит, поскольку он сломан. Цитата Брюса Шнайера: «[мы] мы уже знали, что MD5 - это неработающая хеш-функция» и что «никто больше не должен использовать MD5».

Т.е. используйте SHA512 или SHA256, как кто-то уже предложил.

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

Лично мне нравится Whirlpool - если вы используете PHP, проверьте поддерживаемые алгоритмы в документах хэш-функций.

Whirlpool возвращает строку длиной 128 символов, но вам необязательно хранить ее всю. Первые 32 или 64 символа будут достаточно. Вы также можете рассмотреть sha512 или sha284.

As Henri already mentioned above (+1), the right solution is to use Message Authentication Code such as HMAC with a secret key. This is exactly the "secret salt" someone mentioned before. (BTW. Salts are always public).

Use standard construction such as HMAC-SHA-256 (RFC2104, FIPS-198a), keep the key secret and store the results (authentication tags) in a database.

The larger digest size (256 bits) of SHA-256 should prevent any collisions from happening, SHA-256 is a fairly good hash function and probability of random collisions is 2^-128, so if you ever encounter a collision in your system, please, let me know! :)

Dont bother doing salts, just use HMACs. I know it's kind of an abuse, but then you get a decent keyed hash, so you can prevent collisions and rainbow table attacks.

The nice thing here is that even if the key leaks, nobody can decrypt it. The best thing that works for HMACs is brute force. Actually, the key here is a salt as mentioned earlier. The nice thing here is that the algorithm is a little better than the usual salting stuff done by most non-security programmers.

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

Это «ломает» хеш, но только для конкретной цели использования хеша для проверять данные - это то, чем они должны быть.

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

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

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

Учитывая, что соль должна быть доступна приложению, чтобы оно могло выполнять проверки по черному списку, есть большая вероятность, что кто-то скомпрометирует данные черного списка также сможет добраться до соли. Если у вас несколько серверов, вы можете в некоторой степени смягчить это, убедившись, что и соль, и данные не хранятся. t в одном и том же «месте», поэтому доступ к одному серверу не даст кому-то всех необходимых частей. (Точно так же для резервных копий не храните данные и соль на одном носителе, где кто-то может уйти с одной лентой и получить все). Соль только добавляет некоторую защиту, пока она является секретной (в этом типе использования).

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

t хранить данные и соль на одном носителе, где кто-то может уйти с одной лентой и получить все). Соль только добавляет некоторую защиту, пока она является секретной (в этом типе использования).

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

t хранить данные и соль на одном носителе, где кто-то может уйти с одной лентой и получить все). Соль только добавляет некоторую защиту, пока она является секретной (в этом типе использования).

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

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

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