Скрытие истинного идентификатора объекта базы данных в url's

Что было бы полезным решением для скрытия истинного идентификатора объекта базы данных в URL-адресе для целей безопасности? Я обнаружил, что одним из решений будет:

1) Использование проекта хешидов с открытым исходным кодом

2) Используя что-то вроде того же старого md5 при создании объекта для генерации хеша и храните его в базе данных, затем используйте его в url и запросите их, но недостатком является то, что запрос с помощью первичных ключей с автоматической природой (ID) выполняется быстрее, чем хэши. Поэтому я считаю, что возможность хэша / дежурства будет лучше?

Кроме того, как я нахожусь на Symfony, есть ли, возможно, пакеты, которые я не мог найти или построить в функциях, которые могли бы помочь?

Скажите, пожалуйста, что вы нашли полезным на основе вашего опыта.

Этот вопрос был задан очень часто, с другим выбором слова (что затрудняет говорить «Просто ищите его!»). Этот факт вызвал сообщение в блоге под названием «Всеобъемлющее руководство по шифрованию URL-адресов в PHP» .

Что хотят делать люди

Некоторая функция шифрования используется для детерминированного извлечения идентификатора

Что люди должны делать вместо этого

Использовать отдельный столбец

объяснение

Как правило, людям нужны короткие случайные URL-адреса. Это не позволяет вам много места для шифрования, а затем аутентифицировать идентификатор записи базы данных, который вы хотите запутать. Для этого потребуется минимальная длина URL-адреса 32 байта (для HMAC-SHA256), которая составляет 44 символа при кодировании в base64.

Более простая стратегия – создать случайную строку (см. Random_compat для реализации PHP5 random_bytes() и random_int() для генерации этих строк) и вместо этого ссылаться на этот столбец.

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

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

Не полагайтесь на это.

Цитата с сайта:

У вас есть вопрос или комментарий, который включает в себя «безопасность» и «хешиды» в том же предложении? Не используйте Hashids.

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

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

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

Если вам нужна только защита от неизвестности, которой достаточно, может быть, 99% любопытных людей, которым нравится перебирать идентификаторы в URL-адресах, вы используете что-то простое, например base64 или rot13. Конечно, вы также можете предварительно вычислить эти «общедоступные идентификаторы» и сохранить в базе данных, а не шифровать каждый раз, когда URL-адрес отображается конечным пользователям.
Если вам нужна настоящая безопасность, вы должны зашифровать их каким-то серьезным асимметричным шифром, сохраняя оба ключа на вашей стороне, поскольку вы, по сути, разговариваете с самим собой и не хотите атаки «человек в середине». Этого вы не сможете предсказать, поскольку при каждом шифровании будет другой cyphertext, что хорошо для этой причины.

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

EDIT: Но решение, которое каждый блог использует для этой задачи уже несколько лет, – это просто использовать URL-переписывание, преобразование в вашем случае URL-адресов, таких как http://example.com/book/5 в URL-адреса, такие как http://example.com/rework-by-37signals . Это полностью уничтожит любые значки идентификатора базы данных из вашего URL-адреса.

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