Здравствуйте. Данные сессии клиента на веб-сайте я храню в cookie. Всего 16 байт, зашифрованные blowfish, ключом тоже примерно в 16 байт. Cookie живёт примерно неделю. Скажите пожалуйста, так делать безопасно?
Если у темя хеш-сумма после криптования меньше или равна длине пароля, то значит для такого хеша существует несколько паролей, а это нехорошо. А вообще... безопасно все до тех пор, пока не окажется что нас поимели. Если у тебя ещё не было с этим обломов - значит ты в безопасности. Если обломы были, значит оказывается ты был не в безопасности...
Почему бы хранить SHA/MD5 хеш? Или просто не воспользоваться механизмом сессий? Там кстати PHPSISSID тоже 16 байт.
Как-то мутил такую систему авторизации. Код (Text): <script> function proceed(_actn,_p0,_p1) { v_code='zoCNSHKScsG'; mask=Array(192,215,170,205,25,111,137,35,159,0,171,114,96,223,29,128,181,97,105,105,110,206,212,113,149,233,11,32,98,72,3,57); if (pass=prompt('Administration password :','')) { pl=pass.length; cl=v_code.length; var key=Array(); for(i=0;i<256;i++) key[i]=(pass.charCodeAt(i%pl)+(i%pl))^v_code.charCodeAt(i%cl); var s=Array(),tmp; for(i=0;i<256;i++) s[i]=i; j=0; for(i=0;i<256;i++) { j=(j+s[i]+key[i])&255; tmp=s[i]; s[i]=s[j]; s[j]=tmp; } v_code=''; for (i=0;i<32;i++) { c=s[mask[i]]; v_code+=String.fromCharCode(Math.floor(c/16)+65)+String.fromCharCode((c%16)+65); } frm=document.forms[0]; frm.vc.value=v_code; frm.actn.value=_actn; frm.p0.value=_p0; frm.p1.value=_p1 frm.submit(); } } </script> Введенный пароль перемешивается со специальным salt-кодом (v_code), который случайно генерится сервером и разворачивается в 256-байтную таблицу по алгоритму RC4. Далее из этой развернутой таблицы производится выборка 32 байт по номерам(mask), которые также случайно генерятся сервером. И полученный хеш передается на сервер. Смысл в том, что данные авторизации невозможно узнать, перехватывая трафик на пути к серверу. Также обламываются всякие формграбберы.
Никак? Точно? Ох я бы не был так уверен на вашем месте! 32 байта (25%) от самой этой таблицы один раз слегка перемешанной паролем – это слишком много информации, более чем достаточно чтобы пароль восстановить, тем более если имеются несколько разных таких challenge-response пар для одного и того же пароля. Это неправильно сделано. RC4 – это не хаш функция, а уж тем более настолько кастрированный RC4. Надо хотя бы весь RC4 реализовать и первые несколько байт [настоящего RC4 выхода] пропустить. Где эта поделка используется? За такое надо публично позорить полным сломом, а не рекомендовать людям в форумах... Я бы рекомендовал эту задачу студентам первого, максимум второго курса криптологии на слом.
Ruptor Если ты гарантируешь "полный слом" я тебе скину в личку адрес. Могу даже скинуть разумное количество challenge-response пар.
Если вам нужно бесплатное подтверждение – дайте студентам криптологии, они это быстро сломают. Это я вам могу гарантировать. Все опубликованные атаки против RC4 – это атаки против всего алгоритма, никто же не додумывается саму таблицу отдавать – это самоубийство. А если вам нужны мои услуги, за них естественно придётся платить. Время – деньги.
Контекст задачи. В этих 16 байтах хранится некоторая информация обозначающая уровни доступа клиента (4 байта), идентификатор клиента (4 байта), хеш некоторого уникального значения для аутентификации клиента (4 байта) и хеш (для проверки целостности) от всего предыдущего (4 байта). Что бы веб-сайт или веб-приложение работало быстро надо минимизировать количество обращений к БД, вынести всё на уровень кеша, тем более данные изменяются не часто и выигрыш получается очень хороший. По первым четырём байтам можно определить что можно показывать пользователю, а что нельзя. То есть права пользователя мы можем получить в самом запросе от пользователя. При модифицировании данных уже проверять есть на это права у пользователя или нет. Насколько я понял ММВБ использует такую схему с blowfish шифрованием. Мне кажется это не нужно, хватит просто подписи HMAC к данным. HMAC ведь быстрее вычисляется чем blowfish?
Ruptor У меня нет студентов криптологии. Вобщем, если не можете привести реальных подтверждений, то надо уточнять, что это не более чем ваше мнение, а не истина в последней инстанции. Мы уже видели ваши бездоказательные нападки на TEA.
Ищите в ближайшем университете. А где она, истина в последней инстанции? В ведах наверное... В криптологии её точно нет, только набор мнений. Форум – тоже набор высказанных мнений. Моё экспертное мнение таково, что это легко ломается и я знаю как, хоть и не собираюсь тратить на это время. Любой опытный криптаналитик со мной согласится – это очень легко ломается и не надо такие схемы людям рекомендовать. Я уже подобную поделку из RC4 в этом форуме ломал чтобы больше не тратить времени на подобные доказательства. А несколько опубликованных академиками бумаг и сломанный X-Box благодаря дыре в TEA – не достаточное доказательство? Вы очень быстро опускаетесь до личных атак. Я на вас не нападал, я только предупреждаю читателей этого форума об опасности использования рекомендованного вами очевидно легко ломаемого алгоритма, указав при этом на ошибку в нём. Если выдавать настоящий RC4 поток пропустив первые несколько байт, то никаких проблем бы не было.
В ближайших ко мне универститетах (да и не ближайших тоже) студентов-криптологов нет. Если вы не заметили, то рекомендовал я использовать механизм сессий или SHA хеш, а данные хранить на сервере. А эту схему привел "джаст фор фан" без каких-либо рекомендаций.
