|
Введение.
В этой статье я опишу многие проблемы стандартного алгоритма авторизации и некоторые методы их устранения.
1. Коллизии алгоритмов хэширования.
Как известно, повсеместно применяющиеся алгоритмы md5 и sha1 обладают проблемой наличия коллизий [повторов], т.е. для разных аргументов функции, производящей хэширование, может сгенерироваться одинаковый хэш. Как бороться с этим ? Получается, что сложный 16-24-значный пароль и простой 6-значный могут иметь одинаковый хэш и при авторизации взломщик, нашедший коллизию, сможет зайти как легальный пользователь, и большой пароль со спецсимволами уже не помешает. Я предложу такой выход из этой ситуации – проверять количество символов в пароле на соответствие введенному при регистрации. Тут, конечно, тоже может быть коллизия, так как их число немного увеличивается при очень большом пароле, но вероятность подбора стремится к нулю, ввиду того что текущие вычислительные мощности рядового взломщика не позволяют ему обнаружить такие коллизии. Всем вышесказанным мы осуществляем достаточно мощную защиту от брутфорса.
А реализуется это все очень просто – например из такой проверки:
if(makehash($_POST[‘password’])==file_get_contents(‘users/’.secure($_POST [‘username’]).’/hash’))
$logged_in=1;
else
$logged_in=0;
Сделаем такую:
if(makehash($_POST[‘password’]) == file_get_contents(‘users/’.secure($_POST [‘username’]).’/hash’) && strlen($_POST[‘password’]) == file_get_contents(‘users/’.secure($_POST [‘username’]).’/passlen’)
$logged_in=1;
else
$logged_in=0;
Здесь makehash() – функция, производящая хэширование, secure() – функция, вырезающая вредоносный код и запрещенные спецсимволы из строки.
В дополнение к этому методу можно также записать один из символов в пароле и его место в нем – также проверять по нему.
2. Борьба с XSS.
XSS-атаки изначально базируются на передаче содержимого cookie-файлов на скрипт-сниффер [вообще некорректно называть его сниффер, так как он пишет то что прийдет к нему а не то что проходит мимо)))]. Так почему бы в ущерб удобству программирования в скрипте, требующем особой безопасности, а в них длительность сессии не требуется, отказаться от использования cookie? Сделать например так – сформировать некоторый хэш, зависящий от всей информации, которую возможно получить о клиенте, и при соответствии хэш-функция(параметры клиента) == хэш, считать, что кукисы авторизации существуют и верны.
Пример такой хэш-функции:
function makeClhash()
{
$data.=getenv(‘REMOTE_IP’);
$data.=getenv(‘HTTP_ACCEPT’);
$data.=getenv(‘HTTP_USER_AGENT’);
$data.=getenv(‘HTTP_X_FORWARDED_FOR’);
return sha1($data);
}
Теперь если проверять на соответствие записанному в файл старому хэшу, сформированному при авторизации, информацию, получаемую каждый раз от клиента, можно удостовериться, что все нормально и это тот клиент за которого себя выдает.
Этот метод отнюдь не универсален и имеет недочеты, ведь мы не сможем проверять, как обычно, что пароль доступа верный. Поэтому стоит комбинировать его с использованием cookie.
Заключение.
Вот и все, как только придумаю еще чего – сразу напишу где нибудь об этом. А сейчас – The END.
|
