Каморка

Как-то пару лет назад обсуждали задачу, где клиент должен дыл проходить проверку подлинности при соединении к БД. Тогда данные аккаунта "папа Карло" предложил хранить в самой базе. Правильно предложил. Мой шеф тоже предложил.

У меня есть приложение состоящее из БД (неважно какая) + server, который слушает Интернет (кастом протокол) + клиент, который должен просить server обратиться к БД и выполнить некоторую работу.

БД - в локалке. Server там же, но слушает на внешнем интерфейсе. Клиент - может быть в Африке.

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

Надо сделать как можно проще.
Спасибо.

И я бы посоветовал не как проще, а как стандартнее (да и не особо сложно это): SSL connection using client authentication

Marmot писал(а):И я бы посоветовал не как проще, а как стандартнее (да и не особо сложно это): SSL connection using client authentication

Спасибо за ответ. Весь трафик не надо защищать. Достаточно только client authentication. В трафике ничего полезного для постороннего глаза (крокозябры).

Сервер при коннекте посылает клиенту свой открытый ключ

Клиент хешит свой пороль любвм хешем (например мд-5)

Клиент зашифровывает свой предварительно закешированный пароль и плайн логин открытым ключем и посылает серверу

Сервер расшифровывает его и сверяет мд5 сумму с хранящейся в базе данных для етого пользователя.

Все алгоритмы есть в инете:)

проще всего пустить между клиентом и сервером SSL, на сервере
завести сертификат и заставлять клиента его проверять. поверх
SSL пустить кастом client authentication protocol .. лучше что-нить
типа digest-based.

если не нужно шифрование, его можно отключить используя
соответствующий SSL/TLS suite.

объяснять почему именно так и почему другие варианты фиговы
- долго. если есть конкретные вопросы - могу ответить.

PS keep in mind что полностью кастом протокол как минимум
должен не оперировать с auth credentials в открытой форме
и гарантировать защиту от replays.

вторая часть - это собственно то, что отличает поделку от
нормального дизайна. если ты никогда этого раньше не делал,
то влезать и пробовать я бы строго не рекомендовал. тем более
в результате все равно получится либо SSL, либо IKE/ESP :)

aissp писал(а):Сервер при коннекте посылает клиенту свой открытый ключ

Клиент хешит свой пороль любвм хешем (например мд-5)

Клиент зашифровывает свой предварительно закешированный пароль и плайн логин открытым ключем и посылает серверу

Сервер расшифровывает его и сверяет мд5 сумму с хранящейся в базе данных для етого пользователя.

Все алгоритмы есть в инете:)

exploitable via man-in-the-middle and replays

А я возражаю что ли? Но всего шнайдера переписать тут не могу - очень много буквов.

ну так а фигли чухню то всякую в неокрепшие умы сеять ?

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

vg писал(а):

Marmot писал(а):И я бы посоветовал не как проще, а как стандартнее (да и не особо сложно это): SSL connection using client authentication

Спасибо за ответ. Весь трафик не надо защищать. Достаточно только client authentication. В трафике ничего полезного для постороннего глаза (крокозябры).

Ну вот, пока я со своим 4-месячным пацаном игрался, тут уже всё объяснили.

Для облегчения задачи можно заглянуть вот сюда http://www.stunnel.org/

Ок, парни. Спасибо. Если дойдёт делодо SSL - хорошо. Не от меня зависит.

Предлагаю рассмотреть конкретные возможность эксплоита конкретного протокола. Про то, что можно ломануть теоритически - так почти всё можно. Вопрос в затратности.

О протоколе:
Используется TCP. После аутентификации происходит передача одной команды серверу и соединение закрывается. Если надо выполнить другую команду, то клиент должен начать всё сначала, выполнить "серверный пакет" в пределах одного TCP соединения (в терминах TCP). Ожидается, что в день клиент будет посылать один-два "серверных пакета" (здесь "пакет" = аутентификация + команда).

Как говорилось, важно, чтобы сервер был уверен, что команду послал наш человек.

Положим,чужой человек по середине умеет:
1) создавать "сырые" пакеты, иногда предугадывая seq # TCP, пересчитывая конторольные суммы, и т .д. Таким образом он может "влезать" в соединения, подменяя пакеты клиента или сервера искажёнными данными (теоретически это возможно, но мало вероятно и мало продуктивно).
2) может находится на маршрутиризаторе, как встроенное враждебными силами ПО, что хуже п.1 для "наших". Тогда, получив IP пакет, он может его отправить далее искажённым серверу и клиенту.
3) чужой знает спецификацию данного кастом протокола.

Об имплементации кратко. Она чрезвычайно проста и тупа:
1) Клиент посылает: username (как есть); challenge_1 (случайная последовательность байт. Далее клиент будет ждать ответа от сервера на отправленный challenge_1 );
2) Сервер получив данные username; challenge_1 вычисляет:
- выбирает из базы сохранённый hPwd;
- создаёт последовательность bytes = challenge_1 + hPwd;
- вычисляет "ответ" hash_1 = hash( bytes) на challenge_1;
- создаёт для клиента свой challenge_2 (случайная последовательность байт);
3) Сервер посылает клиенту ответ на его challenge в виде hash_1, и при этом посылает свой challenge_2;
4) Клиент сверяет полученный hash_1 с расчитываемым по challenge_1 и userpassword;
Если hash_1 != hash (challenge_1 + hash(userpassword) ), то это не "наш" сервер. Тогда заканчиваем. Иначе выполняем п.5.
5) Клиент вычисляет hash_2 = hash (challenge_2 + hash(userpassword)), и отсылает его серверу в ответ на challenge_2.
6) Сервер сравнивает полученный hash_2 с аналогичным значением, вычисленным с использованием сохранённого в базе hPwd: hash_2_srv = hash( challenge_2 + hPwd )
7) Если hash_2_srv == hash_2, то сервер, считает, что это "наш" клиент, и ждёт получения "полезной" команды от клиента , которую и выполняет. Затем сервер разрывает соединение.

Укажите, плз. сценарий, или его часть по эксплоиту, если это не трудно вам. Если можно, что-нибудь конкретное.
Спасибо.

Marmot писал(а):

vg писал(а):

Marmot писал(а):И я бы посоветовал не как проще, а как стандартнее (да и не особо сложно это): SSL connection using client authentication

Спасибо за ответ. Весь трафик не надо защищать. Достаточно только client authentication. В трафике ничего полезного для постороннего глаза (крокозябры).

Ну вот, пока я со своим 4-месячным пацаном игрался, тут уже всё объяснили.

Для облегчения задачи можно заглянуть вот сюда http://www.stunnel.org/

Спасибо. Если батьки решат SSL, то так и будет. Пока не знаю.

vg писал(а): Укажите, плз. сценарий, или его часть по эксплоиту, если это не трудно вам. Если можно, что-нибудь конкретное.
Спасибо.

за счет того что hash_1 и hash_2 имеют одинаковую структуру,
man in the middle может заставить клиента посчитать hash для
произвольного challenge, что можно использовать для того, чтобы
посчитать клиентский authentication hash в другой сессии ..

но это типа для умных :) по тупому еще проще -

7) Если hash_2_srv == hash_2, то сервер, считает, что это "наш" клиент, и ждёт получения "полезной" команды от клиента , которую и выполняет. Затем сервер разрывает соединение.

.. и man in the middle аккуратно подменяет команду в реквесте на нужную

tcp stream должен быть пакетизирован,
все пакеты должны быть пронумерованы и "подписаны",
для подписи понадобится ключ,
ключ обычно берется из keying material, который ..
выводится из пула случайных данных, в который ..
contribute'ают обе стороны.

эта contributed random data (also frequently called "nonce") должна
быть аутентифицированы обоими сторонами ... и тд и тп

-> получается стандартный key exachange типа того, что есть в SSL

не надо изобретать велосипед

aissp писал(а):Больше не буду
Без шивровки самого протокола тот же тип атаки съедает на нет все преимущества авторизации. ман он зе мидл сперва раскрывает проткол а потом как хочет его кроит компрометируя и клиент и сервер.

не съедает. аутентичность и прайваси - перпендикулярные вещи.

Ладно, тем не менее спасибо аффтору, иначе бы фиг я в книгу полез