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

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

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


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

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

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

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


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

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

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

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

думаю примерно так и будет.
чудес, как говорится, не бывает )

> Поросенок Винни-Пух  (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 симетричного ключа

> [26] DVM ©   (09.11.08 14:56)


> [27] Поросенок Винни-Пух ©   (09.11.08 22:40)

думаю SHA-1 хэш подойдет.