[Anthony]

Scroll, скорее метафора но расти она будет существенно. за день где-то 300-400 записей

[kost]

Сообщение от Anthony

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

Через MD5 можно было б передавать, но:
1) нам надо было б сначала весь результат запроса по таблице вытащить в массив несколько сот записей и прогнать этот массив на совпадения с MD5 через isset. Не самый хороший вариант, согласитесь.

Запишите md5-хэш в базу и ищите по нему.

[Nielson]

SELECT filed FROM database WHERE md5key='ТУТ ИДЁТ $_GET[хэш]'
По-моему, база в данном случае нисколько не нагружается.

[deMone]

Особенно если есть ключ на md5key.

[Nielson]

deMone, не понял

[Anthony]

Nielson, спасибо. Не знал что так можно в Sql

[Асмодиан]

А при чём тут SQL
Вся фича в том, что мы всё время работаем непосредственно с хешем.
То есть у нас есть исходные данные. Мы их шифруем md5, sha1,...
И вот с этого момента мы про исходные данные забываем нафик.
Результат помещаем в БД, его-же и отправляем пользователю как подтверждающий код. И после этого сравниваем хэши.

То что написал Nielson - md5key - это не супернавороченномощная функция MySQL, а поле в таблице, в которое мы и разместили наш фигов хэш.

Например именно таким образом храняться пароли в большинстве CMS и прочих движках. Даже если злоумышленник и взломает CMS, то он хотябы не узнает пароли пользователей, которые у многих людей едины на всё что можно. В Таблицах храняться лишь хэши паролей.
И что вы думаете происходит, когда вы пытаетесь войти в CMS?
Правильно, из пароля делается хэш и сравнивается по базе!!! Уже хэш, а не пароль.

Таже зачастую используется суперфича под названием уникальный префикс.
Где-то в конфиге вы записываете строку из 6-10 знаков (на самом деле неважно какую) и вместо
md5($encdata) // где $encdata это наш пароль или ещё что
пишите md5($prefix . $encdata) // где префикс и есть наша вышеупомянутая строчка

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

PS. Я слышал, что в sha недавно обнаружили уязвимость... Но в md5 её обнаружили уже давно... так что даже если покопаться в исходниках joomla, то увидите, что раньше шифрование осуществлялось md5, теперь sha

[deMone]

Nielson, ну, индекс.

[Anthony]

Makarenya, абсолютно согласен. Спасибо за подробное объяснение.

Но это когда касается паролей. И, скажем, наиболее простой путь к шифрованию.
Но существуют ситуации, когда требуется зашифровать обычный get: ?id=1&val=50|40|22|14. Собственно как у меня сейчас.
И смысл для каждого поля писать свой хеш. Это не пароль - а просто число, которое нужно зашифровать, чтобы нельзя было ввести другое число.

Таких таблиц много. И получается нужно для каждой хранить еще поле для хеша. А где-же простота и ненагруженность БД?

И все-таки - почему нельзя использовать crypt. Для чего тогда нужна эта функция? На мой взгляд гораздо безопаснее делать через нее. Там больше методов шифрования и меньше возможностей у взломщиков.

[Nielson]

deMone, ну да.


Anthony, складывается впечатление, что твой скрипт просто не выдерживает никакой критики относительно безопасности и правильности кода если ты так горишь идеей зашифровать строку.