Считая сначала md5, затем crc32, вы, по моему мнению,
увеличиваете вероятность коллизии. Коллизия может возникнуть в функции md5 (одинаковые значения для разных входных данных), что сразу приведет к коллизии на выходе crc32 (одинаковые значения для одинаковых входных данных). Кроме того, коллизия может возникнуть в функции crc32b (одинаковые значения на выходе для двух разных результатов md5). Не знаю, как работает функция md5 в php, но мне представляется, что ее вывод имеет некую структуру (32 шестнадцатеричные цифры), что
может увеличить вероятность коллизии crc32b.
Зачем использую crc32b? Чтобы ссылки были как можно короче - для использования в смс-рассылке.
На вашем месте, если нужен детерминизм, я бы:
1) использовал хэш-функции из семейства SHA-2 (SHA-256,SHA-512).
2) использовал бы N последних бит (например, 48, сложность подбора заданного хэша в среднем 2^48 попыток, сложность нахождения двух произвольных пользователей с совпадаюшими хэшми, как отметил
@eandr_67 в комментарии, значительно меньше, 2^24 попыток в среднем, в силу квадратичного количества пар)
3) транслировал бы эти 48 бит в 8 символов 64-символьного алфавита (латинские буквы в обоих регистрах + цифры + 2 символа)
4) использовал бы полученную 8-символьную строку
Пункты 2,3,4 можно подогнать под ваши специфические требования.
UPD:При изменении статусов заказа эти ссылки приходят клиенту на емейл/смс - поэтому будет не очень хорошо если ссылка каждый раз разная будет (таким образом клиент не сможет зайти в кабинет по ссылке из прошлого письма).
Во-первых, непонятно, почему отслеживаются заказы, а хэш вы считаете от товара. Сегодня, например, клиент заказывает один товар одновременно, а завтра, когда концепция поменяется - два и более. Более логичным представляется отслеживание заказов (примерные характеристики заказа - номер телефона/email пользователя, список товаров, срок и адрес доставки и прочая).
Далее, непонятно, почему решено использовать хэширование. Я предполагаю, что проблем с хранением данных нет. Почему бы не хранить вместе с данными заказа соответствующую ему 'секретную' ссылку, сгенерированную при помощи ГПСЧ?
Далее, если вы планируете использовать короткую ссылку в смс, то имеет смысл использовать для ее составления специализированный алфавит, отобрав из набора a-z,A-Z,0-9 наиболее удобные в плане UX. Например, буквы
I и
l бывают трудноразличимы. Здесь важно также максимизировать мощность множества возможных значений строки-ссылки (равное A^l, где A - количество символов в алфавите, l - длина строки-ссылки). В случае 32 символов в алфавите и 8 символов в строке получаем 2^40 вариантов, сложность нахождения пары пользователей с совпадающими ссылками в среднем 2^20 попыток (вероятности релевантных коллизий, соответственно, обратны этим значениям).
Далее, можно разделить функциональность страницы заказа, при простом доступе по ссылке показывать только статус/общую информацию, а важные действия (отменить заказ, изменить адрес, и т.д.) разрешать после прохождения дополнительной проверки (например, на известный номер телефона/e-mail клиента пересылается короткоживущий секрет, который должен быть введен на странице для продолжения).
Такие мысли.
