Pull to refresh

Защита пароля при передаче по открытому каналу (часть 1)

Reading time 2 min
Views 37K
Использование https при аутентификации уже давно стало правилом хорошего тона. Однако, необходимость покупки сертификата приводит к тому, что многие владельцы web-ресурсов по прежнему используют для аутентификации открытый канал и ваши пароли доступа могут быть перехвачены злоумышленником, имеющим доступ к сети, в которой вы работаете. Следует отметить, что использование https в общем случае не гарантирует защиты от перехвата передаваемого трафика. На сегодняшний день существуют решения, основанные на использовании специальных прокси и доменных политик, позволяющие успешно читать https трафик в корпоративных сетях. Далее о том, как все же защитить пароль от перехвата.

Как же обстоят дела сейчас? Наиболее типичная ситуация состоит в том, что сервер хранит в БД hash пароля пользователя H(pwd) и в процессе аутентификации, получив пароль от пользователя, вычисляет hash и сравнивает его с эталоном. Хранение в БД значения хэша пароля, вместо самого пароля, позволяет защититься от кражи аутентификационных данных недобросовестным администратором или сторонним нарушителем. Но несмотря на это каждый раз при аутентификации пароль передается в канале связи в открытом виде. А перехват пароля дает злоумышленнику полный доступ к соответствующему аккаунту. Для защиты от перехвата пароля был придуман механизм Дайджест аутентификации. Я немного упростил алгоритм для лёгкости понимания. При каждом сеансе сервер посылает клиенту случайное число Rnd, клиент в ответ посылает H(Rnd+H(pwd)). В результате перехват ничего не даст злоумышленнику, однако теперь появляется слабое место – БД сервера. Хранимый в БД пароль или хэш пароля позволят воссоздать необходимый для авторизации ответ клиента. Хищение такой БД становится серьезной угрозой безопасности механизма аутентификации.

Ниже приводится пример того как можно защитить передаваемый пароль от перехвата, не создавая дополнительной угрозы. При этом небольшие переделки коснутся только вашего сервиса и не затронут ваших пользователей.

Итак:
  1. Сервер хранит в БД хэш пароля клиента H(pwd);
  2. Клиент отправляет серверу свой Login;
  3. Сервер отправляет клиенту случайное число Rnd шифрованное на H(pwd) клиента;
  4. Клиент вычисляет случайное число Rnd с помощью своего пароля, затем шифрует свой пароль pwd с помощью случайного числа Rnd и отправляет на сервер;
  5. Сервер расшифровывает пароль клиента с помощью случайного числа Rnd, вычисляет хэш пароля и сравнивает с эталоном.

image
Для тех, кому проще понять, читая код — примеры. Серверная часть на PHP. Клиентская — Javascript. Так же можно посмотреть демонстрацию. AES шифрование построено на библиотеках Chrisa Veness
Конечно, данное решение не панацея, и использовать его имеет смысл только когда нет возможности использовать https. Однако, использование описанного алгоритма позволит защитить передаваемый пароль от снифинга и атаки MitM.

часть 2
Tags:
Hubs:
+29
Comments 69
Comments Comments 69

Articles