Алгоритм входа с защитой авторизационных данных от использования при их перехвате на канале?

Question

[xmoonlight]

Делаю пользовательскую зону на веб-сайте с повышенной системой защиты.


Необходимо реализовать без установки сертификата или токена, а так же любого «железа» (кроме стандартных: «мыши» и клавиатуры), вход с защитой авторизационных данных от использования при их перехвате на канале.


Т.е. обычным методом: логин и пароль.

Нужна регистрация (однократно) и авторизация (периодически). (стандартные требования...)


У кого какие мысли? Какие алгоритмы смотреть, подскажите.

Заранее, всем Спасибо за помощь.

Answer 1

[Андрей]

Подскажите, а какие дополнительные угрозы не дают использовать что-то типа примитивного CRAM-MD5 (быстро, все есть штатно на клиенте и на сервере)?

Comments

[xmoonlight]

Вкраце, можете описать механизм? (желательно без чистых ссылок)

[Андрей]

1. Сервер генерирует достаточно длинную случайную строку challenge — единственно требование — она не должна никогда повториться, поэтому в нее обычно добавляют текущее время.
2. Сервер направляет challenge клиенту по открытому каналу.
3. Клиент вычисляет response = MD5( password || challenge || password ).
4. Клиент направляет response серверу по открытому каналу.
5. Сервер по имеющемуся у него «истинному» паролю клиента также вычисляет response' = MD5( password || challenge || password ) и сверяет response=response'

В сухом остатке:
а) пароль не передавался по открытому каналу
б) вычислить корректный response не зная password невозможно в силу свойств хеш-функции
в) отправить повторно старый response на challenge нельзя, т.к. он (challenge) никогда не повторяется.

[xmoonlight]

а пароль зачем два раза (по краям то)? он один и тот же?
MD5( password || challenge || password )?

[Андрей]

Для Вашего случая фиксированной длины challenge-а можно один раз (но обязательно пароль должен стоять спереди от challenge), собственно получается htdigest, упомянутый выше.

А в общем случае, при создании MAC (message authentication codes) на основе хеш-функций, парольная или ключевая информация применяется дважды — спереди и сзади — для защиты от разных угроз (подробнее посоветовал бы прочесть у Менезеса в п.9.5.2).

[Андрей]

А как сервер узнает какой microtime сейчас на клиенте?
Он должен внутри challenge прийти от сервера клиенту.

[Андрей]

Тогда у Вас challenge формируется фактически клиентом, а значит перехватив однажды пару challenge-response от валидного сеанса, злоумышленник сможет повторить microtime в момент инициализации, а потом успешно пройти проверку, не зная фактически пароля. («replay attack»)

[Андрей]

Извините, не могу до конца понять Вашу схему.

Answer 2

[Алексей Гусейнов]

Я правильно понимаю, что вы хотите повысить безопасность системы ничего не меняя в механизме аутенификации/авторизаиции? Тогда кроме использования SSL шифрования канала вам ничего посоветовать нельзя.

Comments

[xmoonlight]

Нет. Я строю систему с нуля.
Пока выбор пал на SRP-6.
Есть еще варианты?

Answer 3

[lair]

Чем вам HTTPS не угодил? Стандартное решение.

Answer 4

[bypasser]

Присоединяюсь к HTTPS.

Answer 5

[Виталий Перетятько]

Почитайте про аутентификацию с солью habrahabr.ru/post/121021/

Comments

[xmoonlight]

Спасибо за линк, viperet.
Изучаю.

Answer 6

[ntkt]

Используйте HTTPS + аутентификацию при помощи SRP-6, как подсказывают коллеги выше.
1. Правильно настроенный HTTPS обеспечит приемлемую защиту канала обмена данными (если пользователи будут минимально сознательны).
2. SRP-6 не дает использовать перехваченные данные повторно и не дает подобрать изначальный пароль на их основе.
Даже если атакующий обойдет SSL, например, получит доступ к закрытому ключу от Вашего серверного сертификата, или от более высокого в цепочке сертификатов, вплоть до корневых, и проведет MITM-атаку, используя легитимный с точки зрения клиентского браузера поддельный SSL-сертификат, то перехваченной информации атакующему будет все равно недостаточно, чтобы аутентифицироваться вместо пользователя.

Вместо SRP-6 можно использовать более слабые стандарты типа htdigest (HTTP digest authentication, rfc2617, есть в апаче из коробки, правда, в самом простом варианте использования это будет для клиента выглядеть как некрасивое стандартное pop-up окно в браузере).

Comments

[xmoonlight]

Огромная благодарность ntkt за подробное изложение материала.
SRP-6 очень заинтересовал и пока первый претендент на участие в моём проекте.
SRP-6 без SSL насколько надежен и можно ли быть уверенным, что не сломают учетку пользователя через год-два?
Есть ли еще подобные альтернативы?

[ntkt]

Надежность SRP-6 основывается на трудности задаче дискретного логарифмирования (DLP, discrete logarithm problem).
Если и на сервере, и на клиенте используются реализации протокола без явных уязвимостей, то грубые оценки по криптостойкости можно брать из Диффи-Хеллмана для той же длины модуля.
Еще кое-какие соображения по безопасности описаны в соотв. RFC (RFC 2945, RFC 5054).
Выбор хэш-функции важен, т.к. если злоумышленник скомпрометирует сервер аутентификации, то получение доступа к паролю можно свести к подбору хэша (словарь, rainbow-таблицы и вперед).
Вот здесь например, обсуждают стойкость конкретной реализации. Тут рассказывается, что будет, если взять короткий модуль и не самую стойкую хэш-функцию, с источниками.

[xmoonlight]

ntkt, почитав документацию появилось ряд новых идей в плане реализации. Если интересно — могу написать в своём блоге. (но не факт, что они будут ценными...)

Answer 7

[Алекс]

Логин , пароль и одноразовый пароль totp, на основе Google Authenticator