Просмотр полной версии : Выбор самого безопастного способа авторизации на портале
GHostly_FOX
28.08.2007, 15:14
При написании системы защиты для нашего движка я с напарником столкнулся в таком вопросе что будет безопаснее:
- авторизация используя протоком SSL
- авторизация используя следующий скрипт (код скрипта приведен ниже в урезанном виде)
//admin.php
<script src="jquery.js" type="text/javascript"></script>
<script src="md5.js" type="text/javascript"></script>
<script>
function chek(login, passw){
$("#body").load("passwd.php",{user:md5(login) ,passwd:md5(passw)});
}
</script>
<div id="body">
<form method="POST" enctype="text/plain">
<input type="text" id="user" name="user" value="test" /><br>
<input type="password" id="pass" name="pass" value="test2" /><br>
<input type="button" value="Проверка2" onclick='chek($("#user").attr("value"), $("#pass").attr("value"));' />
</form>
</div>
//passwd.php
<?
if (isset($_SERVER['HTTP_REFERER']) && $_SERVER['HTTP_REFERER'] == 'http://server/test.php'){
//Тут идет обработка данных
}else{
print "Haking alert!";
}
?>
И если кто заметит изъян безопастности скрипта посоветуйте?!
groundhog
28.08.2007, 15:20
Ну в принципе через JavaScript вариант тоже безопасный, т.к. передаются хеши вместо значений... Но всё равно проснифав трафик, злоумышленник будет располагать хешами которые передаются на сервер, наверняка найдётся такая пара логин/пароль, которая подойдёт к аккаунту какого-то нерадивого пользователя. Что касется SSL - то тут хоть до усрачки снифай, ничего о внутреннем содержании канала передачи данных ты не узнаешь... То есть, SSL - верх безопасности... А если вы замутите JavaScript авторизацию через SSL так это вообще чума будет...
как можно вообще сравнивать протокол SSL и проверку паролей на JS?????? это обсалютно разные вещи.
А если интересует вопрос безопасности, то стоит организовать процесс передачи хэшей пароля посредством ssl, а далее можно, впринципе, получив сессию привязаную к пользователю его ip и т.д. работать по простому http.
inlanger
28.08.2007, 17:09
А как это всё на Php сделать? Хочу сделать на сайте возможность регистрации юзеров, для того, чтобы юзеры могли настраивать сайт под свои нужды.
SSL луче конечн но возни с ним та и дороговато будет
Вроде как только крутые раскрученные порталы юзают ссл
а для середнякового сайта и через js пойдет все зависит насколько конфиденциальны данные
Как можно передавать хэши паролей вместо самих паролей? Это не шифрование данных, потому что серверный обработчик получает ХЭШ, а не ПАРОЛЬ. А это значит, что система не только не защищает вас от прослушки трафика (т.к. в этом случае авторизация не через пароль, а через его хэш), но еще и разрушает основную концепцию безопасности авторизации в системах ограниченного доступа, т.к., имея доступ к базе данных, злоумышленник уже имеет фактически ПАРОЛЬ, а не ХЭШ и может в этих самых системах авторизовываться по нему (если вы конечно не храните в базе данных хэш от хэша, что вообщем никаким образом не умоляет бредовости идеи передавать вместо пароля его md5 отпечаток).
SSL или самодельная шифрация (можно с помощью яваскрипт, но в этом случае вас ничто не страхует перед хакером, если он случайно найдет алгоритм шифрации в яваскрипт (а он это сделает, зная страницу авторизации) ), впрочем от целенаправленной просллушки канала на конкретно этот логин/пароль вас вообще ничего не спасет.
Dword, не тупи. Хэш предается вместо пароля лишь для того, что бы сложно было узнать сам пароль, который, коль ты заговорил о КОНЦЕПЦИЯХ БЕЗОПАСНОСТИ, должен быть максимально скрыт и от злоумышлеников и от администрации, в связи с очень частым использованием пользователями одинаковых паролей в разных системах.
по поводу твоего высказывания в адресс Ssl просто нечего сказать....
Dword, не тупи. Хэш предается вместо пароля лишь для того, что бы сложно было узнать сам пароль, который, коль ты заговорил о КОНЦЕПЦИЯХ БЕЗОПАСНОСТИ, должен быть максимально скрыт и от злоумышлеников и от администрации, в связи с очень частым использованием пользователями одинаковых паролей в разных системах.
Бред...
по поводу твоего высказывания в адресс Ssl просто нечего сказать....
А ты попробуй. Если канал прослушивается с целью получить конкретно пароль и логин, то злоумышленник имеет понятие и об организации шифрованного канала и обо всех ключах, которыми обменивается клиент и сервер, или может они ими по воздуу перекидываются?
что именно?
То что пароль заменяется на хэш, нет в этом никакого смысла. Это не шифрация а просто замена одного другим, а если при этом еще и забывать о том, что в базе должен быть хэш пароля, а не он сам и класть туда полученный md5, то это не просто не имеет смысл, но и создает дополнительные угрозы безопасности
Update: madnet удалил свой пост :(
Dword, до тебя не доходит для чего в данном случае хэшируются пароли.
>если класть туда полученный md5, то это не просто не имеет смысл, но и создает дополнительные угрозы безопасности
нука нука, интересно чем же здесь опаснее чем простой пароль ложить в БД?
Dword, до тебя не доходит для чего в данном случае хэшируются пароли.
Видно надо вернуться с небес в реальность и понять что, если у тебя рыжий цвет ника и ты можешь понижать/повышать "репутацию", это вовсе не означает что ты всегда прав и можешь в категоричной форме рассказывать всякий бред/удалять свои сообщения и так далее. Я закончил.
Видно надо вернуться с небес в реальность и понять что, если у тебя рыжий цвет ника и ты можешь понижать/повышать "репутацию", это вовсе не означает что ты всегда прав и можешь в категоричной форме рассказывать всякий бред/удалять свои сообщения и так далее. Я закончил.
+))) ЛОЛ
не хотел тебя радовать раньш времени, но ты тоже можешь понижать/повышать "репутацию" и удалять свои сообщения.
Так что давай пожалуйста без оскорблений, а просто говори по теме, если есть что сказать.
Идея хорошая, можно ещё сделать немного подругому :)
<?
$site = 'http://ваш.сайт.ру' //именно в таком формате (без слеша в конце)
if(!preg_match('#^'.$site.'(.*)$#i',$_SERVER['HTTP_REFERER'])) {
echo('Попробуйте зайти через сайт.');
} else {
//если всё ок
}
?>
На самом деле madnet прав, пароль не должен передаваться на сайт в открытом виде, хотя предложенные способы авторизации тоже могут не прокатить
js - Злоумышленнику не нужен пароль, у него и так есть то, что просит у него сервер, это хэш
ssl - Может защитить только если злоумышленник начнёт снифать трафик, после того как браузер принял сертификат, иначе у него и браузера одинаковые шансы получить всю передаваемую информацию.
Лучший способ защитить пароль, это получить у клиента логин, достать из базы пароль, сгенерировать блок рандомных данных длиной примерно 256 байт, передать его клиенту, потом каждый из вас зашифрует его хэшем пароля, сервер положит хэшь в сесионную переменную,
Клиент обращается к серверу передовая логин: сервер достаёт из базы хэш пароля, генерирует блок рандомных данных длиной примерно 256 байт, возвращает его клиенту, тем временем шифрует его хэшью пароля, вычисляет из результата новую хэш и сохраняет её в сессионную переменную.
Клиент получает от сервера блок данных, так-же шифрует его хэшью пароля и так-же вычисляет из него новую хэш, с которой и обращается к серверу: сервер сравнивает полученные хэши и ауторезирует клиента в случае совпадения.
При смене пароля нужно снова провести всю эту операцию, за исключением того, что сервер уже знает логин.
При таком случае, даже если не использовать ssl и злоумышленник будет снифать весь трафик, ему потребуются сотни лет, чтоб сбрутить хэш от 256байтного блока, зашифрованного хэшью пароля.
Недостаток, время выполнения скрипта(ДоС-атаки), выход бан по ип.
Новый пароль, при смене пароля можно хэшировать и зашифровать хэшью старого, так как и клиент и сервер её знают.
Как можно передавать хэши паролей вместо самих паролей? Это не шифрование данных, потому что серверный обработчик получает ХЭШ, а не ПАРОЛЬ. А это значит, что система не только не защищает вас от прослушки трафика (т.к. в этом случае авторизация не через пароль, а через его хэш), но еще и разрушает основную концепцию безопасности авторизации в системах ограниченного доступа, т.к., имея доступ к базе данных, злоумышленник уже имеет фактически ПАРОЛЬ, а не ХЭШ и может в этих самых системах авторизовываться по нему (если вы конечно не храните в базе данных хэш от хэша, что вообщем никаким образом не умоляет бредовости идеи передавать вместо пароля его md5 отпечаток).
SSL или самодельная шифрация (можно с помощью яваскрипт, но в этом случае вас ничто не страхует перед хакером, если он случайно найдет алгоритм шифрации в яваскрипт (а он это сделает, зная страницу авторизации) ), впрочем от целенаправленной просллушки канала на конкретно этот логин/пароль вас вообще ничего не спасет.
Мда, лучше б ты промолчал, хоть сам то понял чего написал =\
SSL или самодельная шифрация (можно с помощью яваскрипт, но в этом случае вас ничто не страхует перед хакером, если он случайно найдет алгоритм шифрации в яваскрипт (а он это сделает, зная страницу авторизации) ), впрочем от целенаправленной просллушки канала на конкретно этот логин/пароль вас вообще ничего не спасет.
КОПАЙ! Могильничек а в нём амфора ПОООООЛНАЯ оксибутирата натрия!
Клиент обращается к серверу передовая логин: сервер достаёт из базы хэш пароля, генерирует блок рандомных данных длиной примерно 256 байт, возвращает его клиенту, тем временем шифрует его хэшью пароля, вычисляет из результата новую хэш и сохраняет её в сессионную переменную.
Клиент получает от сервера блок данных, так-же шифрует его хэшью пароля и так-же вычисляет из него новую хэш, с которой и обращается к серверу: сервер сравнивает полученные хэши и ауторезирует клиента в случае совпадения.
При смене пароля нужно снова провести всю эту операцию, за исключением того, что сервер уже знает логин.
При таком случае, даже если не использовать ssl и злоумышленник будет снифать весь трафик, ему потребуются сотни лет, чтоб сбрутить хэш от 256байтного блока, зашифрованного хэшью пароля.
Гениально! +++ Хотя вклиниться в текущее соединение по прежнему хакеру никто не мешает, если он сможет блокировать легального клиента и имеет возможность посылать пакеты серверу системы ограниченного доступа.
Хотя, ведь можно дальше шифровать трафик настоящим паролем, который теперь знает только клиент и сервер? Вообщем супер. А ты сам придумал?
Хотя, ведь можно дальше шифровать трафик настоящим паролем, который теперь знает только клиент и сервер? Вообщем супер. А ты сам придумал?
Такие алгоритмы элементарно придумываются после прочтения книги товарища Шнаера "Прикладная криптография". Думаю, автор с ней знаком. :)
Единственное трезвое сообщение из всего топика кстати (2hidden).
Такие алгоритмы элементарно придумываются после прочтения книги товарища Шнаера "Прикладная криптография". Думаю, автор с ней знаком. :)
Да, к сожалению, ни с какой криптографической литературой не знаком (что собираюсь в скором времени исправить), поэтому мои посты в этой теме были направлены на указание ошибок(коими я их по прежнему считаю) предыдущих авторов, но ни как не на решение самой проблемы.
Была одна книжка по криптографии, правда я от туда всего пару статеек прочёл, ИМХО(чтение книг вредно сказывается на глазах, читать надо только то, что действительно информативно и поможет в будущем)
Хотя, ведь можно дальше шифровать трафик настоящим паролем, который теперь знает только клиент и сервер? Вообщем супер. А ты сам придумал?Ага, как-то задумывался над способом авторизации, кстати, паролем ничего, ни в коем случае, нельзя шифровать, тем более html !!!, его можно будет вычислить статистически после первой же страницы ;)
Имеется ввиду пакеты длиной больше длины пароля, можно рассматривать способ разбиения страницы на пакеты, перемешивания их и добавления в каждый предыдущий пакет, пароль к следующему. В этом случае о XOR-шифровании не может быть и речь, лучше обмен байта по коду символа пароля. Хотя тоже не очень надёжно и очень не экономично.
Если надо защищать не пароль а страницы, то уж лучше ssl использовать.
На самом деле madnet прав, пароль не должен передаваться на сайт в открытом виде, хотя предложенные способы авторизации тоже могут не прокатить
js - Злоумышленнику не нужен пароль, у него и так есть то, что просит у него сервер, это хэш
ssl - Может защитить только если злоумышленник начнёт снифать трафик, после того как браузер принял сертификат, иначе у него и браузера одинаковые шансы получить всю передаваемую информацию.
Лучший способ защитить пароль, это получить у клиента логин, достать из базы пароль, сгенерировать блок рандомных данных длиной примерно 256 байт, передать его клиенту, потом каждый из вас зашифрует его хэшем пароля, сервер положит хэшь в сесионную переменную,
Клиент обращается к серверу передовая логин: сервер достаёт из базы хэш пароля, генерирует блок рандомных данных длиной примерно 256 байт, возвращает его клиенту, тем временем шифрует его хэшью пароля, вычисляет из результата новую хэш и сохраняет её в сессионную переменную.
Клиент получает от сервера блок данных, так-же шифрует его хэшью пароля и так-же вычисляет из него новую хэш, с которой и обращается к серверу: сервер сравнивает полученные хэши и ауторезирует клиента в случае совпадения.
При смене пароля нужно снова провести всю эту операцию, за исключением того, что сервер уже знает логин.
При таком случае, даже если не использовать ssl и злоумышленник будет снифать весь трафик, ему потребуются сотни лет, чтоб сбрутить хэш от 256байтного блока, зашифрованного хэшью пароля.
Недостаток, время выполнения скрипта(ДоС-атаки), выход бан по ип.
Новый пароль, при смене пароля можно хэшировать и зашифровать хэшью старого, так как и клиент и сервер её знают.
Да так будет погиморойнее.
Сам пароль будет скрыт от хакера, но впринципе при снифании ничего не мешает:
1)узнать те самые 256 байт от сервера и результат который мы получим от хэширования этих данных хешем паролем, если пароль не сложный и алогоритм хеширования пароля и данных не особо криптостойкий, то есть шанс узнать его, тут решающую роль играет алгоритм хэширования.
2)Что нам мешает перехватить результативный хэш, отправленый клиентом и находящийся в сессии у сервера и обратится с ним к серверу? Только ограничение по IP, но можно предположить, что имея доступ к трафику злоумышним может и подделать IP.
Да так будет погиморойнее.
Сам пароль будет скрыт от хакера, но впринципе при снифании ничего не мешает:
1)узнать те самые 256 байт от сервера и результат который мы получим от хэширования этих данных хешем паролем, если пароль не сложный и алогоритм хеширования пароля и данных не особо криптостойкий, то есть шанс узнать его, тут решающую роль играет алгоритм хэширования.
2)Что нам мешает перехватить результативный хэш, отправленый клиентом и находящийся в сессии у сервера и обратится с ним к серверу? Только ограничение по IP, но можно предположить, что имея доступ к трафику злоумышним может и подделать IP.Мешает:
1) Время, это не 6ти и даже не 16ти-байтовую хэш брутить.
2) Этот способ защищает только от смены пароля и от повторной авторизации и обеспечивает сохранность пароля.
Для полной сохранности, можно яваскриптом посылать последовательность действий пользователя и если она не совпадает с серверной, сессия сразу-же прерывается.
Кстати, насчёт шифрования данных паролем, только-что придумал; можно на зашифрованный паролем блок данных(тот что использовался при авторизации) наложить несколько заранее известных масок и вычислить от каждой из них хэши(также очень желательно, чтоб длины шэший зависели от самих данных, например усекать их по контрольной сумме данных, а-то снова статистика ;) ), затем этими известными только клиенту и серверу хэшами шифровать получаемые и передаваемые данные.
ЗЫ Ладно, для маленького партальчика защита пойдёт :D
GHostly_FOX
03.09.2007, 06:25
я прочитал про технологию создания сертификатов SSL, там при создании сертификата можно использовать 3 рандомных текстовых файла сжатых gzip тут уж точно невозможно никак угадать какие именно данные были в этих файлах а значит нельзя подделать сертификат.
А если авторизация будет проходить как к примеру на хостинге агава: Доступ по SSL и авторизация на уровне HTTP-аутентификации.
Можно ли при такой авторизации злоумышленику получить коды доступа или авторизоватся?!
GHostly_FOX
03.09.2007, 08:20
Вот последние мысли по данной теме:
При входе пользователя на страницу с формой авторизации создается сессия и рандомом генерируется код Captcha, в базу записываются данные Ip, Session_id, Captcha код, дата, время...
Пользователь вводить Логин и пароль нажимает вход.
Логин и пароль передаются обработчику уже в формате Md5.
Обработчик сравнивает данные, Логина, пароля, скрипта от которого был подан запрос и сравнивает Captcha код который он берет из базы по Session_id.
Если хоть один момент не верен то блок по Ip на минуту...
Какие будут замечания по данному предложению?!
...
Какие будут замечания по данному предложению?!А чего ты пытался добиться этим способом?
GHostly_FOX
03.09.2007, 12:32
Я хочу предотвратить кражу хешей паролей и предотвратить любые возможности прослушивания портов...
сделай свою ф-ию алгоритма хеширования пароля, к примеру:
............
$pass=null;
$abc="abcdefghjkmnpqrstuvwxyz".
"ABCDEFGHJKLMNPQRSTUVWXYZ";
$arr=explode(chr(32),trim(chunk_split($abc,1,chr(3 2))));
$size=count($arr)-1;
for($i=0;$i<$PasswordSize;$i++)
$pass.=$arr[rand(0,$size)]; // Создание пароля
// Финкция "Шифровка пароля"
function encrypt($s, $key)
{
for($i=0;$i<=strlen($s);$i++)
$r.=substr(str_shuffle(md5($key)),($i % strlen(md5($key))),1).$s[$i];
for($i=1;$i<=strlen($r);$i++) $s[$i-1]=chr(ord($r[$i-1])+ord(substr(md5($key),($i % strlen(md5($key)))-1,1)));
return urlencode(base64_encode($s));
}
// --------------------------
$timed = date("YmdHis"); // Время регистрации
$timef = date("d.m.Y H:i:s"); // Время регистрации для письма
//+++++++++++++++++
$key = md5($timed); // КЛЮЧ Для Кодирования/Декодирования
$s = $pass;
$encrypted = encrypt($s, $key); // Кодирование пароля с ключом
$passmd = $encrypted;
//-----------------
#$ucode = md5($_POST['email']); // Код для активации
$umail = $_POST['email'];
$ulog = $_POST['login'];
...........
................
// Функция Декодирования
function decrypt($s, $key)
{
$s=base64_decode(urldecode($s));
for($i=1;$i<=strlen($s);$i++) $s[$i-1]=chr(ord($s[$i-1])-ord(substr(md5($key),($i % strlen(md5($key)))-1,1)));
for($i=1;$i<=strlen($s)-2;$i=$i+2) $r.=$s[$i];
return $r;
}
$qe=mysql_query("SELECT pass,hash FROM users WHERE login='".$_POST['login']."' LIMIT 1");
$re=mysql_fetch_array($qe);
if(mysql_num_rows($qe)) {
$key = $re["hash"]; // КЛЮЧ Для Кодирования/Декодирования
$encrypted = $re["pass"];
$decrypted = decrypt($encrypted, $key); // Декодирование пароля с ключом
$pass = $decrypted;
// ------- decode end ---------
if ($_POST['pass'] == $pass) {
..................
GHostly_FOX
04.09.2007, 11:33
Помогите настроить SSL?!
Я уже с помощью Open_SSL и сертификаты создал...
Поставил WEB сервер (на ОС Windows) Apache + PHP + MySQL + mod_ssl
В Апаче прописал следующее:
httpd.conf:
LoadModule ssl_module modules/mod_ssl.so
<IfModule mod_ssl.c>
Include conf/ssl.conf
</IfModule>
ssl.conf
SSLRandomSeed startup builtin
SSLRandomSeed connect builtin
<IfDefine SSL>
Listen 192.168.110.197:443
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl .crl
SSLSessionCache dbm:logs/ssl_scache
SSLSessionCacheTimeout 300
SSLMutex default
<VirtualHost _default_:443>
DocumentRoot "c:/sweb/home/system/www/ssl"
ServerName system.ssl
ServerAdmin admin@mail.ru
ErrorLog logs/error_log_ssl.log
TransferLog logs/access_log_ssl.log
SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSL v2:+EXP:+eNULL
SSLCertificateFile conf/ssl.crt/server.crt
SSLCertificateKeyFile conf/ssl.key/server.key
<FilesMatch "\.(cgi|shtml|phtml|php3?)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory "C:/sweb/home/system/www/ssl">
SSLOptions +StdEnvVars
AuthType Basic
AuthName "By Invitation Only"
AuthUserFile c:/sweb/usr/local/apache2/conf/passwd.txt
Require valid-user
</Directory>
SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
CustomLog logs/ssl_request_log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>
</IfDefine>
В чем проблемма?!
не идет загрузка =(
Дельная была идея сделать wiki для а-чата, а то я себя после этих сообщений полным ламером чувствую. Будет на что ссылаться...
http://slovari.yandex.ru/dict/informatica/article/info/info-490.htm?text=hash
Вот нашел статейку интересную
http://www.habrahabr.ru/blog/php/24389.html
Полезно почитать...
FoxMALDER
11.09.2007, 00:45
Складывается впечатление, что наш народ думать разучился... :-(
Кто запрещает при авторизации взять на вооружение, следующие параметры:
- разрешение экрана
- версия браузера
- локальное время клиента
- и т.д.
И использовать эти данные как salt в md5... А "куда" вставить и какое количество бит salt'a использовать это по фантазии разработчика...
GreenBear
11.09.2007, 00:56
Складывается впечатление, что наш народ думать разучился... :-(
складывается впечатление, что у многих очень много ума, чтобы искать себе геморой на жопу. проще 5 символов сгенирировать и не парится.
FoxMALDER
11.09.2007, 02:07
складывается впечатление, что у многих очень много ума, чтобы искать себе геморой на жопу. проще 5 символов сгенирировать и не парится.
А кто мешает применять при этом captcha-код??? :cool:
P.S.: При таком раскладе геморой будет не у тебя, а у того кто будет в таких дебрях разбираться...
Мы не ищем лёгких путей!!!
2FoxMALDER, Не подскажешь нам, необразованным, зачем нам соль при авторизации?
FoxMALDER
12.09.2007, 21:46
Не подскажешь нам, необразованным, зачем нам соль при авторизации?
Зачем тогда вообще использовать авторизацию?! Зачем пароль вообще каким-либо способом шифровать???
P.S.: Я вообще предложил применить в шифровании пароля так называемый salt, а как его альтернативу брать дополнительные данные которые всегда у каждого пользователя будут уникальными...
Для начала читай все посты, а потом рассказывай про свою образованость :D
P.S.: Я вообще предложил применить в шифровании пароля так называемый salt, а как его альтернативу брать дополнительные данные которые всегда у каждого пользователя будут уникальными...Зачем при авторизации уникальные данные, которые у каждого КОМПЬЮТЕРА будут разные???, что ими шифровать???
Зачем тогда вообще использовать авторизацию?! Зачем пароль вообще каким-либо способом шифровать???Не надо отвечать вопросами на вопросы, ты просто скажи зачем при авторизации соль, пока-что я твои посты расцениваю как флуд-оффтоп...
GreenBear
15.09.2007, 01:12
Мы не ищем лёгких путей!!!
ты не думал, что я захожу на сайт не только с одного компьютера?
FoxMALDER
15.09.2007, 03:35
Зачем при авторизации уникальные данные, которые у каждого КОМПЬЮТЕРА будут разные???, что ими шифровать???
Ок! Перейду на твой язык восприятия... Добавить соль к паролю и защифровать.
Не надо отвечать вопросами на вопросы, ты просто скажи зачем при авторизации соль, пока-что я твои посты расцениваю как флуд-оффтоп...
Выше сказано было достаточно... Я предлагал, как АЛЬТЕРНАТИВНЫЙ метод... Если кому-то не нравится, я лично не навязываю такой способ никому!
Ответь на такой вопрос, нахрена тогда пароль в чистом виде шифровать в md5 и передавать на сервак?! Если lookup можно сделать не напрягаясь!
Давай перейдём на реальные вещи, для твоего понимания...
1) Открываю страницу авторизации, вижу форму: login, pass, captcha.
2) Ввожу login, pass, captha
3) Отправляю: login, md5(md5(captcha):md5(pass)), captcha
Это как пример соли в пароль, можно не именно так...
P.S.: Смысл уловил?! :cool:
добавлю к hidden: мы, кстати говоря, вообще не обязаны передавать этот самый блок длинной 256 в открытом виде;) к прочтению
http://ru.wikipedia.org/wiki/Алгоритм_Диффи_—_Хеллмана
vBulletin® v3.8.14, Copyright ©2000-2026, vBulletin Solutions, Inc. Перевод: zCarot