Я в шоке
Пишу прогу использую базу FireBird, для доступа на форме лежит TpFIBDatabase.
В параметрах подключения к базе естественно прописываю логин и пароль SYSDBA|masterkey
Сижу ломаю голову как защитить базу, ответ известен - сменить пароль.
и в этот момент возникает мысль посмотреть файл скомпилированной проги по обычному F3
Увиденное вводит меня в столбнячное состояние
жму F3 -> F7 -> в поле ввода ввожу "password=" и жму искать, получаю
фрагмент:

_ctype=WIN1251password=masterkeyuser_name=SYSDBAsql_role_name= DefaultTransactionTransactionRead
SQLDialectTimeout LeftуTop  TpFIB

Ну и как мне ЭТО спрятать ?
Ведь поменяю я пароль на базу, а он тоже будет виден невооруженным глазом !!!

Прикол №2
Есть у меня прога и мне нужно было посмотреть структуру базы (Access) для изучения но никак я не мог до неё добраться.
Нашел чудную прогу "Passware Password Recovery Kit" и с её помощью добрался до пароля.
Сегодня жму F3 на файле это проги, ввожу строку поиска "password=", жму искать и получаю:

WidthZ TADOConnectionADOConnection1ConnectionStringN
 Provider=MSDASQL.1;Password=Herj<kelbt;Persist Security Info=True;User ID=Admin;Data Source=База данных MS Access;Extended Properties="DSN=База данных MS Access;DBQ


Это что получается ?
Все пароли к базам просто так доступны и нафик не нужны навороченные креки ?  

Разъясните, пож-та !

Цитата

Прикол №2: Password=Herj<kelbt

Но это ведь вроде шифрованный пароль? или нет?

Цитата

Все пароли к базам просто так доступны и нафик не нужны навороченные креки ?

Ну это не совсем так. Дело в том, что как я понял ты смотрел бинарники самих программ, которые подключаються с каким-то(не известным тебе) паролем к базе данных. А ты не пробовал получить этот пароль из самой базы данных? (как получиться не забодь меня оповестить)
То, что пароль к базе данных в чистом виде лежит в бинарнике это уже серьёзные проблемы с безопастностью у разработчиков самой программы, а не у тех, кто проектировал и писал соответвующие драйвера и программы для работы с конкретной бд, хотя если это один и тот же человек, то думаю пора призадуматься стоит ли использовать такое ПО и такую бд у себя на работе.

Цитата(Admin @ 06.1.2003, 21:18)

Цитата Прикол №2: Password=Herj<kelbt Но это ведь вроде шифрованный пароль? или нет?

Нет это не шифрованный пароль, просто набор символов такой.
Точно такой же пароль я получал и программой Passware  

Admin

Цитата

Дело в том, что как я понял ты смотрел бинарники самих программ, которые подключаються с каким-то(не известным тебе) паролем к базе данных. А ты не пробовал получить этот пароль из самой базы данных? (как получиться не забодь меня оповестить)

Ну понятное дело, что из самой базы я не смогу получить пароль, но ведь в бинарнике то он доступен !!!
И доступен не только в проге, использующую FireBird, а и с базой Access те же грабли
Вот что меня удивляет ...

Цитата

То, что пароль к базе данных в чистом виде лежит в бинарнике это уже серьёзные проблемы с безопастностью

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

1) Обычно такие данные хранят не в бинарнике а во внешнем файле естественно в зашифрованном виде

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

- все данные в БД достаются через Stored Procedures
- пользователь имеет право только запускать Stored Procedures, но не может читать таблицы или смотреть/редактирвать Stored Procedures
- Для каждого пользователя создаётся свой массив Stored Procedures, которые обеспечивают доступ только к его данным.

Тогда даже если пользователь и узнает пароль, он не сможет вытащить ничего что ему не положено.

Vit
Большое человеческое СПАСИБО !

А какие еще есть варианты или указанный наиболее приемлемый ?
Слабо я знаю еще как создавать эти Stored Procedures и как ими пользоваться
Ссылочкой не кинешь где бы я мог восполнить этот пробел ?

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

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

Vit
Спасибо, буду просвещаться

Еще такой вопрос:
Создам я пользователя, дам ему ограниченные права и т.д.
Как мне потом все эти привилегии создать при инсталяции программы.

Я вижу путь такой.
Есть сама прога, файл с базой (*.gdb) и инсталяшка самого сервера (FireBird)
Беру прогу для создания инсталяционного пакета, запихиваю туда эти файлы, определяю порядок установки, запуска и т.д. - это всё понятно.
А вот как мне прописать в инсталяхе создание юзера с определенными правами, да и поменять дефолтовые настройки (SYSDBA-masterkey) ?

И каким лучше пакетом для создания инсталяшек пользоваться ?
Их развелось сейчас очень много (InstallShield, InnoSetup, CreateInstall, etc.)

Цитата(3D @ 06.1.2003, 18:35)

А вот как мне прописать в инсталяхе создание юзера с определенными правами, да и поменять дефолтовые настройки (SYSDBA-masterkey) ?

Обычно во всех базах данных есть готовые Stored Procedure или специальные запросы которые могут создавать пользователей, менять пароли, и т.п. - читай документацию по свое базе данных.

2Vit
А что мешает мне, как взломшику не имея пароль к базе данных просто использовать эти же Stored Procedure для достижения своих целей.
Или это просто вариант ограничить возможности взломщика правами доступными самой подопытной программе?

XpyDi
О, свежая струя
Приветствую,
и можно подробнее о "вероломных планах" ?

Цитата

Или это просто вариант ограничить возможности взломщика правами доступными самой подопытной программе?

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

Цитата(XpyDi @ 07.1.2003, 10:28)

2Vit А что мешает мне, как взломшику не имея пароль к базе данных просто использовать эти же Stored Procedure для достижения своих целей.

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

Цитата

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

Я что-то не совсем понял - что мешает "Пете" вызвать хранимку для "Васи" ?

Цитата(SmaLL @ 14.1.2003, 02:44)

Я что-то не совсем понял - что мешает "Пете" вызвать хранимку для "Васи" ?

Незнание Васиного пароля.

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

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

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

Chingachguk
Объясни, пож-та, как с хешами обращаться в Delphi
с php + mysql я знаком и знаю как там это реализовывается, а с дельфями пока не знаю, учусь

Цитата(3D @ 14.1.2003, 12:03)

Chingachguk Объясни, пож-та, как с хешами обращаться в Delphi с php + mysql я знаком и знаю как там это реализовывается, а с дельфями пока не знаю, учусь

Модератор: Это вопрос для новой темы.

Цитата

Vit Дата сообщения: 14.1.2003,17:26 -------------------------------------------------------------------------------- По хэшу пароль не восстановишь... Если бы надо было сравнивать введенный пароль с нужным, тогда конечно надо хранить хэш, а изначально вопрос был примерно в том, что программа пароль "знает" и по нему с базой общается, а пользователь чтобы этот пароль узнать не мог...

Я не очень понимаю, в чем конкретно задача.
Допустим, есть клиент (бинарник ? Аксесс ?), который должен предьявить серверу пароль. Но клиент при этом должен также не позволять ЛЮБОМУ пользователю, запустившему клиента, иметь возможность возможность через клиента предъявить пароль...
Тогда такое решение: пусть пароль для сервера есть pass, формируем при помощи хэш-функции(md5,sha1..) хэш от него: h=hash(pass). В самой программе остается код:
 const
 h=...;
 var
 pass:string;
 ...
 pass=GetWindowText(...) {или типа того - запрос от user'а}
 
 if hash(pass)=h then
  {Пароль на сервер предъявлен пользователем верный, используем его}

Если же нельзя давать пользователю пароль на сервер, но необходимо требовать авторизации от него, то можно делать так:

 const
 h=...; {Хэш от пароля ПОЛЬЗОВАТЕЛЯ}
 CryptedServerPassword = ...; {Зашифрованный на пароле pass пароль на сервер}
 var
 pass:string;
 pass_for_server:string;
 ...
 pass=GetWindowText(...) {или типа того - запрос от user'а}
 
 if hash(pass)=h then
  {Пароль на сервер предъявлен пользователем верный, используем его}
  {но уже для расшифровки пароля на сервер}
      begin
         pass_for_server=decrypt(pass,CryptedServerPassword);
         {И предъявляем серверу расшифрованный пароль pass_for_server}

В качестве ф-ции decrypt можно взять любую ф-цию шифрования: RС4, cast,DES...

Примечание: упомянутые алгоритмы являются коммерческими и могут быть недоступны для ...

Chingachguk
Проблема не в том КАК дать авторизацию, а в том, что пароль лежит в открытом виде в exe-шнике.
Почитай самый первый мой пост ...

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

Цитата

3D-Dragon Дата сообщения: 15.1.2003,141 Chingachguk Проблема не в том КАК дать авторизацию, а в том, что пароль лежит в открытом виде в exe-шнике. Почитай самый первый мой пост ...

эээ.... а где у меня в открытом виде пароль ? ;)

Chingachguk
Мне не нужно делать АВТОРИЗАЦИЮ в явном виде (ввод пароля юзером) ...

2 Chingachguk - пользователь запускает программу и НЕ ВВОДИТ ни какого пароля. Пароль лежит в программе! Суть в том что автор хочет чтобы пароль, который пользователь НЕ ВВОДИТ, которого он НЕ ЗНАЕТ, был зашифрован, чтобы пользователь и НЕ МОГ УЗНАТЬ СВОЙ ПАРОЛЬ.

Предварительно пароль шифруется и искомая комбинация запоминается. Также в коде существует ключ, с помощью которого пароль был зашифрован. Можно взять любой симметричный алгоритм шифрования (где ключ зашифровки = ключу расшифровки).
Теперь в коде есть ключ где-то. И зашифрованный с его помощью пароль. И то, что ключ виден в коде ничего не говорит, без дизассемблирования его не различить - как ты узнаешь ключ длиной в 8-16 байт в exe ? Понять его назначение будет крайне сложно. Взяли зашифрованный пароль, взяли ключ, расшифровали, подставили.
Все довольны

Цитата(AntonSaburov @ 15.1.2003, 07:46)

Все довольны

В общем-то выход, да только всё равно на некотором этапе выполнения пароль появляется в памяти в явном виде и в явном виде в базу посылается, думаю что тому же Chingachguk'у потребуется минут пять чтобы этот пароль отловить вне зависимости  от сложности алгоритма шифрования, поэтому вариант с Stored Procedure считается гораздо более предпочтительным с точки зрения защиты данных.

Цитата

В общем-то выход, да только всё равно на некотором этапе выполнения пароль появляется в памяти в явном виде и в явном виде в базу посылается, думаю что тому же Chingachguk'у потребуется минут пять чтобы этот пароль отловить вне зависимости  от сложности алгоритма шифрования, поэтому вариант с Stored Procedure считается гораздо более предпочтительным с точки зрения защиты данных.

Против дампа памяти - не попрешь
Но автоматическое подключение (для меня) должно происходить только из тех программ, которые недоступны пользователям. На выделеном сервере, под паролем, чтобы кода не получали.
А если пользователь сам такую программу запускает - так пусть и пароль вводит. Дальше проблемы службы безопасности - сроки паролей, их сложность и прочая.
А по поводу StoredProcedure - это в любом случае хорошо. У меня в одном из последних проектов все шло через SP - к таблицам вообще никакого доступа. И доступ проверялся прямо в самих SP. Т.е. пользователь мог запускать любую процедуру, но в ней предварительно проверялось - кто он такой. И было крайне удобно.

Цитата(AntonSaburov @ 15.1.2003, 08:06)

А по поводу StoredProcedure - это в любом случае хорошо. У меня в одном из последних проектов все шло через SP - к таблицам вообще никакого доступа. И доступ проверялся прямо в самих SP. Т.е. пользователь мог запускать любую процедуру, но в ней предварительно проверялось - кто он такой. И было крайне удобно.

Во-во-во! Именно так