CC BY
201
УДК 004.032.26 ББК 32.818 В 58
Власенко А.В.
Кандидат технических наук, доцент кафедры компьютерных технологий и информационной безопасности института информационных технологий и безопасности, начальник управления аспирантуры и докторантуры Кубанского государственного технологического университета, Краснодар, e-mail: Vlasenko@kubstu.ru
Дзьобан П.И.
Аспирант института информационных технологий и безопасности Кубанского государственного технологического университета, Краснодар, e-mail: antiemoboy@mail.ru
Тимченко М.В.
Аспирант кафедры информационных систем и программирования института компьютерных систем и информационной безопасности Кубанского государственного технологического университета, Краснодар, e-mail: altezzatm@mail.ru
Разработка алгоритмов, инструментов и методов авторизации пользователей в Web-приложениях с использованием хеш-функций
(Рецензирована)
Аннотация. Разработка алгоритмов, инструментов и методов авторизации пользователей в Web-приложениях с использованием хеш-функций необходимы как для активной, так и для пассивной защиты данных идентификации и аутентификации пользователей разрабатываемого Web-приложения. Даже в случае утери авторизационных данных пользователем злоумышленнику не хватит временного ресурса на конвертацию их в исходный вид для дальнейшего использования, так как разработчик может регулировать время устаревания Cookie.
Ключевые слова: Web-приложения, идентификация пользователя, аутентификация, авторизация, коллизия, база данных, хеширование, криптостойкость.
Vlasenko А.У.
Candidate of Engineering Sciences, Associate Professor of Computer Technologies and Information Security Department, Institute of Information Technologies and Security, Chief of Post-Graduate and Doctorate Office, Kuban State University of Technology, Krasnodar, e-mail: Vlasenko@kubstu.ru
Dzoban P.I.
Post-graduate student of Institute of Information Technologies and Security, Chief of Post-Graduate and Doctorate Office, Kuban State University of Technology, Krasnodar, e-mail: antiemoboy@mail.ru
Timchenko M.V.
Post-graduate student of Information Systems and Programming Department of the Institute of Computer Systems and Information Security, Kuban State University of Technology, Krasnodar, e-mail: altez-zatm@mail.ru
Development of algorithms, tools and methods for user authentication in the Web-applications using hash functions
Abstract. Development of algorithms, tools, and methods for user authentication in the Web-applications using hash functions is necessary for both active and passive protection of data identifying and authenticating users of the developed Web-based applications. Even in the case of loss of authorization data by the user, the attacker will not have enough time resource to convert them into original form for future use because a developer can adjust the aging time Cookie.
Keywords: Web-application, user identification, authentication, authorization, collision, database, hashing, the cryptographic strength.
Большинство из актуальных классов атак на Web-приложения приходятся на этап авторизации пользователя, а именно процесс передачи идентификационных и аутенти-фикационных данных от пользователя к базе данных (БД) Web-приложения, минуя брандмауэры Web-приложения и различные системы защиты как программного, так и аппаратного уровня.
Одним из действенных приемов злоумышленника является получение данных ав-
торизации из Cookie, даже если данные будут в захэшированном виде. На этом этапе смысл любой защиты пропадает, но если работать только с сессиями (при закрытии браузера все идентификационные данные обнуляются), то каждый раз при входе на часто посещаемый сайт или Web-приложение придется вводить данные авторизации. Если учесть, что у большинства пользователей несколько почт, разных паролей и логинов, то такие меры по защите приведут к элементарной записи всех паролей и логинов пользователей на материальный носитель, что менее всего защищается и смысл в защите вообще исчерпывается [1]. Есть смысл работать и с Cookie, и с сессиями, грамотно распределив нагрузку. Представим форму, с помощью которой пользователь сможет передать нам свой логин и пароль на рисунке 1.
<form action-"login.php1 method="post">
<tdxinput type= "text" name=,Tlogin" /></td> <tdxinput type="password' name= passward" /></td> <tdxinput type="submit" value="BotiTM " /></td>
Рис. 1. Форма передачи пользователем пароля и логина
После ввода пользователем данных необходимо проверить его логин и пароль. Очевидно, данные авторизации не хранятся в чистом виде. Существуют различные как криптографические, так и некриптографические хеш-функции. Криптографические хеш-функции отличаются следующими условиями от остальных хеш-функций:
- стойкость к коллизиям 1-го рода - для какого-либо сообщения P должно быть невозможно в реальном времени подобрать другое какое-либо сообщение Q, для которого хеш-функция F(P)=F(Q);
- стойкость к коллизиям 2-го рода - должно быть невозможно в реальном времени подобрать такую пару сообщений (P, P'), хеш для которых одинаков;
- необратимость - для установленного значения хеш-функции A должно быть невозможно в реальном времени найти блок данных X, хеш-функция для которого F(X)=A.
Для проверки данных авторизации необходимо сравнить хеш введенного пароля с тем, что хранится в БД приложения, как представлено на рисунке 2.
Процесс хеширования пароля может проводиться с использованием алгоритма, которому отдаст предпочтение разработчик. Не стоит вникать в криптографическую реализацию всех хеш-функций, стоит обратить внимание на функции, к которым не найдены и не скомпрометированы коллизии. Например, алгоритм MD5 не актуален с 2013 года, а алгоритм bcrypt/scrypt остается актуальным. Если обратиться к российскому опыту, то для большинства проектов смена хеша на scrypt оказывается безболезненной. К примеру, многие банки для дистанционного банковского обслуживания все чаще выбирают решения, основанные на отдельном устройстве, которое генерирует хеши уже с заданной скоростью [2]. Значения скорости перебора хешей (в мегахешах в секунду), которые были получены на современной видеокарте AMD Radeon 7870, представлены в таблице 1.
Хеш из БД
Введенный пароль i "
Хеш-функция --
Рис. 2. Простой алгоритм процесса авторизации пользователя
Таблица 1
Значения скорости перебора хешей на современной видеокарте AMD Radeon 7870
Алгоритм хеширования Скорость перебора хеша (м/с)
MD5 13200
SHA-1 4800
SHA256 1580
SHA512 170
NTLM 26300
bcrypt 0,0075
На рисунке 3 представлена процедура сравнения хеша введенного пользователем пароля с хешом пароля, хранящегося в базе данных Web-приложения, используя самый простой алгоритм хеширования md5.
// то mi ставим об этан метку в сессии (допустим м>1 будем ставить ID пользователя)
// не забываем, что для работы с сессионным! данньми, у нас в каждом скрипте должно присутствовать session_start(>; diel'Такой логин с паролем не найдены в базе данных. И даём ссылку на повторную авторизацию.');
Рис. 3. Процесс сравнения хеша введенного пользователем пароля с хешом, хранящемся в БД Web-приложения
Ясно, что авторизованные пользователи - те, у которых указан $_SESSION['user_id']. Те пользователи, у которых отсутствует $_SESSION['user_id'],
будут гостями [1]. Пример дискриминирования посетителей Web-приложения или сайта приведен на рисунке 4.
// показываем защищенные от гостей данные.
die( Доступ закрыт, даём ссылку на авторизацию.1);
Рис. 4. Пример разделения посетителей на пользователей и гостей
Заметим, это аналог переменных, которые можно хранить у пользователя. Механизм их установки и получения следующий:
1. При запросе страницы браузером сервер формирует ответ, в заголовках которого указывает, что следует установить соответствующие Cookie.
2. Браузер получает ответ и сохраняет значения Cookie.
3. При последующем запросе страницы того же сайта браузер в заголовках запроса посылает Cookie на сервер.
Не стоит забывать, что Cookie хранятся у пользователя, и он может вносить коррективы. Пользователи браузера Firefox даже не обязаны обладать базовыми техническими знаниями - там Cookie можно просмотреть и изменить прямо в меню.
Большой процент некомпетентных пользователей, услышав про кражу Cookie и потерю личной информации, Cookie отключают, даже не разобравшись в сути вопроса, поэтому Cookie подходят для сохранения каких-либо настроек пользователя. Также Cookie используют для сбора общей усредненной статистики по достаточно большому количеству человек. Например, при отслеживании уникальных пользователей на сайте. Если их около 100000, то, скорее всего, подавляющее большинство не будет отключать или подделывать Cookie. Для хранения конфиденциальных данных они не подходят. Для авторизации пользователей подходят с оговорками. Например, после авторизации можно положить пользователю в Cookie его логин и на следующих страницах идентифицировать его уже по нему. Никакой трудности не составит, зайдя под логином "user", потом исправить соответствующую cookie на "admin". Обычно же в Cookie кладут идентификатор сеанса, представляющий собой случайную 32-разрядную строку. Тут уже надежды на то, что пользователь не сможет подобрать чужой идентификатор, значительно выше.
Еще один момент - число Cookie одного сайта ограничено (обычно пара десятков). Их суммарный объем также ограничен (несколько килобайт). Поэтому хранить много информации не получится. Если это необходимо, можно использовать Cookie для идентификации пользователя, а связанную с этим пользователем информацию хранить на сервере в захешированном виде.
В PHP Cookie устанавливаются функцией setCookie(). Ее параметры: name - имя Cookie; value - значение (установка пустой строки, позволяет удалить уже существующую Cookie); expire - время (unix-формат) устаревания Cookie. Установка времени меньше текущего также позволяет удалить Cookie. Важно, что это именно время устаревания, а не время жизни. То есть для установки Cookie на час следует делать так, как представлено на рисунке 5:
Код: PHP
setCookie "cook", "value". setCookie "cook", "value". time 3600); + 36003; // Правильно // Неправильно
Рис. 5. Установка времени устаревания Cookie на 1 час
Сессии не постоянны и данные в них хранятся только на время работы пользователя со скриптом. Поэтому, чтобы пользователь оставался залогиненым после того, как он закрыл и снова открыл Web-приложение, необходимо сохранить его авторизационные данные в Cookie (они хранятся на его компьютере в браузере). Запишем в Cookie пользователя его логин и хеш хеша пароля - для более полной криптостойкости. Представим на рисунке 6 скрипт по проверке пользовательских данных в Cookie:
// то пробуем авторизовать пользователя по этим логину и параш
// то ai ставим об этом метку в сессии (допустим л»/ будем ставить 1С пользователя)
// не забываем, что для работы с сессионным данньми, у нас в каждом скрипте должно присутствовать session_Btart();
Рис. 6. Скрипт Php по проверке пользовательских данных в Cookie
Следует заметить, что на данном скрипте метка в сессии пользователя ставится по ID-пользователя, который меняется при каждом посещении Web-приложения или сайта [3]. Так же следует уделить внимание безопасному хранению паролей в базе данных. Пароль не следует хранить в открытом виде. Всегда существует опасность SQL инъекции, при которой злоумышленник может получить авторизационные данные, но уже в захешированном формате (например, с помощью алгоритма md5()) несколько раз -именно поэтому стоит отвести на пароль 32 символа. И следовательно, при авторизации сравниваются не пароли, а их хеши хешов. В данном примере сравним md5 (md5 ('введенного пароля')) с хэшем хеша пароля, хранящимся в БД Web-приложения. Пароль можно подобрать по его хешу, зная алгоритм хеширования. Существует много баз, где пароли сопоставлены с их хешами. Поэтому можно заметно усложнить задачу злоумышленникам, которые соберутся подбирать пароль по его хешу, используя двойной хеш (например, md5(sha1('password'))), или использовать так называемую «соль» (salt). Пример использования соли: md5(md5('password'). 'secret_code'); secret_code - это и есть соль - к паролю добавляем набор символов однообразного формата с хеширо-ванным паролем, заданный по случайному алгоритму, который можно менять раз в заданный период для увеличения криптостойкости.
Также помимо соли и и-разового хеширования пароля актуально в разработанной методике, с учетом повышенного интереса злоумышленников к таким видам атак, использовать дополнительные инструменты:
- зависимый хэш - зависит от уникальной переменной (например, логина);
- фарш - перемешать значение хэша;
- интеллектуальный хэш - хэш меняет алгоритм в зависимости от длины и значений. Представим на рисунке 7 алгоритм, с учетом разработанных дополнительных инструментов усиления хеша:
Данные пользователя в БД
Рис. 7. Усложненный алгоритм усиления хеша пароля Web-приложения
Для разработанного усиленного метода хранения пароля необходимо изменить таблицу БД с пользователями, как представлено на рисунке 8:
id smallint(B> unsigned WOT HULL auto_inerenient, login varchar[ 50) NOT MULL default '', password varchar[32 J WOT WULL default salt varchar(3) WOT NULL default ''
Рис. 8. Изменение таблицы БД Web-приложения для использования разработанного
метода хэширования пароля
В нашем примере будем использовать соль из 3-х символов. Для каждого пользовательского пароля (при его регистрации) необходимо генерировать свою соль и записывать в БД рядом с паролем, чтобы использовать при хешировании [4]. Рассмотрим пример:
- регистрируем пользователя: md5 с паролем password и солью 8f*;
- получаем его хеш, используя md5(md5('password') . '8f*');
- записываем пользователя в таблицу, получаем: 1 | md5 | 84cd3e7ff13bbaed1c1db91671844bcc | 8f*
При входе пользователя через форму немного изменим наш код, который представлен на рисунке 9.
// дня начала вытащим из таблицы с пользователями соль для логина, который был введен // итак, вот она соль, соответствующая этому логину:
// теперь хешируем введенный пароль как надо и повторям шаги, которые были описаны выие:
die('пользователь с таким логином не найден, даём ссылку на повторную авторизацию 1);
Рис. 9. Измененный вход пользователя через форму, с учетом разработанной методики
Таким образом, используя усиленную разработанную методику авторизации пользователей Web-приложений с помощью и-разового хеширования с разными алгоритмами и разбавлением хеша энтропией, используя инструмент «salt» - соль, значительно увеличивается криптостойкость передаваемых данных от пользователя к БД Web-приложений.
Примечания:
1. Кузнецов С. Д. Базы данных. Модели и языки. М.: Бином-Пресс, 2008. 720 с.
2. Веденьев Л.Т., Афанасьев А.А., Афанасьев А.Н. Аутентификация. Теория и практика обеспечения безопасного доступа к информационным ресурсам. Учебное пособие для вузов. Гриф УМО МО РФ. 2-е изд. 2012. 552 с.
3. Молдовян А.А., Зима В.М., Молдовян Н.А. Безопасность глобальных сетевых технологий. 2-е изд. 2014. 362 с.
4. Колисниченко Д.Н. PHP и MySQL. Разработка Web-приложений. 5-е изд. 2015. 593 с.
References:
1. Kuznetsov S.D. Database. Models and languages. M.: Binom-Press, 2008. 720 pp.
2. Vedenyev L.T., Afanasyev A.A., Afanasyev A.N. Authentication. Theory and practice of provision of secure access to information resources: a manual for higher schools. The 2nd ed. 2012. 552 pp.
3. Moldovyan A.A., Zima V.M., Moldovyan N.A. Security of global network technologies. The 2nd ed. 2014. 362 pp.
4. Kolisnichenko D.N. PHP and MySQL. Development of Web-applications. The 5th ed. 2015. 593 pp.
