Любой файл с расширением .py я могу либо запустить, либо открыть в ide/текст.редакторе и посмотреть исходный код скрипта... Это прекрасно и ничего против этого я не имею, но как быть, если мое приложение общается с базой данных, регистрирует пользователей? Ведь круг лиц, которые имеют доступ к базе и знают соль для регистрации пользователей, имеет критическое значение для безопасности данных и вообще приложения... впрочем, вы сами все прекрасно знаете... Так вот, подскажите, пожалуйста, как обычно решают такие вопросы и как дальше жить

Ты слишком рано задался подобными вопросами )

Тебя интересует безопасность сайтов(и баз данных к ним ) или исходников?

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

rater,

Многослойная архитектура (n-tier client-server architecture) - клиент-серверная архитектура, где процессы представления, обработки и управления данными являются логически отделенными друг от друга процессами. Модель многослойной архитектуры помогает создать гибкое и многократно используемое программное обеспечение. В случае изменений надо их делать лишь в отдельных слоях, а не сразу во всем приложении. Это сулит меньше работы, меньших затрат времени и меньше потенциальных ошибок.

Более типичным и более используемым вариантом является трехслойная архитектура (three-tier client server architecture). В случае трехслойного приложения каждый слой располагается в разных местах в компьютерной сети и может располагаться также ​​на разных платформах.

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

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

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

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

Часть содержания может быть статической и часть - динамической.

Обобщением является многослойная архитектура (n-tier architcture). Здесь различные слои могут добавляться по мере необходимости (или описанные слои могут быть разделены, в свою очередь, на части). В ситуации, когда все большая ценность имеется не у одиночных приложений или баз данных, а у взаимодействующих информационных систем, узкое место в разработке переместилось в сторону создания интерфейсов и интеграции систем. Немаловажно использовать проверенные практики (например, шаблоны для разрешения аналогичных проблем), сервис-ориентированный подход, семантическое описание информационных систем.

rater
С сайтами как раз все ясно - там пользователь не может посмотреть бэкенд. Меня интересует именно как быть с десктопными приложениями. Если я поставляю свое по в виде набора .py файлов, то любой может открыть исходник и посмотреть логины, пароли, адреса бд. Меня интересует куда обычно прячут эти данные и в каком виде их держат.

Настройки вынести в конфигурационный файл. Безопасность файла обеспечить средствами ОС. Если средств недостаточно - шифровать файл и расшифровывать при запуске. А вот это “то любой может открыть исходник и посмотреть логины, пароли, адреса бд” - называется “безопасность через обфускацию”, это сродни закапыванию страусом головы в песок.

ЗЫ: темой навеяло, как меня бесят банки, что жмотятся на нормальный сертификат, присылают филькину грамоту и требуют установить :(

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

Попробую просуммировать. Возможны следующие примитивные варианты, которых вам должно хватить.
вариант 1 Защита ОС
У пользователя нет доступа на чтение файлов исходников и тем более логинов (секретная инфа в код никогда вообще не помещается)
вариант 2 шифровка
Сохраняются не пароли а Хеши
http://ru.wikipedia.org/wiki/MD5
http://ru.wikipedia.org/wiki/SHA-2
вариант 2.5 инструменты в СУБД
Используем административные инструменты СУБД.

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

rater
сделай на сервере APIи общайся с ними через програму)

Может, кто-то знает более гуманные варианты?)