goodronНасколько я знаю, исходный код клиента можно получить из *.xap файла. Тем самым можно узнать ключ, так получается?
Обфускация, для начала.

Я бы рекомендовал SSL + WCF + Membership + обфусцированная сборка в *.xap

buredрадуга просто ;)
Бандиты не прорвутся :)

P.S. Тем более в SL уже в комплекте есть родные WCF сервисы для аутентфикации средствами Membership, так что букаф в коде будет меньше.

buredМСУP.S. Тем более в SL уже в комплекте есть родные WCF сервисы для аутентфикации средствами Membership, так что букаф в коде будет меньше.
доработали рашпилем этот ?
Ага. И не только. Еще ProfileService и RoleService. Как Вам такой ход? :)

bured

SilverlightПоставь Fiddler, сразу будет понятно насколько ssl безопасное соединение.
Не начинай, опять же щас опустят за незнание протоколов :)

SilverlightВ SL нет встроенного Mebershipa и 100% безопасного метода передачи данных.
Точно так же, как и в ASP.NET нет встроенного мембершипа.

Для тех, кто туго соображает: речь о System.Web.Extensions.dll (.NET Framework v4.0), в котором идет поставка Authentication контрактов, Role контрактов и Profile контрактов.

В сильвер-апп достаточно написать одну строку кода (ProfileService.svc):


и сервис готов.

Да что говорить, весь мир использует SSL, на SSL строятся достаточно серьезные приложения. Вараинтов хеширования данных в сертификате с последующей расшифровкой на стороне сервера - масса.
Что тут скажешь, Сева опять всех имеет со своим фиддлером в кармане

SilverlightMCУ, ты опять блеснул своими энциклопедическими познаниями.
Изучай. Decrypting HTTPS-protected traffic
Ты со своим так называемым "умом" не меняешься. Ты понимаешь, что бывают открытые ключи и методы шифрования, которые включаются в сертификат? А ты понимаешь, что бывает еще и закрытый ключ, а метод шифрования находится на сервере? :)
Как твой фиддлер тут поможет?

SilverlightКогда найдешь "вcтроенный" мембершип, дай ссылку на сборку.
System.Web.Extensions.dll

Сева, даже википедия об этом знает, в отличие от тебя: http://ru.wikipedia.org/wiki/SSL

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

Всякий раз, когда сервер аутентифицируется, канал безопасен против атаки человек посредине, но полностью анонимная сессия по своей сути уязвима к такой атаке. Анонимный сервер не может аутентифицировать клиента. Если сервер аутентифицирован, то его сообщение сертификации должно обеспечить верную сертификационную цепочку, ведущую к приемлемому центру сертификации. Проще говоря, аутентифицированный клиент должен предоставить допустимый сертификат серверу. Каждая сторона отвечает за проверку того, что сертификат другой стороны еще не истек и не был отменен. Главная цель процесса обмена ключами — это создание секрета клиента ( pre_master_secret ), известного только клиенту и серверу. Секрет ( pre_master_secret ) используется для создания общего секрета ( master_secret ). Общий секрет необходим для того чтобы создать сообщение для проверки сертификата, ключей шифрования, секрета MAC (message authentication code) и сообщения «finished». При посылке верного сообщения «finished», тем самым стороны докажут что они знают верный секрет (pre_master_secret) .

Так же читать про наш любимый "RSA и аутентификация".

P.S. Короче, RTFM, хакер ты наш

SilverlightSSL безопасен,когда соединение установлено. Fiddler может быть запущен, как прокси для браузера, он устанавливает соединение с сервером, получает все необходимое от него, а браузеру подсовывает свой сертификат, спокойно расшифровывает данные , шифрует их с ключем от сервера и передает ему.
Сева, вот скажи, ты действительно дурак или только им прикидываешься? Алгоритм находится на стороне сервера. Кто даст "спокойно расшифровывать данные", дядя Ваня?
SilverlightЯ проверял это когда делал оплату по кредитной карте, все было замечательно видно.
Не мудрено
Тебе вообще безопасность противопоказана, о чем ты говоришь.
SilverlightЭто защита только от таких наивных и доверчивых юношей, как ты.
Ага, в КриптоПро CSP тоже дети сидят, и ждут, когда же их Сева с фиддлером подломит :)
SilverlightДругой пример с картинками и на русском. тынц
Тебя прёт тынцы на ресурсы ниачём постить?

P.S. Цирк :)

SilverlightAlexeiKSilverlight,

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

У-ха-ха

Silverlight,

Цифровой сертификат – это файл, идентифицирующий людей или серверы. Цифровой сертификат – своего рода цифровой паспорт или удостоверение личности, которое удостоверяет сервер перед началом SSL-сессии.

Silverlightспокойно расшифровывает данные
Каким боком он расшифрует данные, если алгоритм находится на сервере под семью замками? Гадание на кофейной гуще?

SilverlightПричем алгоритм, который находится на сервере, когда данные вводятся на клиенте?
Причем тут ввод данных-то? :) В сертификате находится, к примеру, просто закрытый ключ. Что расшифровывать и каким алгоритмом ты собираешься?
SilverlightЯ про них, бестолочь, говорил и видел, что уходит на сервер
Тебя реально понесло, ты опростоволосился и поплыл в сторону плинтуса, даже ниже...

SilverlightЭто соединение устанавливает Фиддлер, а не браузер, он получает мастер ключ. Зная его, он может правильно вести обмен. Для сервера он выступает в качестве браузера, а для браузера он сервер . Таким образом, спокойно пропускает и видит весь трафик. Поставь, тупо следуй инструкции, сам все узреешь
Ты начинаешь включать заднюю, клоун, и путаться в своих же доводах.
Смотри:

SilverlightПоставь Fiddler, сразу будет понятно насколько ssl безопасное соединение

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

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

P.S. Ты понимаешь смысл сертификата? Смысл такой:

МСУЦифровой сертификат – это файл, идентифицирующий людей или серверы . Цифровой сертификат – своего рода цифровой паспорт или удостоверение личности, которое удостоверяет сервер перед началом SSL-сессии.

Так вот, если у клиента сертификат установлен - значит, клиент - свой. И не важно, стоит ли у него фиддлер или что-то другое, клиент остается своим. И клиенту будет доступен тот контент сайта/сервиса, который должен быть доступен.

И как после этого можно говорить, что SSL небезопасен?
Вот тупо - я говорю человеку - теперь ты админ. Это значит, что этот человек админ и не важно, хакер он или дворник. Он - админ. Когда срок сертификата истечет, он получит (возможно) новый сертификат.

Что, как и где ты собираешься хакать? :))
Ведь твои же слова: "SSL безопасен,когда соединение установлено". Соединение установлено, сертификат в налиии. Какие могут быть проблемы?

Севушка, хакер ты наш, перечисляю все возможные атаки на SSL:

Атаки

Опишем ряд атак, которые могут быть предприняты против протокола SSL. Однако , SSL устойчив к этим атакам.

Раскрытие шифров
Как известно, SSL зависит от различных криптографических параметров. Шифрование с открытым ключом RSA необходимо для пересылки ключей и аутентификации сервера/клиента. Однако в качестве шифра используются различные криптографические алгоритмы. Таким образом, если осуществить успешную атаку на эти алгоритмы, то SSL не может уже считаться безопасным. Атака на определенные коммуникационные сессии производится записью сессии, и потом, в течение долгого времени подбирается ключ сессии или ключ RSA. SSL же делает такую атаку невыгодной, так как тратится большое количество времени и денег.

Злоумышленник посередине
Такая атака предполагает участие трех сторон: сервера, клиента и злоумышленника, находящегося между ними. В данной ситуации злоумышленник может перехватывать все сообщения, которые следуют в обоих направлениях, и подменивать сообщения. Злоумышленник представляется сервером для клиента и клиентом для сервера. Но такая атака невозможна при использовании протокола SSL, из-за того, что сервер использует сертификаты. А злоумышленник не имеет сертификата сервера.

Замечание. Однако работа HTTPS-фильтра (который устанавливает туннель в обе стороны и отдаёт свой сертификат клиенту) в MSForefrontTGM, работающая по этой схеме, не является атакой, но средством защиты и контроля.

Атака отклика
Злоумышленник записывает коммуникационную сессию между сервером и клиентом. Позднее, он пытается установить соединение с сервером, воспроизводя записанные сообщения клиента. Но SSL отбивает эту атаку при помощи особого уникального идентификатора соединения (ИС). Конечно, теоретически третья сторона не в силах предсказать (ИС), потому что он основан на наборе случайных событий. Однако злоумышленник с большими ресурсами может записать большое количество сессий и попытаться подобрать «верную» сессию, основываясь на код nonce, который послал сервер в сообщение Server_Hello. Но коды nonce SSL имеют, по меньшей мере длину 128 бит, а значит, злоумышленнику необходимо записать 2^127 кодов nonce, чтобы получить вероятность угадывания 50 %. Но 2^127 достаточно большое число, чтобы сделать эти атаки бессмысленными.

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

Для такой атаки злоумышленнику необходимо быстро подменить одно или более сообщений рукопожатия. Если это происходит, то клиент и сервер вычислят различные значения хэшей сообщения рукопожатия. В результате чего стороны не примут друг от друга сообщения Finished. Без секрета злоумышленник не может исправить сообщение Finished, вот почему атака будет обнаружена.


А теперь скажи, дружок, как твой фиддлер (банальный сниффер, который ничего не умеете, ни брутфорсить, ни подбирать клуючи RSA) может подломить SSL? :)

Расскажи, а мы послушаем, поглумимся над тобой

P.S. Ёпт, оказывается SSL - ненадежен! Сева, Вы подломили МИР
P.S2. Нужно закрываться банкам, в первую очередь...