Есть ли алгоритм хеширования, который позволяет мне указать длину выходного символа?

Question

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

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

Answer 1

Будьте осторожны, когда вы обрабатываете номера кредитных карт!

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

Это напрашивается на неприятности рано или поздно ...

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

Answer 2

Если ваш ввод представляет собой 20-значное число, то существует 10 ²⁰ возможных вводов.
Если ваш вывод представляет собой 12-символьную буквенно-цифровую строку, то существует 62 ¹² возможных выходных данных.

Входы:

100000000000000000000

Выходы:

3226266762397899821056

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

Итак, мы просто будем использовать более короткий хэш!

В чем смысл? Просто используйте целое, случайное, если нужно.

---

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

Это работает, потому что:

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

И почему так? Ну, пароль, который я использовал, мог быть длиной 1000000 символов. Как ты собираешься понять это из короткого хэша? Ты не можешь Вы можете только попытаться подсчитать как можно больше хэшей, сравнить их с тем, который у вас есть, и надеяться на совпадение. В этом случае обычно даже не актуально находить фактический исходный ввод, так как любой ввод, который выдает тот же хеш, будет работать.

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

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

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

Answer 3

Игнорируя все вышеперечисленные вопросы, есть действительно, действительно, ослепительно простое решение.

В псевдокоде:

function my_hash(string data, int length){
    string t = md5sum(data);
    return t.substring(0,length)
}

Или сумма sha512 или что-то, что поражает ваше воображение. Лично я рекомендую несколько раундов раздува. Если кто-то захватывает базу данных и знает, как вы создали этот хеш, он может просто пробежаться по пространству всех номеров CC и сравнить данные, чтобы изменить его. Это плохо

Однако будьте осторожны. Прочитайте все остальные ответы, все они имеют очень веские моменты.

Answer 4

У продавца не должно быть никаких причин хранить полный номер кредитной карты, хэшированный или нет.

Я думаю, вам действительно нужно оценить, почему вам нужно это сделать.

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

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