Давайте добавлю свои 5 копеек к обсуждению...
Тут приводился контраргумент на тему организации системы security средствами app-сервера, сводящийся к тому, что на app-сервере можно выполнить sql-injection и т.п. Не обсуждая саму такую возможность и следовательно криво написанный app-сервер, скажу, что для случая удаленного доступа к СУБД (не из локальной сети) существует довольно обоснованное правило закрывать доступ к СУБД снаружи, т.к. довольно часто обнаруживаются различные уязвимости, да и всякие DoS - атаки никто не отменял. В принципе и с использованием 3-х звенной архитектуры не мешает правильно настроить security на уровне СУБД, но дополнительный уровень защиты будет совсем не лишним (особенно в случае удаленного доступа). Я помню время, когда достаточно регулярно появлялись различные дыры и черви под MSSQL - это нам много проблем доставило.

softwarer"Клиент-серверной" аналогией этого будет СУБД, в которой защита реализована целиком на клиенте, и достаточно подсоединиться к БД через sqlplus, чтобы сделать в базе что угодно.
Аналогия не совсем правильная - например для моего примера удаленного доступа (с закрытой снаружи СУБД) "обмануть" app-сервер (в смысле обойти его) не получится - можно его только взломать.
И в этом случае вопрос
softwarerВопрос в том, что надежность аппсервера (как кода, написанного для решения частной задачи) в этом разрезе заведомо ниже, нежели надежность любой стандартной системы безопасности (в том числе СУБДшной). является довольно интересным. Cтандартная система безопасности СУБД не всегда "лучше кода, написанного для решения частной задачи". Особенно если одной из этих частных задач является как раз обеспечить максимальный уровень безопасности. Ну что за примерами ходить - встроенная система безопасности MSSQL 2000 довольно хлипкая сама по себе (если не используется Windows-аутентификация, что для удаленного доступа как раз неудобно). Есть практически "стандартные" хакерские средства для ее взлома, которые успешно используются. Т.е. этот принцип может быть в общем случае и верен, но дьявол, как известно, прячется в деталях.

здесь
Особенно интересна самая верхняя статейка (в конце дается ссылка на программу для взлома).
здесь - то же самое
То, что хэш вычисляется для 2-х вариантов пароля - оригинального и upper-cased, соответственно по upper-cased варианту его проще подобрать.
Конечно, если очень длинные пароли вводить, то это не проблема, но разве у всех поользователей в вашей базе пароль длиннее 6-7 символов?

Разумеется, для того, чтобы так подбирать пароли, надо выцепить этот хэш, а для этого наверное иметь хоть какие-то права на уровне MSSQL или Windows - но это решается другими методами :)

ChAМетодом brute-force можно взломать практически любую систему, при соблюдении определенных условий, и ничем особым тут MSSQL не выделяется. Для этого даже не надо вычислять хешей. Кстати, с программой "John the Ripper" когда-нибудь сталкивались, чем она занимается в курсе ?
В курсе. Насчет того, что любую систему можно взломать методом brute-force - я и не спорю. Подбор паролей без вычисления хэша - гораздо более длительная операция и нормальные системы ее удлиняют еще сильнее, не давая к примеру логиниться за одну сессию больше нескольких раз.
Так что вопрос только во времени взлома. Если эта система позволяет на порядок сократить время такого взлома (как в случае с MSSQL обстоит дело) - значит что-то в ней не так...

tygraА в вашей системе нет вообще уязвимостей? Пароль подобрать нельзя? Просто взломать - нельзя? Вы наверное патентованными методами пользуетесь - MS до них не доросла пока?
Блин, детский сад
Изобреталей влосипедов
Это вы к чему, интересно? По существу вам сказать опять нечего? Переходить на личности - это у вас как я вижу самый главный аргумент.
Насчет доступа только под правами админа - почитайте здесь . Это некоторые ваши заблуждения на этот счет развеет (если вы конечно будете это читать, в чем у меня есть сомнения судя по вашему сообщению). А вообще, на будущее - после еще одного сообщения в таком стиле дальнейшие ваши сообщения я буду игнорировать.

ChAНаверное ? Понятно, Вы, несомненно, очень крупный специалист по MSSQL. Впрочем, tygra уже все сказал.
Присоединяетесь к тигре? Да ради бога... Вы сторонник открытого доступа к MSSQL снаружи? Ну что же, флаг Вам в руки. Слабость хранения хэшей в MSSQL - просто один из примеров, которых и без этого достаточно. Поверьте, грамотному специалисту взломать типичный MS SQL сервер (который админит не настолько же грамотный специалист) не составит особого труда. Конечно, для всяких средств взлома есть методы противодействия, но чтобы полностью обезопасить свою СУБД самый дешевый и надежный способ - закрыть к ней доступ снаружи. Остальные способы дороже, как минимум на разницу зарплаты типичного админа и хорошего специалиста по компьютерной безопасности, которых не так много.

ChAПолистал, но не понял, причем здесь MS. Подобных способов хоть отбавляй практически к любой достаточно популярной системе, например, как ее взломать, как получить администраторские права, exploits и прочая хрень. Более того, некоторые до сих пор работают. Или Вы будете настаивать, что этими недостатками больны только продукты MS .
Я не пойму, вы надо мной издеваетесь? Здесь кажется речь шла о том, что _очень_ желательно держать СУБД закрытой снаружи на сетевом уровне, потому как существует масса exploits и прочей хрени как вы говорите. В качестве примера я привел парочку для MSSQL, т.к. в безопасности других СУБД я плохо ориентируюсь. Вы же мне здесь сами и подтвердили мою точку зрения. А при чем здесь MS - я не знаю, вопрос конкретно про MS вообще не стоял. Вы сами перевели разговор в эту плоскость.
Если все согласны с тем, что СУБД надо держать закрытой снаружи, то теперь, внимание, вопрос: каким образом организовывать удаленный доступ к системе? Есть 2 варианта - или терминальный доступ или промежуточное звено. Причем терминальный доступ - это тоже не самая удобная вещь в плане безопасности под windows. начиная от уязвимости windows terminal services к DoS - атакам и заканчивая просто сложностью правильной настройки security, чтобы к примеру пользователь не мог ничего больше делать кроме использования указанного приложения.

ChAВот только передергивать не надо. Тема Вашей реплики и моего вопроса были совсем другие. Не думаю, что вообще есть сторонники открытого доступа к любой СУБД, не сломают, так завалят. В конце концов, они ведь создавались для другой среды и целей. Правда это уже совсем другая тема.
Тема разговора была как раз об этом. Не верите - прочитайте последние 10 сообщений. Это как раз Вы начали уводить разговор в другую сторону, а я просто дал ссылки на интересующую Вас информацию.

ChAДа, да, разумеется :) Там одни лохи сидят :)
Насколько понимаю, подобной же слабостью страдают практически все системы с хешированием паролей,
Пример в студию! В какой еще системе пароль хэшируется в upper-cased - варианте? Это между прочим раз в 10-20 сокращает время подбора типичного пароля.

tygraЕсть еще VPN - очень хорошо защищает. Или у вас и про нее pdf-ы имеются? :)
Согласен, VPN - это тоже вариант, но не для всех случаев он подходит. PDF-ы приводить не буду, хотя их тоже хватает :).

tygraИ никакой самодеятельности в security.
Интересно... Ну-ка, расскажите мне, как вы без самодеятельности в security сможете обеспечить аутентификацию через веб-сервисы? Единственный стандартный в настоящее время вариант - через windows-аутентификацию, что для удаленного доступа неудобно.

tygraТо, что вам app-сервер ходит под sa в СУБД, никак не увеличивает безопасности - как бы вы внутри арр-сервера не извращались, к СУБД доступ все-равно можно получить и без него, а тогда смысл в извращениях теряется.
Я здесь где-то упоминал про хождение апп-сервера под sa? В этом топике я кстати вообще тему апп-сервера не поднимал, но у вас какая-то болезненная реакция на мои посты - везде чудится сервер приложений :). Насчет промежуточного звена я писал выше, что оно не отменяет настройки security на уровне СУБД. Справедливости ради могу только сказать, что если например открыть доступ к СУБД только app-серверу на сетевом уровне, то никакой пользователь напрямую к базе данных не достучится. Это тоже один из вариантов обеспечения безопасности, в некоторых случаях единственный.

tygra
Да в общем странный разговор - куча компаний работают без арр-серверов и ничего. А если трясти бумажками с расписанными хакерскими методами ... Насчет кучи компаний - это не аргумент. Вернее такой же аргумент как и "раз они потратили на этот сервер XXX M$, значит с безопасностью у него все нормально. Не вижу никакой корелляции. На разработку Windows 2000 были потрачены огромные деньги, тем не менее попробуйте поставить ее без сервис-паков на открытую машину - максимум в течение часа она станет сервером спам-рассылки для китайских подростков :)

По теме этого сообщения у вас есть что сказать?
Как вы думаете, какой вариант будет более универсальным и защищенным - через веб-сервисы коннект к внешнему http-серверу, доступ внутрь сети через VPN или терминальный доступ? Разумеется, последние 2 - это тоже приемлемые варианты, можно поместить сервер доступа в dmz с возможностью коннекта только к СУБД и никуда более и т.п. Просто организационно более трудоемкие и менее безопасные. Зато с их помощью можно организовать так любимый вами прямой коннект клиента к sql-серверу.

2ChA - я жду примеров :)

Да, tygra, чтобы облегчить ответ на вопрос, приведу более конкретный пример. Есть система заказов. Есть торговая компания, у нее есть партнеры (очень много, количество может тысячами измеряться). Каждому предоставляется доступ к системе заказов. Как бы вы реализовали удаленный доступ в этой системе? (промежуточный слой на вебсервисах, терминальный доступ, vpn, ваш вариант). P.S. Приложение обязательно должно быть десктопным, не web (по условиям задачи).

P.S. последний вопрос не только для tygra, пусть все желающие что-нибудь скажут на эту тему, т.е. достоинства и недостатки того или иного способа, и какой из них лучше подходит с точки зрения безопасности...