Привет ребята! Появилась проблема. Из десктопного приложения происходит подключение к удаленной БД (MySQL). Пароль зашит в приложение.
Что можно сделать, что бы нельзя было получить пароль через тот же например дебагер?

Здравствуйте, Аноним, Вы писали:

А>Привет ребята! Появилась проблема. Из десктопного приложения происходит подключение к удаленной БД (MySQL). Пароль зашит в приложение.
А>Что можно сделать, что бы нельзя было получить пароль через тот же например дебагер?

Не зашивать пароль в приложение.

А>Привет ребята! Появилась проблема. Из десктопного приложения происходит подключение к удаленной БД (MySQL). Пароль зашит в приложение.
А>Что можно сделать, что бы нельзя было получить пароль через тот же например дебагер?
Если без пароля никак(иногда бывает) — в файл конфига, а сам файл шифровать (прйват ключ/сертификат пользователя/локалхоста/свой вариант) и доступ к нему ограничить — только в прогу ничего зашивать не стоит. Будет больно бить потом по попе, если произойдет утечка(но Вы это и сами поняли). В идеале и ключ шифрования должен быть на удаденном хосте/выделеном репозитории ключей.

Здравствуйте, Аноним, Вы писали:

А>Привет ребята! Появилась проблема. Из десктопного приложения происходит подключение к удаленной БД (MySQL). Пароль зашит в приложение.
А>Что можно сделать, что бы нельзя было получить пароль через тот же например дебагер?

Правильное решение — ограничить доступ на уровне БД.

Обфускация

Здравствуйте, Аноним, Вы писали:

> Что можно сделать, что бы нельзя было получить пароль через тот же например дебагер?

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

1. Не делать таких входов вообще
2. Там, где они действительно абсолютно необходимы, выдавать им минимальный набор прав в БД, так, чтобы раскрытие пароля не давало ничего существенного.

S>пользователь с отладчиком всегда будет иметь возможность залогиниться от имени приложения. Поэтому правильных решений два:
Каким образом? Если у пользователя только бинарник и ключей шифрования/файла с паролем нету. С зашитым паролем — запустил — подебажил — получил юзера и пароль на любом компе.

S>1. Не делать таких входов вообще
не всегда возможно, особенно если приложение написано и уже работает...

S>2. Там, где они действительно абсолютно необходимы, выдавать им минимальный набор прав в БД, так, чтобы раскрытие пароля не давало ничего существенного.
Как Вы в этом случает предлагаете реализовать доступ к "существенным данным", нужным для работы приложения?

Здравствуйте, Alyash77, Вы писали:

A>Каким образом? Если у пользователя только бинарник и ключей шифрования/файла с паролем нету.

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

A>С зашитым паролем — запустил — подебажил — получил юзера и пароль на любом компе.

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

С точки зрения скомпрометированной системы работа приложения для получения искомого сервиса заключается в последовательном обращении к одному или нескольким сервисам, размещённым на надёжных системах. Входными данными для таких обращений является некоторая комбинация из:

1. Данных, размещённых на скомпрометированной системе
2. Общедоступных данных (имени компьютера, сетевого адреса, даты-времени итп)
3. Данных, полученных от участвующих сервисов.

Всё. Все эти данные доступны злоумышленнику и открыты для фальсификаций, следовательно, он может воспроизвести процесс под своим управлением и добиться результата. При любой, сколь угодно сложной конфигурации "защиты" злоумышленник может в самом худшем случае полностью воспроизвести процесс и получить права на доступ к искомому сервису. А в 99% случаев весь этот геморрой обходится за считанные минуты — поставить точку останова, дождаться, пока приложение инициализирует все ключи, запустит все сервисы, всё идентифицирует и расшифрует, и наконец, когда оно получило чистый пароль, взять его в точке останова и радостно пойти работать с базой в консоли. То есть, грубо говоря: знаем, что приложение работает с Oracle, ставим точку останова в OCILogon, получаем имя-пароль, искренне смеёмся над теми "разработчиками", которые провели сотни, если не тысячи, часов в придумывании и реализации сложных схем с ключами и шифрами и наивно полагают, что кто-то будет пытаться разобраться в их изделиях.

S>>1. Не делать таких входов вообще
A>не всегда возможно,

Тем не менее, если взять это за принцип, оказывается, что чаще всего возможно

S>>2. Там, где они действительно абсолютно необходимы, выдавать им минимальный набор прав в БД, так, чтобы раскрытие пароля не давало ничего существенного.
A>Как Вы в этом случает предлагаете реализовать доступ к "существенным данным", нужным для работы приложения?

Применением головы на этапе проектирования системы. Приложению не нужен доступ к "существенным данным". Если доступ нужен пользователю — он должен включаться только по предъявлению пароля (ключа, флешки итп) этого пользователя. Если нужен какой-нибудь автоматизированный процесс — его логику можно положить внутрь БД или другой надёжной системы, а на долю приложения оставить только дёрганье нестрашных сервисов (скажем, запуск обработки этих данных). Скажем, репликация: вот, казалось бы, процесс, который обязательно автоматический и обязательно получает "существенные данные". Но если подумать — этому процессу нужны по сути две операции, "дай мне пакет данных" и "возьми от меня пакет данных". Содержание пакетов при этом — чёрный ящик, его можно закрыть от распознавания и искажения шифрами-подписями с надёжных систем. А аккаунт приложения, если и будет получен злоумышленником, позволит только поработать вместо репликатора.

На практике основной источник "существенные данные нужны для работы приложения" — идиотизм под названием "мы будем лазить в базу под общим логином, а безопасность сами сбацаем как-нибудь на клиенте". Для десктопного клиент-сервера это безусловно недопустимый метод, но и его как правило можно решить малой кровью, например, в Oracle это можно сделать через application roles. В этом случае злоумышленник, узнав "общий пароль к БД" и законнектившись, обнаружит, что у него вообще нет прав, а права появятся только после того, как он введёт личный пароль (и из базы он таким образом получит только то, что и так мог быть получить в интерфейсе приложения).

S>Всё. Все эти данные доступны злоумышленнику и открыты для фальсификаций, следовательно, он может воспроизвести процесс под своим управлением и добиться результата. При любой, сколь угодно сложной конфигурации "защиты" злоумышленник может в самом худшем случае полностью воспроизвести процесс и получить права на доступ к искомому сервису.
Абсолютной защиты создать и невозможно. В случае "злобного хардкода" — пароль получаем простым рефакторингом или дебагом. Изменения пароля тянет за собой очередной релиз.
При внешнем конфиге+ключах — пароль может быть изменен в течении минут (если фактор взлома таки установлен) кроме того переодическое его изменение отвязано от релизов.

S>Тем не менее, если взять это за принцип, оказывается, что чаще всего возможно
В теории — да. На практике (корпорация 100+ приложения, зоопарк технологий Rubby/Java/ASP/ASP.Net) не совсем так.

S>Если доступ нужен пользователю — он должен включаться только по предъявлению пароля (ключа, флешки итп) этого пользователя.
Десктоп/внутрикорпоративное — да. Веб — не взлетит. Доступ нужен приложению, а пользователь только определяет зоны этого доступа. Часто не только он а и геолокейшн, домен входа итд.

S>Если нужен какой-нибудь автоматизированный процесс — его логику можно положить внутрь БД или другой надёжной системы, а на долю приложения оставить только дёрганье нестрашных сервисов (скажем, запуск обработки этих данных).
Автоматизированый процес тоже приложение(предполагаем что внешнее) — и точно также может быть скомпроментировано. Считать его "надежным" слишком смело. Логика его работы мало зависит от конкретного пользователе (для примера — анализатор лога транзакций).

S>На практике основной источник "существенные данные нужны для работы приложения" — идиотизм под названием "мы будем лазить в базу под общим логином, а безопасность сами сбацаем как-нибудь на клиенте".
До тех пор пока вы можете заставить пользователя аутинфицироваться ДО использования приложения. Это не всегда возможно вне финансов/банкинга.

S>Для десктопного клиент-сервера это безусловно недопустимый метод, но и его как правило можно решить малой кровью, например, в Oracle это можно сделать через application roles. В этом случае злоумышленник, узнав "общий пароль к БД" и законнектившись, обнаружит, что у него вообще нет прав, а права появятся только после того, как он введёт личный пароль (и из базы он таким образом получит только то, что и так мог быть получить в интерфейсе приложения).
Для веб-приложений такой подход работать будет очень плохо. Держать ВСЮ базу пользователей и их права доступа на уровне базы, а также их поддерживать очень нетривиальная и дорогая задача.

Здравствуйте, Alyash77, Вы писали:

A>Десктоп/внутрикорпоративное — да. Веб — не взлетит.

Посмотрите на стартовое сообщение топика. Я не вижу там слова "веб", зато вижу "десктоп" и явный клиент-сервер. Давайте придерживаться темы. По поводу веба, если хотите, давайте поговорим отдельно, когда разберёмся с десктопом.

A>Абсолютной защиты создать и невозможно.

Это не повод рекламировать уровень "ключ под половичком". Преимущества внешних карманов-кошельков-шифров над вшитым паролем малозначимы (для уникальных приложений — стоимость их разработки по сравнению со стоимостью взлома явно не окупается).

A>При внешнем конфиге+ключах — пароль может быть изменен в течении минут (если фактор взлома таки установлен) кроме того переодическое его изменение отвязано от релизов.

Довольно жалкое утешение после того, как нежданно случился EXPORT ALL или там DROP DATABASE.

S>>Тем не менее, если взять это за принцип, оказывается, что чаще всего возможно
A>В теории — да. На практике (корпорация 100+ приложения, зоопарк технологий Rubby/Java/ASP/ASP.Net) не совсем так.

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

S>>Если нужен какой-нибудь автоматизированный процесс — его логику можно положить внутрь БД или другой надёжной системы, а на долю приложения оставить только дёрганье нестрашных сервисов (скажем, запуск обработки этих данных).
A>Автоматизированый процес тоже приложение(предполагаем что внешнее)

Процесс — это процесс. "Посчитать дебиторку", "разослать заявки", "определить победителя аукциона" итдитп. Как этот процесс будет реализован — вопрос к архитектору. Если архитектор собирается вынести работу с существенными данными в легко компрометируемую среду — однозначно рекомендуется ампутация.

S>>На практике основной источник "существенные данные нужны для работы приложения" — идиотизм под названием "мы будем лазить в базу под общим логином, а безопасность сами сбацаем как-нибудь на клиенте".
A>До тех пор пока вы можете заставить пользователя аутинфицироваться ДО использования приложения.

Я не понял смысла этой фразы, она выглядит недописанной. Тем не менее отмечу, что "использование приложения" тут не при чём. Пользователь должен аутентифицироваться до выполнения важной операции — это да. И это... естественное и разумное ограничение, альтернатива — важная операция доступна кому угодно со всеми вытекающими.

Это не всегда возможно вне финансов/банкинга.

S>>Для десктопного клиент-сервера это безусловно недопустимый метод, но и его как правило можно решить малой кровью, например, в Oracle это можно сделать через application roles. В этом случае злоумышленник, узнав "общий пароль к БД" и законнектившись, обнаружит, что у него вообще нет прав, а права появятся только после того, как он введёт личный пароль (и из базы он таким образом получит только то, что и так мог быть получить в интерфейсе приложения).
A>Для веб-приложений такой подход работать будет очень плохо. Держать ВСЮ базу пользователей и их права доступа на уровне базы, а также их поддерживать очень нетривиальная и дорогая задача.

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

Здравствуйте, Softwarer, Вы писали:

S>Ничего. Можно нагромоздить кучу мусора, но тем не менее пользователь с отладчиком всегда будет иметь возможность залогиниться от имени приложения. Поэтому правильных решений два:
S>1. Не делать таких входов вообще
S>2. Там, где они действительно абсолютно необходимы, выдавать им минимальный набор прав в БД, так, чтобы раскрытие пароля не давало ничего существенного.

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

Пример:
Допустим есть локальная сеть компании, сервер с БД, и на компьютерах пользователей — двузвенное приложение.
Менеджер Вася запускает программу (ему нужно отредактировать заказы).
Что дальше? Как происходит процесс аутентификации (откуда берется логин и пароль, что это за логин и пароль) и дальнейшие действия (на уровне кода приложения и БД) для выполнения действия "отредактировать заказ"?

S>Посмотрите на стартовое сообщение топика. Я не вижу там слова "веб", зато вижу "десктоп" и явный клиент-сервер. Давайте придерживаться темы. По поводу веба, если хотите, давайте поговорим отдельно, когда разберёмся с десктопом.
Моя ошибка к десктопу в корпоративных приложениях такой же подход был как и к вебу: юзеру/его машине веры нет.

S>Это не повод рекламировать уровень "ключ под половичком". Преимущества внешних карманов-кошельков-шифров над вшитым паролем малозначимы (для уникальных приложений — стоимость их разработки по сравнению со стоимостью взлома явно не окупается).
Смотря где. Но для "мелкого десктопа" точно оверкил

S>Процесс — это процесс. "Посчитать дебиторку", "разослать заявки", "определить победителя аукциона" итдитп. Как этот процесс будет реализован — вопрос к архитектору. Если архитектор собирается вынести работу с существенными данными в легко компрометируемую среду — однозначно рекомендуется ампутация.
Всякая среда должна интерпертироваться как компроментруемая.
По сложности где-то так (опять же из личного опыта):
Машина юзера
ВебСервер (если есть)
Серавер приложения
Сервер базы данных
Сервер ключей (типа RSA или SafeNet)

S>Я не понял смысла этой фразы, она выглядит недописанной. Тем не менее отмечу, что "использование приложения" тут не при чём. Пользователь должен аутентифицироваться до выполнения важной операции — это да. И это... естественное и разумное ограничение, альтернатива — важная операция доступна кому угодно со всеми вытекающими.
Тут с вебом больше связано. Все верно. Но иногда серверу нужны данные (например блеклист адресов) которые к логину отношения не имеют, но их утечка была бы нежелательной.


S>Для веб-приложений такой подход отлично работает.
Вы имеете в виду деражать 40-50 милионов пользователей и права доступа средствами базы? Я бы не хотел пулю в лоб от ДБА за такое

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

Здравствуйте, Аноним, Вы писали:

А>Не могли бы вы, пожалуйста, для лучшего понимания, на примере рассмотреть хороший по вашему мнению вариант аутентификации
А>скажем, обеспечивающий высокий уровень защиты от доступа злоумышленника к важным данным в БД)?

"Охранник с автоматом на входе в закрытый контур, физически разделённый двойной ввод, контроль на входе и стопроцентное уничтожение внесённых носителей информации на выходе".

Это всё же комплексное решение, и тут нельзя фокусироваться на одном-единственном аспекте. Ну например, данные кредитных историй у нас операторы подписывали личными ключами — но рекомендовать это как решение для ста процентов пользователей типовой КИС я бы не стал. Мы сейчас рассматриваем единственную угрозу: менеджер Вася (зная свой пароль и некоторое количество внутренней технической информации) оказался квалифицированным в ИТ злоумышленником и полностью скомпрометировал свою систему. Наша задача: он не должен без взлома других систем получить доступ к информации/операциям, на которые ему не дано прав в рамках КИС. А для этого необходимо по сути одно: с его компьютера не должно осуществляться входов в систему под другими (кроме Васиного) мало-мальски привилегированными многоразовыми аккаунтами. Если система и делает какие-то другие, служебные входы, то они должны быть, грубо говоря, с правами guest-а.

А>Что дальше? Как происходит процесс аутентификации (откуда берется логин и пароль, что это за логин и пароль) и дальнейшие действия (на уровне кода приложения и БД) для выполнения действия "отредактировать заказ"?

Для действий уровня "отредактировать заказ" имхо вполне достаточно доменной аутентификации.

Здравствуйте, Alyash77, Вы писали:

A> юзеру/его машине веры нет.

Воистину. Именно поэтому никаких "привилегированных паролей" туда попадать не должно.

S>> Если архитектор собирается вынести работу с существенными данными в легко компрометируемую среду — однозначно рекомендуется ампутация.
A>Всякая среда должна интерпертироваться как компроментруемая.

Безусловно. Поэтому "легко компрометируемую".

A>Тут с вебом больше связано. Все верно. Но иногда серверу нужны данные (например блеклист адресов) которые к логину отношения не имеют, но их утечка была бы нежелательной.

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

S>>Для веб-приложений такой подход отлично работает.
A>Вы имеете в виду деражать 40-50 милионов пользователей и права доступа средствами базы?

Нет. Я имею в виду именно то, что имею в виду — динамическая выдача прав соединению через application roles в зависимости от аутентифицированного пользователя.

S>>обычно не рассматривается варианта злоумышленника с отладчиком на веб-сервере.
A>Вот тут Вы оптимист.

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