Защита веб-сайтов паролем

05.03.2007

Иногда при создании сайта возникает необходимость разработки системы защиты веб-приложений.

Парольная защита – не единственный способ проверки подлинности, но на данный момент самый привычный и используемый.

Первая задача, которая стоит перед разработчиком системы безопасности – это надёжная аутентификация пользователя.

При выборе парольного способа у разработчика остаётся мало возможностей для манёвра.

Для работы у него есть поля: логин и пароль. Иногда к этому может добавляться поле ввода домена, фирмы, подразделения.

В большинстве случаев логин и любое дополнительное поле (фирма и прочее) известны широкому кругу лиц, и реально конфиденциальным является только пароль. При этом пароль не может быть сложным.

Единственное, что может требовать разработчик от пользователей – периодически менять пароль на другой, удобный пользователю. И, фактически, вся система защиты строится на способе обмена идентификационными данными и политике работы пользователей в системе.

1. Прежде всего – это защищённая передача данных пользователя. Идеально использование SSL, но, к сожалению, не всегда возможно.

Простое хеширование по алгоритму md5 и передача сейчас не рассматриваются, т. к. не являются наиболее надёжным способом. Намного грамотнее использовать HMAC. Данный метод позволяет хешировать и передать данные, позволяя защититься от подборки исходных пользовательских данных в случае одностороннего перехвата (передача данных от клиента к серверу).

2. Использование виртуальной клавиатуры уменьшает возможность перехвата данных клавиатурными шпионами.

3. Блокировка пользователя после некоторого числа неудачных попыток входа. Резко снижает вероятность взлома пароля путём перебора или брутфорса.

4. Смена идентификатора пользователя в системе (сессии) после аутентификации.

5. Привязка пользователя к текущему клиенту.

Решается посредством привязки к IP и браузеру. Это сводит к минимуму ущерб от похищения идентификатора сессии пользователя.

6. В самой сессии со стороны пользователя отсутствие каких-либо данных, кроме её идентификатора.

7. Запрос повторной аутентификации пользователя после некоторого числа минут неактивности.

8. Система привязки пользователей к конкретным IP/дням/времени работы.

9. Принципиальная невозможность работы с системой через прокси-сервера.

Особенно актуально в случае работы без SSL, но, к сожалению, в ряде случае отследить невозможно.

10. Самое важное – постоянный контроль работы системы.

Вход и выход пользователей, блокировки, неверный ввод пароля, перебор, сканирование на уязвимости и так далее – возможности ограничены только фантазией разработчика.

Новости