Silverlight, мы давно поняли все, что ты не читаешь даже свои посты, не говоря обо всём остальном.

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

Вдумайся в эти буквы и осознай свою некомпетенцию.

Silverlight Вчера закончилась конференция 25C3 (25th Chaos Communication Congress) в Берлине. Одним из самых громких докладов на конференции стал доклад Александра Сотирова (Alexander Sotirov), Марка Стивенса (Marc Stevens) и Джекоба Аппельбаума (Jacob Appelbaum) – MD5 considered harmful today: Creating a rogue CA certificate. В этой статье я кратко опишу суть уязвимости и постараюсь ответить на возможные вопросы.

«Мы обнаружили уязвимость в Internet Public Key Infrastructure (PKI), используемой для выдачи цифровых сертификатов для Web сайтов. В качестве примера мы продемонстрировали часть атаки и успешно создали фальшивый CA сертификат, которому доверяют все современные браузеры. Сертификат позволяет нам выдать себя за любой сайт в интернете, использующий HTTPS, включая сайты банков и online магазинов»[1
Начало статьи: "

Суть уязвимости

Многие центры сертификации до сих пор используют MD5 хеши для проверки подлинности сертификатов. С 2004 года достоверно известно, что MD5 хеши являются слабыми с криптографической точки зрения."

Дальше можно не читать.

Сева, вот скажи, ты реально такой тупой?

МСУSilverlight, мы давно поняли все, что ты не читаешь даже свои посты, не говоря обо всём остальном.

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

Вдумайся в эти буквы и осознай свою некомпетенцию.

Это равносильно тому, что юзер просто экспортирует корневой сертификат и подарит его взломщику
Севушка, жги еще, жги ))

Ого! Пиши еще, Сева, еще!

SilverlightLR, у МСУ в свое время с пулом отжигал также, как ты.
Ага, и с пулом, и с мембершипом, и с ролепровайдером, и с IPrincipial, и с грязным чтением, и с пейджингом, и с таблицей в 5 миллионов записей, и с.... Сева, мы помним твои перлы.
SilverlightЕсли это освоить не можете, то что говорить об SSL. Это для вас еще сложно
Учитель, мы будем учить и стараться

rmontSSL безусловно обеспечивает наибольшую безопасность.
Абсолютно верно.
rmontНо в 99% (когда речь не идет о деньгах) на мой взгляд достаточно простого шифрования пароля на клиенте ассимитричным алгоритмом.
Согласен. Но, при особом желании (при атаке посередине) дизассемблим Cryptography.dll в ClientBin/*.xap, забираем хеш и



Так что, для начала лучше, всё-таки, обфусцировать алгоритм, коль его хотите отдать клиенту (ну это от дурака, ибо серьезный взломщик будет трассить серьезными вещами типа интерактивного дизассемлера ИДА и иже).

Но, в 99%, как Вы заметили, такой защиты вполне хватит. Хотя бы для того, чтобы всякие ламерские шпионские перехватчики отмести.

LRесли канал не безопасный, злоумышленник сможет записать и затем повторить (трафик обмена) _не расшифровывая пароль_ (т.е., пароль не узнает, но идентифицироваться сможет)...
Нет. Трафик повторять не нужно, алгоритм не на стороне сервера, а у нас в руках, вот он: RiaWebSoftRu.Cryptography.dll. Шифруем ассимитрично.
Имеем: ключ и хеш. анализируем сборку, производим расшифровку ей же. Стандартный прэктис.

Silverlight,

если не сломаешь сайт, извиняться будешь?

LRрасшифровать с помошью открытого ключа и хеша? я так понял, это гораздо трудозатратней (чем повторить обмен сообщениями), особенно если длина ключа, как в примере, 2048 бит (часто встречается что вполне надежным считается ключ с длиной 1024)
Обмен сообщениями нужен, если алгоритм находится на сервере. У нас же алгоритм находится в руках.

LRМСУОбмен сообщениями нужен, если алгоритм находится на сервере. У нас же алгоритм находится в руках.
алгоритм позволит расшифровать если есть закрытый ключ, но разве он поможет воссоздать закрытый ключ по открытому и хешу? (в этот вопрос я не вникал, но что-то не верится)
Мля... :)

1. Имеем на сервере ключ открытый ключ (Base64), см. секцию для хранения RSA ключей (rsaKeyConfig Modulus)
2. Имеем на сервере алгоритм (сборка)
3. При обращении к сайту, клиент получает алгоритм (в WcfSilverlight.xap)
4. При обращении к сайту, клиент получает ключ rsaKeyConfig Modulus (иначе, нечем будет шифровать)
5. При обращении к сервису аутентификации пользователя, клиент передает свой Login открытым текстом и Password, зашифрованный ключом rsaKeyConfig Modulus и алгоритмом (из в WcfSilverlight.xap)
6. Понятно? :)

LR, не забывайте, у нас же полноценный толстый клиент (SL), у него имеется вся информация по алгоритму. Сломать пусть даже обфусцированную сборку с алгоритмом - вопрос времени. IDA рулит.
А вот с SSL такие танцы не пройдут - будешь всю свою жизнь подбирать брутфорсером последовательности и еще не факт, что подберешь. Даже HTTPS-фильт в туннеле в обе стороны не поможет, ибо сертификат находится у клиента.

Ладно, пока наш хакер Сева сопли жует, пойду дальше готовиться к сертификационному экзамену по шарепоинту, сегодня в Софт-лайн еду сдавать.
А наш хакер пусть RTFM'ит, а то скучно уже с этим клоуном перепалки устраивать.

LR, пароль зашифрован, причём неплохо, 2048 бита. Если хотите поюзать исходнички, вот тут я сегодня качал. Классная сборочка, мне понравилась.