РегистрацияПротокол защищенной HTTP-авторизации
Предлагаю реализацию протокола, идею которого предложил SATtva.
Ознакомиться с оригинальной идеей можно здесь "Защита HTTP-авторизации без SSL?".
Возможно, я частично продублирую изложенный в указанной статье материал. И все же это необходимо сделать для лучшего описания реализации протокола.
Так же есть реализация для "CMS Joomla!", доступна по адресу http://joomlaforum.ru/index.php/topic,11428.0.html
Условные обозначения
A – пользователь.
B – сервер.
u – идентификатор (имя) пользователя.
p – пароль пользователя.
p_h – хеш пароля.
p6 – хеш пароля хранимый в base.php.
ip1 – ip-адрес определенный сервером на 1 этапе протокола.
ip4 – ip-адрес определенный сервером на 4 этапе протокола.
k – секретный показатель, известный только B.
t1 – метка времени начала исполнения протокола.
H() – операция хеширования.
Описание сценариев и файлов
initialization.php – страница инициализации протокола.
form.html – форма для ввода имени имени и пароля.
webtoolkit.md5.js – java-скрипт клиентской стороны.
login.php – сценарий обработки формы для ввода имени и пароля.
validate.php – сценарий проверки имени и пароля по базе данных (base.php).
base.php – файл с зарегистрированными пользователями и их паролями (пароли в хешированном виде).
config.php – конфигурационный файл.
initialization.php
В момент открытия этой страницы пользователем A происходит инициализация протокола.
Еще до загрузки формы для ввода имени и пароля (form.html) этот сценарий проделывает следующие операции:
- открывает гостевую сессию со следующими параметрами:
- ip-адрес пользователя;
- временная метка начала протокола;
- генерирует r=H(k, t1, ip1);
Далее, когда все необходимые операции проведены, на клиентскую сторону передается java-скрипт webtoolkit.md5.js и форма form.html.
Форма, помимо полей для ввода и кнопки, содержит скрытое поле r_type, в которое записывается сгенерированное сервером r.
- передача на сторону клиента form.html и webtoolkit.md5.js;
Теперь A видит форму и может ввести u и p.
webtoolkit.md5.js
Загруженный клиенту webtoolkit.md5.js перехватывает событие нажатия кнопки.
- При нажатии кнопки берет значения полей p_type (пароль) и r_type.
- Вычисляет p_h=H(u).
Операция H(u) производится т.к. в базе паролей на сервере (base.php) хранятся не сами пароли, а их хешированные значения. Возможно это бесполезный "наворот", т.к. в этом случаи получается, что роль паролей играют их хешированные значения.
Т.е. пользователь мог бы вводить как пароль значение хеша (идентичного хранимому в base.php) и тогда операцию H(u) можно было бы не производить. Однако в этом случае все пароли должны были бы быть длинной 128 бит (если используется md5). (Дайджест любого сообщения прошедшего md5 имеет длину 128 бит.)
- Вычисляет h=H(r, p_h, p). Записывает h в r_type.
- Очищает поле в которое введен пароль p_type.
- Отправляет форму (возвращает событие).
Теперь начинается следующий этап протокола (в статье "Защита HTTP-авторизации без SSL?" 4 этап).
login.php
- сценарий проверяет, стартовала ли гостевая сессия, если да то исполнение сценария продолжается;
- берет из переменных сессии t1';
- определяет интервал между текущим временем и временем начала использования протокола. Если интервал не превышен, исполнение протокола продолжается;
- В отправленной форме сценарий получает u.
Сценарий login.php передает идентификатор пользователя (u) сценарию проверки имени и пароля по базе данных validate.php.
- Если validate.php возвращает не 0, то определяет ip4.
- Вычисляет h'=H(H(k, t1, ip4), u4, p6).
- Сравнивает значения h и h'
- Если значения совпали присваивает A идентификатор авторизованной сессии sid'.
initialization.php
<?php
/*
протокол авторизации MAS
*/
session_start();
/*Праметры неавторизованной гостевой сессии*/
$_SESSION['nominee']='guest'; //индентификатор неаторизованной гостевой сессии (sid)
$_SESSION['ip']=getenv ("REMOTE_ADDR"); //определение и запись ip-адреса пользователя (ip1)
$_SESSION['timestamp']=time(); //временная метка начала протокола (t1)
require "config.php"; //подключение конфигурациоонного файла
/*вычисление хеша*/
$r = md5($k.$_SESSION['timestamp'].$_SESSION['ip']);
/*Вывод формы и передача скрипта*/
require "form.html";
echo $r;
echo " | ";
echo md5('user1_password');
echo " | ";
echo $REMOTE_ADDR;
?>
form.html
login.php
<?php
/*
протокол авторизации MAS
*/
/*Проверка старотвала ли гостевая сессия*/
if (! isset( $_REQUEST[session_name()] ))
{
echo "сессия не стартовала";
exit;
}
session_start(); //стартуем сессию
require "config.php"; //подключаем конфигурационный файл
/*Проверка получен ли ответ в допустимом временном интервале*/
if ( (time() - $_SESSION['timestamp']) > $access_interval)
{
echo "превышен временной интервал ответа";
exit;
}
/*Извлечение хеша пароля из БД*/
require "validate.php"; //подключаем файл с функцией для извленчения хеша пароля
if (validate($name) == "NULL")
{
echo "пользователь с таким именем не зарегистрирован";
exit;
}
if ( md5( md5($k.$_SESSION['timestamp'].$_SESSION['ip']).$name.validate($name)) == $r_type)
{
echo "Вы авторизированы";
exit;
}
echo "Пароль не тот";
?>
webtoolkit.md5.js
validate.php
<?php
function validate($name){
require "base.php";
if (!isset($base[$name])){
return "NULL";
}
return $base[$name];
}
?>
config.php
<?php
$k = "server_secret"; //секретный показатель, известный только серверу
$access_interval = 60; //временной интервал в течении которого должен быть получен ответ, в секундах
?>
base.php
В оригинале статьи файл имел расширение .txt, что позволяло тривиально считать его содержимое, просто открыв его в браузере (если только файл не лежал за пределами публичной дериктории сервера).
SATtva (30/03/2007 13:16)
<?php
$base['user1'] = "b4ca6e90dcef1196a20930c2d9ecfbc0";
?>
– в базе должны лежать хэши
– клиент должен передавать пароль в чистом виде
– канал должен быть зашифрован
почему эта схема вдруг стала считаться дорогой – не понятно. vps нынче дешевые.
просто ради спортивного интереса: почему "в хешированном виде"?
комментариев: 11558 документов: 1036 редакций: 4118
касательно хэшированых паролей
по неизвестной мне причине, вы сами в своей же реализации не считаете безопасным хранить в базе чистые пароли. НЕТ ЧИСТЫМ ПАРОЛЯМ © SATtva!
с другой стороны, я уже достаточно обосновал тот факт, что предложенная схема эквивалентна хранению паролей в чистом виде. с моими доводами уже и spongebob согласился бы. честно-честно-честно.
итого: написано одно, а на деле выходит другое.
я клоню к тому, что вместо того, чтобы ворчать, надо ПРЯМО, в тексте статьи, предупредить читателей о том, что я написал. статья ведь сидит в разделе "разработки", а не "отвлеченные от практики размышления". кто-то использует, как ГОТОВОЕ решение, и потом как-то вдруг...
Сути не меняет
комментариев: 11558 документов: 1036 редакций: 4118
О какой реализации речь?
А вы посмотрите, какая аннотация приведена к самому разделу. Это всё PoC, не более.
P. S.
Не, я согласен проверять IP клиента и время нужно, но нах их использовать в хэше?...
Мне кажется, что ценность этой схемы в любом случае нулевая, потому что трафик не подписывается и злоумышленник может изменить сам скрипт, который исполняется на стороне клиента, чтобы тот отправлял ему пароль.