Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Проверка подлинности сервера

Страницы: < 1 2
Eraser © (2008-11-07 02:51:00)
Есть некая клиент-серверная система.

Назрела задача - сделать проверку подлинности сервера на этапе авторизации.

В общем виде сейчас алгоритм такой:
1. устанавливаем зашифрованный канал (RSA + AES).
2. передаем на сервер по зашифрованному каналу пароль.
3. берем хэш пароля и сверяем его с хэшем пароля, хранящимся на сервере. если хэши совпали - авторизация пройдена.

но у этого алгоритма есть изъян - в общем случае, сервер можно подменить, т.е. написать софтину, которая повторяет действия настоящего сервера при авторизации и т.о. получить пароль. Т.е. нужна проверка подлинности сервера. Я в курсе, что обычно это делается с использованием сертификатов или общего секрета - скорее всего так и будет реализовано. НО, тут предложили кое-какое интересное но сомнительное решение. Изложу его:

"Моё предложение заключалось в том , чтобы перед передачей пароля серверу , клиент мог бы убедиться что он подсоединился именно к своему серверу , а не к подставной машине , которая хочет узнать пароль. Что мы делаем?
Напомню у нас есть только два слова:
1) На клиенте пароль - "MirMir"
2) На сервере хэш пароля - AEDE7AADA7FF808889A53DF34DC33A58
Для того чтобы убедиться что это наш сервер , клиентская машина загадывает какое-нибудь произвольное число , например - 1234 (хотя может быть длинной в несколько десятков символов) и передаёт его серверу.
Сервер получил это число , добавляет его к имеющемуся у него хэшу пароля и всё это дело заного херирует по формуле:
MD5("AEDE7AADA7FF808889A53DF34DC33A58"+"1234")
получется - 647168356A74AD99C92D03DD3436DD3E. И теперь этот хэш передаётся клиенту.
Клиент на своей стороне проверяет правильность пароля делая MD5(MD5("MirMir")+"1234") , что равно 647168356A74AD99C92D03DD3436DD3E.
Теперь наш клиент точно уверен что сервер свой! Значит можно передавать ему пароль...".

Слабое место, очевидно, в том, что сервер передает не проверенному клиенту md5(md5(пароль) + случайный данные). Реально ли по этим данным восстановить md5(пароль)или вообще пароль?
В чём подвох?

Спасибо!

Vlad Oshin (2008-11-07 14:41:00) [21]

> 1) На клиенте пароль - "MirMir"
> 2) На сервере хэш пароля - AEDE7AADA7FF808889A53DF34DC33A58
> Для того чтобы убедиться что это наш сервер , клиентская
> машина загадывает какое-нибудь произвольное число , например
> - 1234 (хотя может быть длинной в несколько десятков символов)
> и передаёт его серверу.
> Сервер получил это число , добавляет его к имеющемуся у
> него хэшу пароля

А как сервер узнает какой клиент ему это "1234" прислал?

Поросенок Винни-Пух (2008-11-07 14:40:00) [22]
а как такое вообще может случится, что клиент попал на подставной сервер?

Eraser (2008-11-07 14:31:00) [23]
так я ж написал про сертификаты, что вкурсе )

> [4] Поросенок Винни-Пух © (07.11.08 09:13)

> подставной сервер никогда не узнает пароль клиента если
> использовать авторизацию challenge-response, а не тупо слать
> md5(чистый пароль без соли)

так заметье, в данной сетуации клиент вообще не отсылает ни пароль, ни md5 пароля, ни md5 пароля + соль. А вот сервер отсылает НЕ проверенному клиенту MD5(MD5(Пароль)+N), где N - известно клиенту! странно, что сразу не заметил, где упущение. этот алгоритм позволяет задействовать мощности по подбору пароля на стороне клиента. Если сейчас подбор пароля - операция очень не быстрая (установка RSA канала занимает значительное время) + есть защита от брутофорса, то при использовании этого алгоритма, злоумышленник на стороне Клиенталегко получает от сервера MD5(MD5(Пароль)+N), где N ему известно. для подбора пароля достаточно подставлять сам ожидаемый пароль и два раза брать хэш.

> [6] Anatoly Podgoretsky © (07.11.08 11:06)

думал насчет сертификатов, потом понял, что грамоздко будет. что если просто использовать общий секрет, например специально сгенерированный для проверки подлинности сервера AES ключ. при установки соединения, сервер шифрует этим ключем определенную фразу, которую знает клиент. отсылает её клиенту. тот пытается расшифровать принятую фразу своим ключом, если расшифровал успешно - то сервер подлинный.

Anatoly Podgoretsky (2008-11-07 11:06:00) [24]
Использовать репозиторий ключей, например verisign

Поросенок Винни-Пух (2008-11-07 10:03:00) [25]
Клиент на своей стороне проверяет правильность пароля делая MD5(MD5("MirMir")+"1234") , что равно 647168356A74AD99C92D03DD3436DD3E.
Теперь наш клиент точно уверен что сервер свой! Значит можно передавать ему пароль...".

А вот фигушки. Клиент будет знать, что работает с экземпляром "правильного" сервера. Но ничто не мешает злоумышленнику взять этот самый экземпляр и поставить "у себя". Клиент не заметит никакой подмены, при любой степени хитрости алгоритма.

Поросенок Винни-Пух (2008-11-07 09:13:00) [26]
подставной сервер никогда не узнает пароль клиента если использовать авторизацию challenge-response, а не тупо слать md5(чистый пароль без соли)

Slym (2008-11-07 05:01:00) [27]
Slym © (07.11.08 4:46) [1]
2. Diffie-Hellman - на заранее прошитом у клиента ключе + проверка ключа как в 1
чушь спорол... там же случайные ключи а не "прошитые"...

Slym (2008-11-07 04:47:00) [28]
Eraser © (07.11.08 2:51)
устанавливаем зашифрованный канал (RSA + AES)
на SSL или поделка?

Slym (2008-11-07 04:46:00) [29]
1. не проще проверять MD5/SHA открытого RSA ключа сервера? в упрощеном виде это и будет "сертификатом"
2. Diffie-Hellman - на заранее прошитом у клиента ключе + проверка ключа как в 1

Страницы: < 1 2

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »