Кодирование цифрового идентификатора

[Butylski]

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

ps: я так давно уже делаю. только шифрую немного по-другому

[dab512]

md5?

[Butylski]

нет. а обратно как расшифровывать? )) надо, чтобы обратимое шифрование было

[Apostol]

Как всё запущено...

$cookie += abs($crc32); // С чем складываем?
$cookie = decbin($cookie_id); // Зачем тогда нужна предыдущая строка и откуда взялось $cookie_id?
$cookie = str_pad($cookie_id, 32, '0', TR_PAD_LEFT); // То же самое
$cookie = strrev($cookie_id); // То же самое

$user_id = strrev($cookie_id); // Только по названиям функций можно догадаться,
$user_id = bindec($server_id); // что автор хотел выполнить обратные преобразования
$user_id -= abs($crc32); // Но ничего не работает!

Что мы получаем? А мы получаем бинарную строку в 32 символа

Мы получаем развёрнутую задом на перёд пустую строку. ;) Кстати, зачем нам так хотелось бинарную строку? Это нынче эффективнее, чем хеш, состоящий из шестнадцатеричных символов?

Алгоритм как угодно можно упрощать или усложнять, но в любом случае - если он не известен тому, кто хочет его раскодировать, то у него попросту ничего не получится.

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

$chr_num = (int)$_SERVER['REMOTE_ADDR'] % 30; // Это ужасно

[evilbloodydemon]

хы-хы, верно. книжки нужно почитать сначала (шнайера, например), а потом мастерить свои мегаалгоритмы.

[Juniorro]

Автор просто не хочет раскрывать свой алгоритм =)

[Apostol]

Или решил лёгким движением пера убрать всех конкурентов. :)

[zorba_buddha]

строка не пустая, у меня всё работает просто отлично как на серверах, так и на своей машине.

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

на счёт ужасно - обоснуйте или не говорите глупостей.

[Apostol]

Работает именно тот код, который вы привели? ;)

Из хеша данных и не надо получать. Хеш — это для надёжности и базопасности. Если вам это не так нужно, и решили хранить в браузере данные пользователя, то хотя бы придумали б более красивое решение. Например, можно было сериализовать массив с данными пользователя и выполнить сжатие. А чтоб бинарные данные нормально сохранились в куках — запаковать в base64. Вот оно, простое и элегантное решение:

$data=base64_encode(gzdeflate(serialize($data)));

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

[zorba_buddha]

при разборке сам идентификатор упустил.
исправил

[Apostol]

Я вас умоляю, изучите внимательно свой код. У вас 4 присваивания одной переменной. В итоге она будет иметь значение, установленное в последней строчке. Три предыдущих не влияют на результат.

$cookie = $user_id + abs($crc32);
$cookie = decbin($cookie_id);
$cookie = str_pad($cookie_id, 32, '0', TR_PAD_LEFT);
$cookie = strrev($cookie_id);

Зачем приводить код, который не работает?

[zorba_buddha]

заработался под утро то )))
в исправлениях запутался.

[quark]

Зачем это все?

[zorba_buddha]

шифрование открытых данных.

[false]

ох уж эти пхп-кодеры. вечно изобретут велосипед. это сказывается отсутствие своего фреймворка у пхп?

[proxor]

Сходу три могу назвать: ZF, CakePHP и Symfony.

[angelov]

Может я только вернулся и отвык от компа, но что-то с ходу не врубился что это и для чего? Не могли бы подробнее обьяснитЬ, а то я было подумал что мы шифруем от пользователя его же данные и их ему же зашифрованным посылаем

[angelov]

Теперь подозреваю что автор имел ввиду, статью заминисуют не из злости, а чтобы другие не читали и так не делали

[Butylski]

ты правильный блог админишь ;)

[angelov]

Ну соре, я работаю маляром штукотурщиком и эти закорючки для меня дремучий лес, просто интуиция подсказывает что так делать не надо и читать такое не надо

[Butylski]

ну если ничего не понимаете, зачем обсуждать?

[Butylski]

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

[angelov]

Тут автор что имел ввиду? Если у нас есть логин и пароль, не будем делать сессию - зашифруем пароль и всунем его в куки?

[Butylski]

зачем?

[zorba_buddha]

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

[Butylski]

видимо автор лишь донес свою идею (код выдернут из контекста). чтобы код работал, надо самим пошустрить ;)

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

конечно промежуточные данные можно хранить и более безопасно: в пхп-сессии, в БД, в memcached, но зачастую возникает потребность использовать банальные cookies.

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

[zorba_buddha]

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

[josser]

Мдя. Есть такое главное правило в криптографии: Защищённость системы определяется не секретностью алгоритма, а длинной ключа. Исключение можно сделать только для стеганографических алгоритмов.

Вопщем там выше уже писали про Шнайера.

[Butylski]

тут дело не в криптографии, а в минимальном сокрытии открытых для пользователя данных. в данном случае - cookies

[zorba_buddha]

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

[Butylski]

в общем зря заметку заминусовали. она будет полезной для тех, кто поймет.
сколько раз я видел в opensource-проектах криво выставленные куки.. разработчики не удосужились хоть как-то "прикрыть" уязвимое место.