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

← →
Eraser © (2008-11-07 02:51) [0]

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

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

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

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

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

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

Спасибо!

← →
Slym © (2008-11-07 04:46) [1]

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

← →
Slym © (2008-11-07 04:47) [2]

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

← →
Slym © (2008-11-07 05:01) [3]

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

← →
Поросенок Винни-Пух © (2008-11-07 09:13) [4]

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

← →
Поросенок Винни-Пух © (2008-11-07 10:03) [5]

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

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

← →
Anatoly Podgoretsky © (2008-11-07 11:06) [6]

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

← →
Eraser © (2008-11-07 14:31) [7]

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

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

← →
Поросенок Винни-Пух © (2008-11-07 14:40) [8]

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

← →
Vlad Oshin © (2008-11-07 14:41) [9]

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

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

← →
Поросенок Винни-Пух © (2008-11-07 14:55) [10]

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

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

← →
DVM © (2008-11-07 15:44) [11]

> Eraser © (07.11.08 02:51)

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

← →
Eraser © (2008-11-07 15:56) [12]

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

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

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

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

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

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

← →
Eraser © (2008-11-07 15:58) [13]

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

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

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

← →
Поросенок Винни-Пух © (2008-11-07 16:05) [14]

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

← →
Eraser © (2008-11-07 16:12) [15]

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

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

← →
DVM © (2008-11-07 16:14) [16]

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

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

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

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

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

← →
DVM © (2008-11-07 16:17) [17]

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

← →
Eraser © (2008-11-07 16:22) [18]

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

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

← →
Поросенок Винни-Пух © (2008-11-07 16:22) [19]

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

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

← →
Eraser © (2008-11-07 16:23) [20]

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

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

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

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

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

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

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

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

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

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

> Поросенок Винни-Пух (07.11.2008 14:40:08) [8]

Транзитный подставной сервер, ведь пакеты идут по цепочке серверов.

Еще такой вопрос.

Что лучше передавать по сети - пароль или хэш. (канал защищенный - RSA, т.е. "подслушать" пароль нельзя).

1. Клиент отсылает серверу пароль. Сервер принимает пароль, берет от него хэш, сравнивает с хэшем настящего пароля.
2. Клиент отсылает серверу хэш пароля. Сервер принимает хэш, сравнивает с настоящим хэшем.

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

так какой вариант лучше и почему?

> Eraser © (09.11.08 00:36) [25]

Лучше хэш. Ибо если сервер будет каким то образом взломан, то хоть пароли в открытом виде не достануться. Брутфорсить их хэшей время надо.

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

0. сгенерить серверу RSA ключ минимум 1024
1. клиент конектится передает свой открытый сессионный ключ
2. сервер делает свой сессионный и шифрует его закрытым ключем из п.0
3. клиент расшифровывает ключ при помощи известного ему заранее открытого ключа из п.0
4. далее идет генерация AES симетричного ключа

Проверка подлинности сервера Найти похожие ветки