Комментарии 31
прикрути ко всему этому еще и сериализацию всех кук и будет совсем счастье ;) тем самым можно снять ограничение на максимальное кол-во кук для одного домена..
ps: я так давно уже делаю. только шифрую немного по-другому
ps: я так давно уже делаю. только шифрую немного по-другому
Как всё запущено...
Мы получаем развёрнутую задом на перёд пустую строку. ;) Кстати, зачем нам так хотелось бинарную строку? Это нынче эффективнее, чем хеш, состоящий из шестнадцатеричных символов?
Не нужно людей приучать к тому, что кто-то код не увидит. Не зря ведь придуманы алгоритмы для одностороннего преобразования данных в хеши. Храните свой $user_id, или что там у вас, на сервере, а в куки передавайте хеш.
$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; // Это ужасно
хы-хы, верно. книжки нужно почитать сначала (шнайера, например), а потом мастерить свои мегаалгоритмы.
Автор просто не хочет раскрывать свой алгоритм =)
строка не пустая, у меня всё работает просто отлично как на серверах, так и на своей машине.
вы не получите из хеша данных, а поиск по хешу не быстрее поиска по user_id, как и чтение файла с диска.
на счёт ужасно - обоснуйте или не говорите глупостей.
вы не получите из хеша данных, а поиск по хешу не быстрее поиска по user_id, как и чтение файла с диска.
на счёт ужасно - обоснуйте или не говорите глупостей.
Работает именно тот код, который вы привели? ;)
Из хеша данных и не надо получать. Хеш — это для надёжности и базопасности. Если вам это не так нужно, и решили хранить в браузере данные пользователя, то хотя бы придумали б более красивое решение. Например, можно было сериализовать массив с данными пользователя и выполнить сжатие. А чтоб бинарные данные нормально сохранились в куках — запаковать в base64. Вот оно, простое и элегантное решение:
По поводу глупостей. Пожалуйста, просмотрите внимательно свой код и мой прошлый комментарий. По два раза обосновывать нет желания.
Из хеша данных и не надо получать. Хеш — это для надёжности и базопасности. Если вам это не так нужно, и решили хранить в браузере данные пользователя, то хотя бы придумали б более красивое решение. Например, можно было сериализовать массив с данными пользователя и выполнить сжатие. А чтоб бинарные данные нормально сохранились в куках — запаковать в base64. Вот оно, простое и элегантное решение:
$data=base64_encode(gzdeflate(serialize($data)));По поводу глупостей. Пожалуйста, просмотрите внимательно свой код и мой прошлый комментарий. По два раза обосновывать нет желания.
при разборке сам идентификатор упустил.
исправил
исправил
Я вас умоляю, изучите внимательно свой код. У вас 4 присваивания одной переменной. В итоге она будет иметь значение, установленное в последней строчке. Три предыдущих не влияют на результат.
Зачем приводить код, который не работает?
$cookie = $user_id + abs($crc32);
$cookie = decbin($cookie_id);
$cookie = str_pad($cookie_id, 32, '0', TR_PAD_LEFT);
$cookie = strrev($cookie_id);Зачем приводить код, который не работает?
Зачем это все?
ох уж эти пхп-кодеры. вечно изобретут велосипед. это сказывается отсутствие своего фреймворка у пхп?
Может я только вернулся и отвык от компа, но что-то с ходу не врубился что это и для чего? Не могли бы подробнее обьяснитЬ, а то я было подумал что мы шифруем от пользователя его же данные и их ему же зашифрованным посылаем
видимо автор лишь донес свою идею (код выдернут из контекста). чтобы код работал, надо самим пошустрить ;)
иногда требуется в куке хранить не только хэш, но и какие-то открытые данные, которые надо хоть как-то шифровать.
односторонние алгоритмы шифрования тут не помогут, первоначальное значение нужно получить.
конечно промежуточные данные можно хранить и более безопасно: в пхп-сессии, в БД, в memcached, но зачастую возникает потребность использовать банальные cookies.
и никакие фреймворки вам не помогут. есть прикладные задачи, которые требуют подумать котелком.
иногда требуется в куке хранить не только хэш, но и какие-то открытые данные, которые надо хоть как-то шифровать.
односторонние алгоритмы шифрования тут не помогут, первоначальное значение нужно получить.
конечно промежуточные данные можно хранить и более безопасно: в пхп-сессии, в БД, в memcached, но зачастую возникает потребность использовать банальные cookies.
и никакие фреймворки вам не помогут. есть прикладные задачи, которые требуют подумать котелком.
Мдя. Есть такое главное правило в криптографии: Защищённость системы определяется не секретностью алгоритма, а длинной ключа. Исключение можно сделать только для стеганографических алгоритмов.
Вопщем там выше уже писали про Шнайера.
Вопщем там выше уже писали про Шнайера.
тут дело не в криптографии, а в минимальном сокрытии открытых для пользователя данных. в данном случае - cookies
практически как достоинство мужчины измеряется длинной его пениса?
извините, не согласен с вами.
приведённый пример в комплексе даёт наибольшую защиту, потому как собой составляет ещё больший ключ, нежели обычный 32 битовый.
извините, не согласен с вами.
приведённый пример в комплексе даёт наибольшую защиту, потому как собой составляет ещё больший ключ, нежели обычный 32 битовый.
в общем зря заметку заминусовали. она будет полезной для тех, кто поймет.
сколько раз я видел в opensource-проектах криво выставленные куки.. разработчики не удосужились хоть как-то "прикрыть" уязвимое место.
сколько раз я видел в opensource-проектах криво выставленные куки.. разработчики не удосужились хоть как-то "прикрыть" уязвимое место.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кодирование цифрового идентификатора