| |
|
|
| | Вообщем с заказчиком возникла проблема, он считает что сессии безопаснее basic-аутентификации. По его просьбе прикрепил к этому всему айпи. Вот что получилось(в части басик аутентификации(за сессии вообще браться не хочу))
<?
function GetRealIp() // определение ip пользователя
{
$strRemoteIP = $_SERVER['REMOTE_ADDR'];
if (!$strRemoteIP) { $strRemoteIP = urldecode(getenv('HTTP_CLIENTIP'));}
if (getenv('HTTP_X_FORWARDED_FOR')) { $strIP = getenv('HTTP_X_FORWARDED_FOR'); }
elseif (getenv('HTTP_X_FORWARDED')) { $strIP = getenv('HTTP_X_FORWARDED'); }
elseif (getenv('HTTP_FORWARDED_FOR')) { $strIP = getenv('HTTP_FORWARDED_FOR'); }
elseif (getenv('HTTP_FORWARDED')) { $strIP = getenv('HTTP_FORWARDED'); }
else { $strIP = $_SERVER['REMOTE_ADDR']; }
if ($strRemoteIP != $strIP) { $strIP = $strRemoteIP.", ".$strIP; }
return $strIP;
}
$ip = "тут айпишник";
if(GetRealIp() != $ip){exit('<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head><meta http-equiv="Content-Type" content="text/html; charset=windows-1251" /><title>Не совпали айпи</title>
</head><body>IP не совпадает</body></html>');}
$db = mysql_connect ("","","");//подключение к базе
mysql_select_db("base",$db);
if (!isset($_SERVER['PHP_AUTH_USER']))
{
Header ("WWW-Authenticate: Basic realm=\"Admin Page\"");
Header ("HTTP/1.0 401 Unauthorized");
exit();
}
else {
$_SERVER['PHP_AUTH_USER'] = mysql_escape_string($_SERVER['PHP_AUTH_USER']);
$_SERVER['PHP_AUTH_PW'] = md5(mysql_escape_string($_SERVER['PHP_AUTH_PW']));
$query = "SELECT id,pass FROM admin WHERE user='".$_SERVER['PHP_AUTH_USER']."'";
$lst = @mysql_query($query);
if (!$lst)
{
Header ("WWW-Authenticate: Basic realm=\"Admin Page\"");
Header ("HTTP/1.0 401 Unauthorized");
exit();
}
if (mysql_num_rows($lst) == 0)
{
Header ("WWW-Authenticate: Basic realm=\"Admin Page\"");
Header ("HTTP/1.0 401 Unauthorized");
exit();
}
$pass = @mysql_fetch_array($lst);
if ($_SERVER['PHP_AUTH_PW']!= $pass['pass'])
{
Header ("WWW-Authenticate: Basic realm=\"Admin Page\"");
Header ("HTTP/1.0 401 Unauthorized");
exit();
}
$dostup = $pass['id']; //тут определяем что за пользователь и даем ему соответствующие права
}
|
Клиент говорит что он работает в локальной сети из примерно еще 200 машин, все эти машины имеют выход в инет через обычный adsl. Вообщем заказчик очень боиться "сниферов" как он выразился(кражи данных в пределах текущей сессии). Требует чтоб я сделал аутентификацию по сессии.
Но(как мне кажеться) идентификатор сессии утащить гораздо проще из кук и даже если я прикручу по айпи админа, то это не даст результата так как остальные компьютеры находящиеся в этой локалке будут иметь тот же айпишник при выходе в инет(один adsl на всех)
Если я не прав обьясните пожалуйста в чем, если я прав докажите пожалуйста клиенту почему(в дальнейшем дам ссылку на этот топик) | |
| |
|
|
| |
|
|
| |
для: tvv123456
(20.12.2009 в 04:22)
| | | Если клиент боится сниферов, то нужен совсем не этот механизм. И сессии тут вообще непричем. Нужно шифровать или хэшировать данные на стороне клиента, тогда перехват станет бесполезен. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(20.12.2009 в 10:34)
| | | Хеш сам по себе не представляет ценности. А реализовывать шифрование на клиенте глупо, так как вся логика шифрования открыта. | |
| |
|
|
| |
|
|
| |
для: Саня
(20.12.2009 в 11:08)
| | | Хеш сам по себе не представляет ценности
К чему это сказано?
А реализовывать шифрование на клиенте глупо, так как вся логика шифрования открыта.
Это смотря как шифровать. SSL тоже шифрует. Другой вопрос что хэшировать легче. Хотя не всегда надежнее. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(20.12.2009 в 12:12)
| | | Какой смысл от хеша в данном случае?
Хеш не является заменой шифрованию. Это, по сути, разные технологии для разных задач. | |
| |
|
|
| |
|
|
| |
для: Саня
(20.12.2009 в 12:44)
| | | Какой смысл от хеша в данном случае?
Человек боится, что у него перехватят данные, как какой смысл? Такой же как и везде, не дать жулику возможности узнать их.
Хеш не является заменой шифрованию. Это, по сути, разные технологии для разных задач.
Я знаю, что не является. И знаю что для разных. Однако в данном случае задачу можно решить обоими способами. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(20.12.2009 в 15:02)
| | | > Человек боится, что у него перехватят данные, как какой смысл?
По-вашему данными, нуждающимися в защите, является только пароль? | |
| |
|
|
| |
|
|
| |
для: Саня
(20.12.2009 в 16:01)
| | | В контексте данного вопроса - да. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(20.12.2009 в 16:46)
| | | В контексте данного вопроса заказчик хочет получить защиту всех данных, передаваемых между сервером и компьютером клиента.
Надеюсь не нужно объяснять что такое сниффинг и почему хеширование пароля ему не помешает? Система аутентификации никак не может решать задачу защиты данных. | |
| |
|
|
| |
|
|
| |
для: Саня
(20.12.2009 в 16:51)
| | | Аспект, затронутый в данном вопросе, касался исключительно аунтификации. Даже тема так называется. Все остальные предположения, чего и как боится заказчик, остаются за кадром. Как собственно и сам вопрос о защите данных. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(20.12.2009 в 17:25)
| | | [поправлено модератором] | |
| |
|
|
| |
|
|
| |
для: Fractured#
(20.12.2009 в 17:30)
| | | Я не трудный, просто иногда не понимаю, зачем пытаться исковеркать мои ответы. И тем более придавать им статус глупых.
В вопросе топикстартера небыло ни слова про защиту данных, не относящихся к аунтификации. И SSL здесь может оказаться совершенно излишним, тем более он платный.
Допустим это панель администрирования, где совершенно не важна информация как таковая, а важен именно доступ к скрипту, изменняющему эти данные. Сниффинг тут не имеет никакого смысла, если невозможно получить пароль доступа. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(20.12.2009 в 18:11)
| | | SSL не платный. Чтобы сгенерировать сертификат, особых знаний, за которые нужно платить, не потребуется. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(20.12.2009 в 17:25)
| | | Ладно. Попробую объяснить на пальцах.
Вот я перехватил хеш пароля.
Захожу на страницу логина, отключаю JS, ввожу логин, перехваченный хеш...
И что дальше произойдёт? | |
| |
|
|
| |
|
|
| |
для: Саня
(20.12.2009 в 18:03)
| | | Это зависит от реализации. Смотря как хэшировать. Допустим с солью, со случайной строкой, которая действует в пределах данной сессии. Следующий ввод этого хэша ничего не даст, потому что он состоит из двух частей - серверной и клиентской. И если серверную можно перехватить, то клиентскую уже нет. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(20.12.2009 в 18:22)
| | | Тогда прийдётся хранить пароли в открытую. А это потенциально опасно. Особенно со стороны вполне невинных администраторов базы данных. Ведь часто люди используют один пароль на все сервисы. Порой достаточно получить доступ к основному мылу, на которое можно "Забыть пароль" во всех интересующих сервисах. | |
| |
|
|
| |
|
|
| |
для: Саня
(20.12.2009 в 18:42)
| | | Тогда прийдётся хранить пароли в открытую.
Не факт. Точно так же можно хранить и хэш.
Я же говорю, все зависит от потребностей. возможностей и вообще конкретных условий. Использовать HTTPS для сокрытия пароля как минимум нерентабельно, даже если не покупать сертификат, а слепить самому. Просто по скорости.
А если там действительно есть что прятать, то тогда да. Может и этого протокола нехватить)) | |
| |
|
|
| |
|
|
| |
для: Николай2357
(20.12.2009 в 19:00)
| | | Если соль не меняется при каждой аутентификации, то тогда нет смысла городить этот огород. Опять же, снифаем соль, хеш. Подставляем эти данные в форму и вуаля!
Но если соль изменяется, тогда обязательно нужно знать пароль. Или любую другую строку, дающуюю коллизию с паролем :). | |
| |
|
|
| |
|
|
| |
для: Саня
(20.12.2009 в 19:10)
| | | Ну а чем хэш пароля не коллизия? Зачем именно в явном виде хранить? | |
| |
|
|
| |
|
|
| |
для: Николай2357
(20.12.2009 в 19:11)
| | | Коллизия — это строка (или не строка), не совпадающая с исходной, и дающая такой же хеш как и исходная строка. Вероятность нахождения этой строки микроскопическая.
> Зачем именно в явном виде хранить?
Вот примерный алгоритм использования изменяемых солей:
С. генерируем случайную соль и запоминаем (в БД, файлы, сессию... куда угодно на сервере)
К. вводит пароль и отправляет серверу соль и хеш-функция(соль+пароль)
С. смотрит что за соль и есть ли она у него в памяти. Если есть, достаём по введённому логину пароль и сравниваем хеш-функция(соль из памяти + пароль из базы). Сразу после этой операции удаляем соль из памяти, чтобы нельзя было воспользоваться ей второй раз. | |
| |
|
|
| |
|
|
| |
для: Саня
(20.12.2009 в 19:18)
| | | Вот другой алгоритм:
С. генерируем случайную соль и запоминаем (в БД, файлы, сессию... куда угодно на сервере) обозначив принодлежность к логину. Её же передаем клиенту.
К. вводит пароль и отправляет серверу хеш-функция(соль и хеш-функция(пароль))
С. смотрит соответствие отпечатка хеш-функция(соль конкретного юзера и хеш пароля из базы) Сразу после этой операции удаляем соль из памяти, чтобы нельзя было воспользоваться ей второй раз.
Вот и вся коллизия. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(20.12.2009 в 19:00)
| | | > Использовать HTTPS для сокрытия пароля как минимум нерентабельно
В чём же нерентабельность?
Так же не следует забывать, что шифруются и передаваемые страницы, которые могут содержать приватный контент. | |
| |
|
|
| |
|
|
| |
для: Саня
(20.12.2009 в 19:39)
| | | Нерентабельность в скорости и трафике, я же написал. Если данные не приватны, то нет смысла пользовать такой неповоротливый протокол. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(20.12.2009 в 19:59)
| | | Откуда такие данные? | |
| |
|
|
| |
|
|
| |
для: Саня
(20.12.2009 в 20:03)
| | | В смысле неприватные?))) Ну ведь реально медленный протокол, неужели и это будет оспариваться.... | |
| |
|
|
| |
|
|
| |
для: Николай2357
(20.12.2009 в 20:10)
| | | В смысле про траффик и медлительность.
> Ну ведь реально медленный протокол, неужели и это будет оспариваться....
Что-то я не замечаю этих эффектов при работе с gmail. | |
| |
|
|
| |
|
|
| |
для: Саня
(20.12.2009 в 20:16)
| | | А я очень замечаю. Причем на столько, что нервов нехватает. Это наверное еще от каналов зависит и провайдера. Но факт есть факт. В любом случае на шифрование страницы требуется время. | |
| |
|
|
| |
|
|
| |
для: tvv123456
(20.12.2009 в 04:22)
| | | Предложите ему SSL. | |
| |
|
|
| |
|
|
| |
для: tvv123456
(20.12.2009 в 04:22)
| | | Напишите заказчику вот что:
При использовании basic аутентификации логин с паролем передаются открытым текстом в каждом запросе к серверу.
При аутентификации на сессии, логин с паролем передаются один раз в начале сессии и назначается некий идентификатор, по которому сервер определяет кто к нему пришел за очередным запросом.
В обоих случаях передаваемые аутентификационные данные, что логин-пароль в basic, что идентификатор сессии, никак не шифруются и злоумышленнику достаточно отснифать ОДИН запрос клиента (любой в basic'е или первый при сессиях), чтобы получить логин-пароль (и как бонус — идентификатор сессии, позволяющий здесь и сейчас влезть в сессию... если она ещё жива, конечно). Это фатально что в одном, что в другом случае.
Очевидно, что basic аутентификация сосёт, так как данные передаются открыто в каждом запросе.
Но даже если менять пароль каждую минуту или придумать хитронакрученную систему аутентификации, это не спасёт. Потому что сниффер будет складывать себе все данные, передающиеся между целевым клиентом и сервером. А так как они не шифрованные, то злоумышленник увидит содержимое всех страниц, которые вы посещали.
Выходом из этой ситуации может стать использование SSL. | |
| |
|
|
| |
|
|
| |
для: Саня
(20.12.2009 в 17:59)
| | | Вот про SSL и хотел услышать. Пытался убедить, что это лучшее решение, но мне не очень верили.
Спасибо за ответ.
P.S. Клиент нашел сам способ защититься от злоумышлеников в локалке(купил три джи модем) и выходит в админку только с него отключившись от локалки :))) | |
| |
|
|
| |
|
|
| |
для: tvv123456
(20.12.2009 в 18:43)
| | | Сурово. | |
| |
|
|
| |
|
|
| |
для: tvv123456
(20.12.2009 в 18:43)
| | | Можно усилить его паранойю. Пусть в коммандной строке выполнит
И увидит в скольких точках возможен сниффинг его данных :)
* Вместо example.com нужно поставить домен, на котором находится админка | |
| |
|
|
