Цитата(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. Т.е. пользователь мог запускать любую процедуру, но в ней предварительно проверялось - кто он такой. И было крайне удобно.

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