Есть некая клиент-серверная система.

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

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

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

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

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

Спасибо!

1. не проще проверять MD5/SHA открытого RSA ключа сервера? в упрощеном виде это и будет "сертификатом"
2. Diffie-Hellman - на заранее прошитом у клиента ключе + проверка ключа как в 1

Eraser ©   (07.11.08 2:51)
устанавливаем зашифрованный канал (RSA + AES)
на SSL или поделка?

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

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

Клиент на своей стороне проверяет правильность пароля делая MD5(MD5("MirMir")+"1234") , что равно 647168356A74AD99C92D03DD3436DD3E.
Теперь наш клиент точно уверен что сервер свой! Значит можно передавать ему пароль...".

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

Использовать репозиторий ключей, например verisign

так я ж написал про сертификаты, что вкурсе )


> [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 ключ. при установки соединения, сервер шифрует этим ключем определенную фразу, которую знает клиент. отсылает её клиенту. тот пытается расшифровать принятую фразу своим ключом, если расшифровал успешно - то сервер подлинный.

а как такое вообще может случится, что клиент попал на подставной сервер?

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


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

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

Итого: ключ зашит и в сервер и в клиента.
так его оттудова же вытащат.

> Eraser ©   (07.11.08 02:51)

Эта схема в общем то известна давно и имеет несколько вариаций. В общем то довольно безопасное решение. Можно или нельзя восстановить пароль по хэшу зависит от реализации функции хэширования. Я применяю всегда почти похожую схему, похожая же схема используется где то в Windows. Суть всех манипуляций одна - не пересылать пароли а только хэши от паролей склееных со случайными данными.

> [11] DVM ©   (07.11.08 15:44)

так эта схема предоставляет возможность брутофорсить пароль БЕЗ участия сервера, т.е. не по сети, а локально. злоумышленник может задействовать хоть кластер для генерации. в вся генерция сводится к ввызову 2 раза функции хэширования. не считаю такой подход безопасным.

> [8] Поросенок Винни-Пух ©   (07.11.08 14:40)
> а как такое вообще может случится, что клиент попал на подставной
> сервер?

тупо переткнут кабель в другой комп с тем же IP. не важно как, факт в том, что это возможно.

> [10] Поросенок Винни-Пух ©   (07.11.08 14:55)

зачем же зашиты? ключи с возможностью экспорт/импорта. третьим лицам в руки не должны попадать.

> [12] Eraser ©   (07.11.08 15:56)


> зачем же зашиты? ключи с возможностью экспорт/импорта. третьим
> лицам в руки не должны попадать.

повторюсь, имеется ввиду специальный ключ, который предназначен для проверки подлинности сервера, к сеансовым ключам отношения не имеет.

ну так и надо смотреть в сторону pki и эцп.
если сохранность ключей/сертификатов гарантируется и у поддельного сервера нет оригинальных ключей/сертификатов настоящего сервера, то клиент просто не сможет рсшифровать посылки сервера, и поддельный сервер не поймет что ему заслал клиент. Это если на прикладном уровне зарывать данные. Либо защищенный канал + опять же сохранность серверных сертификатов и ключей

> [14] Поросенок Винни-Пух ©   (07.11.08 16:05)

защещенный канал имеется, см [0]. все описанные опирации ведутся по защищенному каналу.
задача - реализовать проверку подлинности сервера, т.к. есть возможность реализовать поддельный сервер. тогда клиент установит защищенный канал с ним и передаст ему пароль. проверка подлинности клиента есть! но прежде чем к ней приступить нужно проверить подлинность именно сервера.

> Eraser ©   (07.11.08 15:56) [12]


> так эта схема предоставляет возможность брутофорсить пароль
> БЕЗ участия сервера

Я несколько раз применял следующую схему:

1) Клиент подключается к серверу.
2) Сервер генерит сколь угодно длинную последовательность символов, запоминает ее в контексте клиента и высылает ее клиенту.
3) Клиент берет эту последовательность, клеит к ней свой пароль и находит хэш от всего. Далее высылает получившееся серверу.
4) Сервер получает хэш, берет свою случайную последовательность, клеит к ней пароль клиента (который у сервера есть) и находит хэш от всего и сравнивает с тем что прислал клиент.

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

ну и в обратку можно точно так же проверять сервер, что он наш, и плюс еще не хранить на сервере пароль в открытом виде.

> [16] DVM ©   (07.11.08 16:14)

схема понятна. но это не проверка подлинности сервера (инетерсует именно этот аспект). это хороший алгоритм для авторизации клиента на сервер, в случае, если канал не защищен. защищенный канал имеется (248 бит RSA и 256 AES), т.е. беспокоиться о снифферах и прочем не приходится.

непонятно каким макаром реализован защищенный канал. и как он поднимется, если соску переткнут в другой комп.

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