Форум АНТИЧАТ

Форум АНТИЧАТ (https://forum.antichat.xyz/index.php)
-   PHP, PERL, MySQL, JavaScript (https://forum.antichat.xyz/forumdisplay.php?f=37)
-   -   Выбор самого безопастного способа авторизации на портале (https://forum.antichat.xyz/showthread.php?t=47802)

GHostly_FOX 28.08.2007 15:14
Выбор самого безопастного способа авторизации на портале
 
При написании системы защиты для нашего движка я с напарником столкнулся в таком вопросе что будет безопаснее:
- авторизация используя протоком SSL
- авторизация используя следующий скрипт (код скрипта приведен ниже в урезанном виде)

//admin.php
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
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 так это вообще чума будет...

madnet 28.08.2007 16:35
как можно вообще сравнивать протокол SSL и проверку паролей на JS?????? это обсалютно разные вещи.

А если интересует вопрос безопасности, то стоит организовать процесс передачи хэшей пароля посредством ssl, а далее можно, впринципе, получив сессию привязаную к пользователю его ip и т.д. работать по простому http.

inlanger 28.08.2007 17:09
А как это всё на Php сделать? Хочу сделать на сайте возможность регистрации юзеров, для того, чтобы юзеры могли настраивать сайт под свои нужды.

sqr 28.08.2007 17:24
SSL луче конечн но возни с ним та и дороговато будет
Вроде как только крутые раскрученные порталы юзают ссл
а для середнякового сайта и через js пойдет все зависит насколько конфиденциальны данные

DWORD 28.08.2007 17:27
Как можно передавать хэши паролей вместо самих паролей? Это не шифрование данных, потому что серверный обработчик получает ХЭШ, а не ПАРОЛЬ. А это значит, что система не только не защищает вас от прослушки трафика (т.к. в этом случае авторизация не через пароль, а через его хэш), но еще и разрушает основную концепцию безопасности авторизации в системах ограниченного доступа, т.к., имея доступ к базе данных, злоумышленник уже имеет фактически ПАРОЛЬ, а не ХЭШ и может в этих самых системах авторизовываться по нему (если вы конечно не храните в базе данных хэш от хэша, что вообщем никаким образом не умоляет бредовости идеи передавать вместо пароля его md5 отпечаток).

SSL или самодельная шифрация (можно с помощью яваскрипт, но в этом случае вас ничто не страхует перед хакером, если он случайно найдет алгоритм шифрации в яваскрипт (а он это сделает, зная страницу авторизации) ), впрочем от целенаправленной просллушки канала на конкретно этот логин/пароль вас вообще ничего не спасет.

madnet 28.08.2007 18:55
Dword, не тупи. Хэш предается вместо пароля лишь для того, что бы сложно было узнать сам пароль, который, коль ты заговорил о КОНЦЕПЦИЯХ БЕЗОПАСНОСТИ, должен быть максимально скрыт и от злоумышлеников и от администрации, в связи с очень частым использованием пользователями одинаковых паролей в разных системах.

по поводу твоего высказывания в адресс Ssl просто нечего сказать....

DWORD 28.08.2007 19:25
Цитата:
Dword, не тупи. Хэш предается вместо пароля лишь для того, что бы сложно было узнать сам пароль, который, коль ты заговорил о КОНЦЕПЦИЯХ БЕЗОПАСНОСТИ, должен быть максимально скрыт и от злоумышлеников и от администрации, в связи с очень частым использованием пользователями одинаковых паролей в разных системах.
Бред...
Цитата:
по поводу твоего высказывания в адресс Ssl просто нечего сказать....
А ты попробуй. Если канал прослушивается с целью получить конкретно пароль и логин, то злоумышленник имеет понятие и об организации шифрованного канала и обо всех ключах, которыми обменивается клиент и сервер, или может они ими по воздуу перекидываются?

DWORD 28.08.2007 19:32
Цитата:
Сообщение от madnet
что именно?
То что пароль заменяется на хэш, нет в этом никакого смысла. Это не шифрация а просто замена одного другим, а если при этом еще и забывать о том, что в базе должен быть хэш пароля, а не он сам и класть туда полученный md5, то это не просто не имеет смысл, но и создает дополнительные угрозы безопасности

Update: madnet удалил свой пост :(

madnet 28.08.2007 19:36
Dword, до тебя не доходит для чего в данном случае хэшируются пароли.

>если класть туда полученный md5, то это не просто не имеет смысл, но и создает дополнительные угрозы безопасности

нука нука, интересно чем же здесь опаснее чем простой пароль ложить в БД?

DWORD 28.08.2007 19:39
Цитата:
Сообщение от madnet
Dword, до тебя не доходит для чего в данном случае хэшируются пароли.
Видно надо вернуться с небес в реальность и понять что, если у тебя рыжий цвет ника и ты можешь понижать/повышать "репутацию", это вовсе не означает что ты всегда прав и можешь в категоричной форме рассказывать всякий бред/удалять свои сообщения и так далее. Я закончил.

madnet 28.08.2007 19:45
Цитата:
Сообщение от dword
Видно надо вернуться с небес в реальность и понять что, если у тебя рыжий цвет ника и ты можешь понижать/повышать "репутацию", это вовсе не означает что ты всегда прав и можешь в категоричной форме рассказывать всякий бред/удалять свои сообщения и так далее. Я закончил.
+))) ЛОЛ
не хотел тебя радовать раньш времени, но ты тоже можешь понижать/повышать "репутацию" и удалять свои сообщения.

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

NOmeR1 28.08.2007 20:11
Идея хорошая, можно ещё сделать немного подругому :)
PHP код:
<?

$site = 'http://ваш.сайт.ру' //именно в таком формате (без слеша в конце)

if(!preg_match('#^'.$site.'(.*)$#i',$_SERVER['HTTP_REFERER'])) {
 echo('Попробуйте зайти через сайт.');
} else {
 //если всё ок
}

?>

hidden 28.08.2007 21:42
На самом деле madnet прав, пароль не должен передаваться на сайт в открытом виде, хотя предложенные способы авторизации тоже могут не прокатить
js - Злоумышленнику не нужен пароль, у него и так есть то, что просит у него сервер, это хэш
ssl - Может защитить только если злоумышленник начнёт снифать трафик, после того как браузер принял сертификат, иначе у него и браузера одинаковые шансы получить всю передаваемую информацию.

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

Клиент обращается к серверу передовая логин: сервер достаёт из базы хэш пароля, генерирует блок рандомных данных длиной примерно 256 байт, возвращает его клиенту, тем временем шифрует его хэшью пароля, вычисляет из результата новую хэш и сохраняет её в сессионную переменную.
Клиент получает от сервера блок данных, так-же шифрует его хэшью пароля и так-же вычисляет из него новую хэш, с которой и обращается к серверу: сервер сравнивает полученные хэши и ауторезирует клиента в случае совпадения.
При смене пароля нужно снова провести всю эту операцию, за исключением того, что сервер уже знает логин.
При таком случае, даже если не использовать ssl и злоумышленник будет снифать весь трафик, ему потребуются сотни лет, чтоб сбрутить хэш от 256байтного блока, зашифрованного хэшью пароля.
Недостаток, время выполнения скрипта(ДоС-атаки), выход бан по ип.

Новый пароль, при смене пароля можно хэшировать и зашифровать хэшью старого, так как и клиент и сервер её знают.

ant0ha 28.08.2007 21:54
Цитата:
Сообщение от DWORD
Как можно передавать хэши паролей вместо самих паролей? Это не шифрование данных, потому что серверный обработчик получает ХЭШ, а не ПАРОЛЬ. А это значит, что система не только не защищает вас от прослушки трафика (т.к. в этом случае авторизация не через пароль, а через его хэш), но еще и разрушает основную концепцию безопасности авторизации в системах ограниченного доступа, т.к., имея доступ к базе данных, злоумышленник уже имеет фактически ПАРОЛЬ, а не ХЭШ и может в этих самых системах авторизовываться по нему (если вы конечно не храните в базе данных хэш от хэша, что вообщем никаким образом не умоляет бредовости идеи передавать вместо пароля его md5 отпечаток).

SSL или самодельная шифрация (можно с помощью яваскрипт, но в этом случае вас ничто не страхует перед хакером, если он случайно найдет алгоритм шифрации в яваскрипт (а он это сделает, зная страницу авторизации) ), впрочем от целенаправленной просллушки канала на конкретно этот логин/пароль вас вообще ничего не спасет.
Мда, лучше б ты промолчал, хоть сам то понял чего написал =\

KEZ 28.08.2007 22:14
Цитата:
SSL или самодельная шифрация (можно с помощью яваскрипт, но в этом случае вас ничто не страхует перед хакером, если он случайно найдет алгоритм шифрации в яваскрипт (а он это сделает, зная страницу авторизации) ), впрочем от целенаправленной просллушки канала на конкретно этот логин/пароль вас вообще ничего не спасет.
КОПАЙ! Могильничек а в нём амфора ПОООООЛНАЯ оксибутирата натрия!

DWORD 28.08.2007 22:24
Цитата:
Клиент обращается к серверу передовая логин: сервер достаёт из базы хэш пароля, генерирует блок рандомных данных длиной примерно 256 байт, возвращает его клиенту, тем временем шифрует его хэшью пароля, вычисляет из результата новую хэш и сохраняет её в сессионную переменную.
Клиент получает от сервера блок данных, так-же шифрует его хэшью пароля и так-же вычисляет из него новую хэш, с которой и обращается к серверу: сервер сравнивает полученные хэши и ауторезирует клиента в случае совпадения.
При смене пароля нужно снова провести всю эту операцию, за исключением того, что сервер уже знает логин.
При таком случае, даже если не использовать ssl и злоумышленник будет снифать весь трафик, ему потребуются сотни лет, чтоб сбрутить хэш от 256байтного блока, зашифрованного хэшью пароля.
Гениально! +++ Хотя вклиниться в текущее соединение по прежнему хакеру никто не мешает, если он сможет блокировать легального клиента и имеет возможность посылать пакеты серверу системы ограниченного доступа.

DWORD 28.08.2007 22:28
Хотя, ведь можно дальше шифровать трафик настоящим паролем, который теперь знает только клиент и сервер? Вообщем супер. А ты сам придумал?

iv. 28.08.2007 22:46
Цитата:
Хотя, ведь можно дальше шифровать трафик настоящим паролем, который теперь знает только клиент и сервер? Вообщем супер. А ты сам придумал?
Такие алгоритмы элементарно придумываются после прочтения книги товарища Шнаера "Прикладная криптография". Думаю, автор с ней знаком. :)

Единственное трезвое сообщение из всего топика кстати (2hidden).

DWORD 28.08.2007 22:55
Цитата:
Сообщение от iv.
Такие алгоритмы элементарно придумываются после прочтения книги товарища Шнаера "Прикладная криптография". Думаю, автор с ней знаком. :)
Да, к сожалению, ни с какой криптографической литературой не знаком (что собираюсь в скором времени исправить), поэтому мои посты в этой теме были направлены на указание ошибок(коими я их по прежнему считаю) предыдущих авторов, но ни как не на решение самой проблемы.

hidden 29.08.2007 02:39
Была одна книжка по криптографии, правда я от туда всего пару статеек прочёл, ИМХО(чтение книг вредно сказывается на глазах, читать надо только то, что действительно информативно и поможет в будущем)

Цитата:
Сообщение от DWORD
Хотя, ведь можно дальше шифровать трафик настоящим паролем, который теперь знает только клиент и сервер? Вообщем супер. А ты сам придумал?
Ага, как-то задумывался над способом авторизации, кстати, паролем ничего, ни в коем случае, нельзя шифровать, тем более html !!!, его можно будет вычислить статистически после первой же страницы ;)
Имеется ввиду пакеты длиной больше длины пароля, можно рассматривать способ разбиения страницы на пакеты, перемешивания их и добавления в каждый предыдущий пакет, пароль к следующему. В этом случае о XOR-шифровании не может быть и речь, лучше обмен байта по коду символа пароля. Хотя тоже не очень надёжно и очень не экономично.
Если надо защищать не пароль а страницы, то уж лучше ssl использовать.

madnet 29.08.2007 10:51
Цитата:
Сообщение от hidden
На самом деле madnet прав, пароль не должен передаваться на сайт в открытом виде, хотя предложенные способы авторизации тоже могут не прокатить
js - Злоумышленнику не нужен пароль, у него и так есть то, что просит у него сервер, это хэш
ssl - Может защитить только если злоумышленник начнёт снифать трафик, после того как браузер принял сертификат, иначе у него и браузера одинаковые шансы получить всю передаваемую информацию.

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

Клиент обращается к серверу передовая логин: сервер достаёт из базы хэш пароля, генерирует блок рандомных данных длиной примерно 256 байт, возвращает его клиенту, тем временем шифрует его хэшью пароля, вычисляет из результата новую хэш и сохраняет её в сессионную переменную.
Клиент получает от сервера блок данных, так-же шифрует его хэшью пароля и так-же вычисляет из него новую хэш, с которой и обращается к серверу: сервер сравнивает полученные хэши и ауторезирует клиента в случае совпадения.
При смене пароля нужно снова провести всю эту операцию, за исключением того, что сервер уже знает логин.
При таком случае, даже если не использовать ssl и злоумышленник будет снифать весь трафик, ему потребуются сотни лет, чтоб сбрутить хэш от 256байтного блока, зашифрованного хэшью пароля.
Недостаток, время выполнения скрипта(ДоС-атаки), выход бан по ип.

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

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

2)Что нам мешает перехватить результативный хэш, отправленый клиентом и находящийся в сессии у сервера и обратится с ним к серверу? Только ограничение по IP, но можно предположить, что имея доступ к трафику злоумышним может и подделать IP.

hidden 29.08.2007 12:18
Цитата:
Сообщение от madnet
Да так будет погиморойнее.
Сам пароль будет скрыт от хакера, но впринципе при снифании ничего не мешает:

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 на минуту...

Какие будут замечания по данному предложению?!

hidden 03.09.2007 08:51
Цитата:
Сообщение от GHostly_FOX
...
Какие будут замечания по данному предложению?!
А чего ты пытался добиться этим способом?

GHostly_FOX 03.09.2007 12:32
Я хочу предотвратить кражу хешей паролей и предотвратить любые возможности прослушивания портов...

TANZWUT 03.09.2007 13:36
сделай свою ф-ию алгоритма хеширования пароля, к примеру:

PHP код:
............
$pass=null;
        $abc="abcdefghjkmnpqrstuvwxyz".
             "ABCDEFGHJKLMNPQRSTUVWXYZ";

        $arr=explode(chr(32),trim(chunk_split($abc,1,chr(32))));
        $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']; 
........... 
PHP код:
................
// Функция Декодирования
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:+SSLv2:+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>
В чем проблемма?!
не идет загрузка =(

bopoh13 04.09.2007 13:05
[off]Дельная была идея сделать wiki для а-чата, а то я себя после этих сообщений полным ламером чувствую. Будет на что ссылаться...

http://slovari.yandex.ru/dict/informatica/article/info/info-490.htm?text=hash
[/off]

DIAgen 09.09.2007 13:38
Вот нашел статейку интересную
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
Цитата:
Сообщение от GreenBear

складывается впечатление, что у многих очень много ума, чтобы искать себе геморой на жопу. проще 5 символов сгенирировать и не парится.
А кто мешает применять при этом captcha-код??? :cool:

P.S.: При таком раскладе геморой будет не у тебя, а у того кто будет в таких дебрях разбираться...


Мы не ищем лёгких путей!!!

hidden 12.09.2007 06:59
2FoxMALDER, Не подскажешь нам, необразованным, зачем нам соль при авторизации?

FoxMALDER 12.09.2007 21:46
Цитата:
Сообщение от hidden
Не подскажешь нам, необразованным, зачем нам соль при авторизации?
Зачем тогда вообще использовать авторизацию?! Зачем пароль вообще каким-либо способом шифровать???

P.S.: Я вообще предложил применить в шифровании пароля так называемый salt, а как его альтернативу брать дополнительные данные которые всегда у каждого пользователя будут уникальными...

Для начала читай все посты, а потом рассказывай про свою образованость :D

hidden 15.09.2007 00:47
Цитата:
Сообщение от FoxMALDER
P.S.: Я вообще предложил применить в шифровании пароля так называемый salt, а как его альтернативу брать дополнительные данные которые всегда у каждого пользователя будут уникальными...
Зачем при авторизации уникальные данные, которые у каждого КОМПЬЮТЕРА будут разные???, что ими шифровать???
Цитата:
Сообщение от FoxMALDER
Зачем тогда вообще использовать авторизацию?! Зачем пароль вообще каким-либо способом шифровать???
Не надо отвечать вопросами на вопросы, ты просто скажи зачем при авторизации соль, пока-что я твои посты расцениваю как флуд-оффтоп...

GreenBear 15.09.2007 01:12
Цитата:
Мы не ищем лёгких путей!!!
ты не думал, что я захожу на сайт не только с одного компьютера?

FoxMALDER 15.09.2007 03:35
Цитата:
Сообщение от hidden
Зачем при авторизации уникальные данные, которые у каждого КОМПЬЮТЕРА будут разные???, что ими шифровать???
Ок! Перейду на твой язык восприятия... Добавить соль к паролю и защифровать.

Цитата:
Сообщение от hidden
Не надо отвечать вопросами на вопросы, ты просто скажи зачем при авторизации соль, пока-что я твои посты расцениваю как флуд-оффтоп...
Выше сказано было достаточно... Я предлагал, как АЛЬТЕРНАТИВНЫЙ метод... Если кому-то не нравится, я лично не навязываю такой способ никому!

Ответь на такой вопрос, нахрена тогда пароль в чистом виде шифровать в md5 и передавать на сервак?! Если lookup можно сделать не напрягаясь!

Давай перейдём на реальные вещи, для твоего понимания...
1) Открываю страницу авторизации, вижу форму: login, pass, captcha.
2) Ввожу login, pass, captha
3) Отправляю: login, md5(md5(captcha):md5(pass)), captcha

Это как пример соли в пароль, можно не именно так...

P.S.: Смысл уловил?! :cool:

ZaCo 01.11.2007 11:23
добавлю к hidden: мы, кстати говоря, вообще не обязаны передавать этот самый блок длинной 256 в открытом виде;) к прочтению
Код:
http://ru.wikipedia.org/wiki/Алгоритм_Диффи_—_Хеллмана


Время: 00:30