Парольная защита веб-приложений

Я хочу рассказать о собственном опыте защиты веб-приложений, используемых на предприятиях/фирмах с ограниченным числом сотрудников. Поговорим о системе, когда проверка подлинности пользователей осуществляется только с помощью паролей. Хочу отметить, что парольная защита – не единственный способ проверки подлинности, но на данный момент самый привычный и используемый.

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

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

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

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

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


И, фактически, вся система защиты строится на способе обмена идентификационными данными (далее - просто данными) и политике работы пользователей в системе.

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

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

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

3. Блокировка пользователя после 7-10 неудачных попыток входа.
Практически исключает взлом пароля путём перебора.

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

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

6. В самой сессии со стороны пользователя – никаких данных!
Только её идентификатор.

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

8. Система привязки пользователей к конкретным IP/дням/времени работы.
Нечего рядовому менеджеру Кате делать в системе в субботу в 02:23 с IP американской университетской сети :) .

9. Принципиальная невозможность работы с системой через прокси-сервера.
Особенно актуально в случае работы без SSL.
К сожалению, в ряде случае отследить невозможно.

10. И Самое Важное – постоянный мониторинг работы системы!
Вход/выход пользователей, блокировки, неверный ввод/перебор пароля, сканирование на уязвимости и так далее, всё в руках паранойи разработчика :)

mot