[FaultEvent fault=[RPC Fault faultString="The type initializer for 'PPG.Security.LoginManager' threw an exception." faultCode="Server.Processing" faultDetail="The type initializer for 'PPG.Security.LoginManager' threw an exception. : at PPG.Security.LoginManager.Login(String user, String password, Boolean UseEmailAsKey, Guid& CredentialToken)
at PPG.Facade.General.Login(String username, String password)
at PPG.FlexService.Users.Login(String userName, String password)"] messageId="87D0435C-8E7D-474C-9F64-987A8280EEBC" type="fault" bubbles=false cancelable=true eventPhase=2]
потом еще одна
The type initializer for 'PPG.bl.States' threw an exception.
И все, войти нельзя, кнопка Sign In запрещена.
У кого то еще такое есть? или это у меня что то жестко глючит.
Всем яростно минусующим — читать здесь. Хоть и для АСПа, но в основах верно и для Флекса и т.п.
В частности:
The more information a hacker can gather about a Web site, the more likely it is that he will be able to successfully attack it. An error message can be of vital significance to an attacker. A default ASP.NET error message lists the specific versions of ASP.NET and the .NET framework which are being used by the Web server, as well as the type of exception that was thrown. Just knowing which Web-based applications are used (in this case ASP.NET) compromises application security by telling the attacker that the server is running a relatively recent version of Microsoft Windows and that Microsoft Internet Information Server (IIS) 6.0 or later is being used as the Web server.
Если смотреть на тот кусок вырванного стек-трейса, то очень интересен контракт вызванного метода:
PPG.Security.LoginManager.Login(String user, String password, Boolean UseEmailAsKey, Guid& CredentialToken)
т.е. пароль передается открытым текстом, великолепно! А если предположить, что это flex веб-приложение (я не спец по нему, могу ошибаться), то открытый пароль передается уже с клиента на сервер (PPG.Security.LoginManager.Login вызывается на клиенте, который вызывает метод сервиса на сервере PPG.FlexService.Users.Login), что просто кричит "захады дарагой, гостэм будэш".
Т.е. 1) делаем проксирующий дефейс (не забывая про SSL) страницы логина 2) складываем все логин/пароли к себе 3) профит. Или и того легче: снифаем ваш трафик (ISP провайдер, инет-кафе, WiFi) + 2)+3).
И это только беглый взгляд.
зы: M.A.D — вы же тестируете приложения за деньги, причем как организация, и ваш глаз не зацепился за эту проблему! нихира себе, ребята (с) Бородач
Здравствуйте, AnonThisTime, Вы писали:
ATT>Всем яростно минусующим — читать здесь. Хоть и для АСПа, но в основах верно и для Флекса и т.п. ATT>В частности: ATT>The more information a hacker can gather about a Web site, the more likely it is that he will be able to successfully attack it. An error message can be of vital significance to an attacker. A default ASP.NET error message lists the specific versions of ASP.NET and the .NET framework which are being used by the Web server, as well as the type of exception that was thrown. Just knowing which Web-based applications are used (in this case ASP.NET) compromises application security by telling the attacker that the server is running a relatively recent version of Microsoft Windows and that Microsoft Internet Information Server (IIS) 6.0 or later is being used as the Web server.
ATT>Если смотреть на тот кусок вырванного стек-трейса, то очень интересен контракт вызванного метода: ATT>PPG.Security.LoginManager.Login(String user, String password, Boolean UseEmailAsKey, Guid& CredentialToken)
ATT>т.е. пароль передается открытым текстом, великолепно! А если предположить, что это flex веб-приложение (я не спец по нему, могу ошибаться), то открытый пароль передается уже с клиента на сервер (PPG.Security.LoginManager.Login вызывается на клиенте, который вызывает метод сервиса на сервере PPG.FlexService.Users.Login), что просто кричит "захады дарагой, гостэм будэш". ATT>Т.е. 1) делаем проксирующий дефейс (не забывая про SSL) страницы логина 2) складываем все логин/пароли к себе 3) профит. Или и того легче: снифаем ваш трафик (ISP провайдер, инет-кафе, WiFi) + 2)+3). ATT>И это только беглый взгляд.
ATT>зы: M.A.D — вы же тестируете приложения за деньги, причем как организация, и ваш глаз не зацепился за эту проблему! нихира себе, ребята (с) Бородач
Вы перегоняете пароли в открытом виде? Думаю, что тут, что-то типа md5 от пароля — не более. Вы когда-нибудь действительно занимались похищением паролей? Настраивание проксей и прочее?
Здравствуйте, Neud, Вы писали:
N>Вы перегоняете пароли в открытом виде? Думаю, что тут, что-то типа md5 от пароля — не более. Вы когда-нибудь действительно занимались похищением паролей? Настраивание проксей и прочее?
1. причем здесь "Вы перегоняете пароли в открытом виде"? Я о себе говорил?
2. Думать можно что угодно. Юзайте md5 на здоровье, только скажите названия приложений, чтобы обходить их стороной.
3. ээээ...причем здесь я?
Здравствуйте, AnonThisTime, Вы писали:
ATT>Здравствуйте, Neud, Вы писали:
N>>Вы перегоняете пароли в открытом виде? Думаю, что тут, что-то типа md5 от пароля — не более. Вы когда-нибудь действительно занимались похищением паролей? Настраивание проксей и прочее?
ATT>1. причем здесь "Вы перегоняете пароли в открытом виде"? Я о себе говорил? ATT>2. Думать можно что угодно. Юзайте md5 на здоровье, только скажите названия приложений, чтобы обходить их стороной. ATT>3. ээээ...причем здесь я?
Ну вы высказали теорию, о том, что стэк не стоит показывать пользователю. Это и да и нет, но не как не показатель плохих программистов. Перехват паролей, по ssl, да еще и в asp.net это довольно не простая вещь. Вот я и спрашиваю, вы этим занимались?
N>>>Вы перегоняете пароли в открытом виде? Думаю, что тут, что-то типа md5 от пароля — не более. Вы когда-нибудь действительно занимались похищением паролей? Настраивание проксей и прочее?
ATT>>1. причем здесь "Вы перегоняете пароли в открытом виде"? Я о себе говорил? ATT>>2. Думать можно что угодно. Юзайте md5 на здоровье, только скажите названия приложений, чтобы обходить их стороной. ATT>>3. ээээ...причем здесь я? N>Ну вы высказали теорию, о том, что стэк не стоит показывать пользователю. Это и да и нет, но не как не показатель плохих программистов. Перехват паролей, по ssl, да еще и в asp.net это довольно не простая вещь. Вот я и спрашиваю, вы этим занимались?
О какой теории вы говорите? Т.е. чтобы защитить какую-то часть своего приложения/сервиса, где теоретически может быть угнана ключевая информация внутренностей, я должен обязательно сначало взломать незащищенную версию? А если не взломаю, то не защищать ибо "ну не хакер я, значит и другие не сломают"? Не долго такой сервис проживет.
Я привел ссылку с очень растространенными вариантами появления дыр в защите, и тут стек-трейс — это только один из элементов вытекшей информации. И это таки "показатель плохих программистов", я бы сказал даже нубов (возможно и по неосторожности). Ибо если чел пишет веб-сервис, то знание таких ньюансов, это как отче наш. Почитайте гайды по секьюрити, а в особенности параграф "Do Not Reveal Exception Details to the Client":
When exceptions occur, return concise error messages to the client and log specific details on the server. Do not reveal internal system or application details, such as stack traces, SQL statement fragments, and table or database names to the client. Ensure that this type of information is not allowed to propagate to the end user or beyond your current trust boundary. A malicious user could use system-level diagnostic information to learn about your application and probe for weaknesses to exploit in future attacks.......
и у вас не возникнет такого: "стэк не стоит показывать пользователю. Это и да и нет, но не как не показатель плохих программистов".
Перехват паролей, по ssl, да еще и в asp.net это довольно не простая вещь
асп.нет это всего лишь платформа, на которой также можно писать говнокод, т.е. "да еще и в asp.net" не добавляет защиты в неумелые руки. Тут тонны вариантов хака.
С SSL сложнее, но не невозможно. Вон недавно пробегало, что взломали SSL 1.0 просто подсунув червя между клиентом и сервером (в ISP или сервер интернет-кафе например)!
Это конечно неправильно, но на самом деле информация об исключении не так страшно, как использование открытых паролей или "что-то вроде md5". Я так понимаю сервис можно считать скомпрометированным? По крайней мере до тех пор пока не найдут нормальных кодеров и не перелопатят движок на предмет уязвимостей.
Здравствуйте, grosborn, Вы писали:
G>Это конечно неправильно, но на самом деле информация об исключении не так страшно, как использование открытых паролей или "что-то вроде md5".
Вы совершенно правы! Гораздо лучше чтобы пароли передавались телепатически и так же телепатически еще и принимались.
О каком открытом виде передачи пароля идет речь, если весь уходящий из браузера на сайт панели трафик шифруется публичным ключом TLS 1.0 (SSL 3.1) и расшифровываться приватным ключом на сайте этого сервиса. Обоснуйте, пожалуйста.
Может и я тогда тоже для доступа покупателей к панельке управления купленными модулями небезопасно пароли шифрую с помощью безопасного логина через TLS соединение, как в Gmail?
> Вы совершенно правы! Гораздо лучше чтобы пароли передавались телепатически и так же телепатически еще и принимались.
Не. Кажись в вавилоне пять телепаты перехватывали пароли И вообще, пример с телепатом-перехватчиком разбирается как простейший пример при рассмотрении уязвимостей. Так что лучше, если пароль никто не знает и никто не видел, ыыыы....
> О каком открытом виде передачи пароля идет речь, если весь уходящий из браузера на сайт панели трафик шифруется публичным ключом TLS 1.0 (SSL 3.1) и расшифровываться приватным ключом на сайте этого сервиса. Обоснуйте, пожалуйста. > Может и я тогда тоже для доступа покупателей к панельке управления купленными модулями небезопасно пароли шифрую с помощью безопасного логина через TLS соединение, как в Gmail?
Я не специалист по криптосистемам. Да пусть меня поправят, если что не так напишу.
Несимметричные алгоритмы используются только при генерации сеансовых ключей.
Для передачи текущего трафика используются обычные симметричный алгоритмы шифрования сенсовым ключом, соль не используется, алгоритмы замедления (антибрутфорс) не используются.
Подход: восстановление исходного кода той части, что у вас передает пароль, получение алгоритма выделяющего из исходящего трафика пакета передачи пароля. Если этот шаг удачен и если пароль внутри tsl вы передаете открытым, то брутфорс по словарю или сразу даст пароль или даст сравнительно небольшой набор, с помощью которого можно будет его подобрать.
Лучше бы конечно специалиста спросить.
Здравствуйте, grosborn, Вы писали:
G>Лучше бы конечно специалиста спросить.
Лучший способ обезопасить логин, а так же другую информацию, передаваемую на сайт, является использование современных криптографических протоколов — TLS (SSL 3.1)
Если знаете что-то лучше этого — дайте знать.
В форумах типа вобла (vBulletin) вводили механизм передачи хешированого пароля с помощью JavaScript — а смысл? На сервере сравнивался этот же хеш с сохраненным, т.е. проснифив хеш передаваемый на сервер, злоумышленник так же может и сам передать его. В этом случае паролем выступает MD5 хеш пароля.
Единственный способ безопасно передать данные на сервер — использование криптографического протокола. И ничего тогда лишнего выдумывать не надо. Весь трафик будет шифрованный. Для некоторых CMS есть модули позволяющие осуществлять безопасный логин, например — http://drupal.org/project/securelogin
Более надежный способ аутентификации — двухфакторыный. Передача вместе с тем что вы знаете (пароль) еще и чего-то что есть только у вас (железяка генерирующая токен, смс код который вы получите на свой телефон) или чего-то кем вы являетесь (скан сетчатки глаза, ваше ДНК, отпечатки пальцев)
Но это уже совсем другая история.
Действительно интересно мнение авторитетных специалистов по безопасности веб-сайтов.
Если есть какой-то более безопасный метод передачи данных на сайт, кроме как через HTTPS с использованием TLS — дайте знать.
> Если есть какой-то более безопасный метод передачи данных на сайт, кроме как через HTTPS с использованием TLS — дайте знать.
Достаточно будет зашифровать пароль с солью, с нефиксированной длиной пакета и можно передавать по https.
Хэш md5 выбросить ф топку, для целей безопасности он уже не годится.
Использовать ключ и длину пакета от 1к.
Точнее зашифровать хэш пароля. Вам же хэш передать нужно? И в общем случае не использовать md5 хэш, а как минимум SHA512++, хотя рекомендуется что-то посильнее. Ну и хэш вы правильно написали, не должен быть сформирован только из исходного пароля.
Здравствуйте, grosborn, Вы писали:
G>Точнее зашифровать хэш пароля. Вам же хэш передать нужно? И в общем случае не использовать md5 хэш, а как минимум SHA512++, хотя рекомендуется что-то посильнее. Ну и хэш вы правильно написали, не должен быть сформирован только из исходного пароля.
Ну... SHA512 симметричный алгоритм шифрования. Т.е. salt на сервере (сайт) и клиенте (браузер пользователя) будет одним и тем же.
Получить salt с клиента по сложности равносильно получить пароль в открытом или хэшированом виде, т.к. хеширование с применением сальта будет происходить на клиенте (JavaScript или Flash-плеер)
Смысла в этом нет.
Другое дело можно применить асимметричное шифрование, когда вместо сальта будет использоваться открытый ключ.
И тут... мы приходим к тому что это уже сделано. C помощью SSL >3.0.
Асимметрично шифровать пароль, чтобы потом его передать через HTTPS где шифрование всего трафика (а не только пароля) работает по тому же принципу, не слишком ли извращенно и параноидально?
Безопасное соединение на то и является безопасным, т.к. HTTPS с применением современных сертификатов безопасности гарантирует с большой достоверностью безопасность передаваемых данных. Шифрование используя TLS (http://ru.wikipedia.org/wiki/TLS) намного более продумано и проверенно временем чем предложенное симметричное шифрование пароля с сальтом.
Пока это предложение с шифрованием пароля на стороне клиента с помощью симметричной криптографии типа SHA-2 и salt кажется как бы не особо подходящим, особенно в плане безопасности.
> Ну... SHA512 симметричный алгоритм шифрования. Т.е. salt на сервере (сайт) и клиенте (браузер пользователя) будет одним и тем же. > Получить salt с клиента по сложности равносильно получить пароль в открытом или хэшированом виде, т.к. хеширование с применением сальта будет происходить на клиенте (JavaScript или Flash-плеер) > Смысла в этом нет. > Другое дело можно применить асимметричное шифрование, когда вместо сальта будет использоваться открытый ключ. > И тут... мы приходим к тому что это уже сделано. C помощью SSL >3.0.
Я же писал, ssl это симметричное некриптостойкое шифрование сеансовым ключом.
Соответственно если есть возможность перхватить трафик и позиционировать ваш открытый пароль в шифрованном трафике, то ssl ломается, если позиционируем в трафике хэш пароля известного алгоритма (msd5), то опять ломается.
> Асимметрично шифровать пароль, чтобы потом его передать через HTTPS где шифрование всего трафика (а не только пароля) работает по тому же принципу, не слишком ли извращенно и параноидально?
SSL несколько для иных целей сделан, чем для передачи паролей.
> Безопасное соединение на то и является безопасным, т.к. HTTPS с применением современных сертификатов безопасности гарантирует с большой достоверностью безопасность передаваемых данных. Шифрование используя TLS
Опять же сертификаты. Я не специалист, но вроде бы удостоверяется только одна сторона — сервер. Мы же передаем данные с клиента, то есть с неудостоверенной сертификатами стороны. И даже если бы удостоверялся клиент, телепат-перехватчик тоже может быть удостоверен.
---
Проблема в том, что все эти заборы-огороды создают видимость защищенности, а на самом деле одна маленькая дырка все ломает.
PK>Ну... SHA512 симметричный алгоритм шифрования. Т.е. salt на сервере (сайт) и клиенте (браузер пользователя) будет одним и тем же. PK>Получить salt с клиента по сложности равносильно получить пароль в открытом или хэшированом виде, т.к. хеширование с применением сальта будет происходить на клиенте (JavaScript или Flash-плеер) PK>Смысла в этом нет.
SHA это не шифрование! Не ясно, что значит "получить salt с клиента" и в чем не смысла.
PK>Другое дело можно применить асимметричное шифрование, когда вместо сальта будет использоваться открытый ключ. PK>И тут... мы приходим к тому что это уже сделано. C помощью SSL >3.0. PK>Асимметрично шифровать пароль, чтобы потом его передать через HTTPS где шифрование всего трафика (а не только пароля) работает по тому же принципу, не слишком ли извращенно и параноидально?
далеко-далеко не параноидально, когда речь идет о деньгах и/в финансовых системах! Представьте, что в один прекрасный день Вася добавил код в результате чего в качестве транспорта теперь юзается обычный http.
PK>Безопасное соединение на то и является безопасным, т.к. HTTPS с применением современных сертификатов безопасности гарантирует с большой достоверностью безопасность передаваемых данных. Шифрование используя TLS (http://ru.wikipedia.org/wiki/TLS) намного более продумано и проверенно временем чем предложенное симметричное шифрование пароля с сальтом.
в данной ситуации (передача пароля) надежность у обоих одинаковая и проверенность у них обоих одинаковая. Уже SHA256 не поддается расшифровке в разумных временных рамках. У них просто назначение разное. хеширование — для первичного "рукопожатия" (логина) клиента/сервера, а дальше траф не криптованный, SSL — для шифрования трафа на всем периоде сессии пользователя.
PK>Пока это предложение с шифрованием пароля на стороне клиента с помощью симметричной криптографии типа SHA-2 и salt кажется как бы не особо подходящим, особенно в плане безопасности.
и так же телепатически еще и принимались.