Отправлено: 06.08.10 12:20. Заголовок: Как запретить работу с чужими базами ?

Всем привет !

Кто может подсказать по следующему вопросу:

Имеется своя программа, базы данных: dbf-файлы, индексы: cdx.
Этой программой пользуются определенное кол-во фирм. Программа привязана на ключ (HASP HL).

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

 Отправлено: 06.08.10 12:30. Заголовок: Где то была такая те..

Где то была такая тема :)

 Отправлено: 06.08.10 12:37. Заголовок: Dima пишет: Где то ..

Dima пишет:

цитата:

Где то была такая тема :)

Прошло время, может кто-то по новому сможет предложить решение данной проблемы.

 Отправлено: 06.08.10 12:41. Заголовок: Да вроде просто ФСЁ ..

Да вроде просто ФСЁ ;)
Только нужно продумать как все это верно замутить.
На компе в файле (или в реестре) , храним предположим MD5 (тут могут варианты) всех реквизитов организации
(или части реквизитов).
Пришел чел с левой базой и пытается зайти в прогу и тут........понял ? :)


Еще вариант ;)
Привязка проги к MAC адресу сетевой карты.

 Отправлено: 06.08.10 13:12. Заголовок: Не совсем просто. У..

Не совсем просто.
У меня есть номер ключа HASP HL. Я по нему могу определять, чья задача и не надо мне MAC адресу сетевой карты или MD5 всех реквизитов организации ....

Как сделать привязку DBF-ника баз на конкретную организацию ?
Dima пишет:

цитата:

Пришел чел с левой базой и пытается зайти в прогу и тут....

Этот чел переписал 3-4 больших баз и справочники и все .... вуаля.... РАБОТАЕТ с чужой базой...

 Отправлено: 06.08.10 14:18. Заголовок: Первое, что приходит..

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

 Отправлено: 06.08.10 14:29. Заголовок: КСС пишет: Первое, ..

КСС пишет:

цитата:

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

Кстати да , вариант !

 Отправлено: 06.08.10 14:59. Заголовок: КСС пишет: это шифр..

КСС пишет:

цитата:

это шифрование баз (хотя бы основных) по тому же номеру ключа,

Это интересно. Для локального варианта это ХОРОШИЙ выход.
Как реализовать ? Примерчик небольшой можно ? (Заранее спасибо !)


Но вот для сетевой версии программы, когда ключей несколько, то это наверно облом !
Хотя можно придумать БАЗУ шифра, в которой будут храниться номера ключей, а КОД-шифрования будет общим.
А как тогда обеспечить подключение "правильных" своих пользователей и не давать подключаться "левым" пользователям ?

И еще тогда меня интересует как будет вести себя ОБЩАЯ база (шифрованная) в многопользовательском режиме ?
У кого есть опыт ?

 Отправлено: 06.08.10 15:22. Заголовок: Andrey пишет: И еще..

Andrey пишет:

цитата:

И еще тогда меня интересует как будет вести себя ОБЩАЯ база (шифрованная) в многопользовательском режиме ?

У меня есть печальный опыт на Clipper + SIX. Упала как то шифрованная база , не было на компе бесперебойника.
Половина базы осталась вообще не понятно в каком виде , расшифровать так и не удалось.
С тех пор не шифрую шибко большие базы , только "особо секретные" ;)
Возможно X(Harbour) ведет себя корректнее в таких случаях , не проверял.

 Отправлено: 06.08.10 17:40. Заголовок: Возможно, устроит та..

Возможно, устроит такое решение. На мой взгляд, достаточно дёшево, сердито и с минимальными доработками :)

1. Каждая DBF – таблица ( ну или не каждая, а по выбранная возможному интересу для недоброжелателей или другому критерию ) дополняется полем для записи некоторого кода ( назовём его это поле CRYPTFIELD )
2. Значение для записи в CRYPTFIELD вычисляется на основе содержимого всех ( ну или опять-же не всех, а на усмотрение разработчика ) полей записи и некоторого ключа шифрования, который уникален для конкретного пользователя ( можно вписывать в экземпляр программы или получать из HASP )
3. При обновлении полей отдельной записи соответственно обновляется и содержание CRYPTFIELD.
4. При запуске программы проверяется совпадение содержимого CRYPTFIELD и используемых для его генерации полей записях так в сотне, отобранных случайным порядком по всей DBF-таблице.
5. Если случаев несовпадений слишком много ( процентов так 10, например ) - значит, DBF-таблицы скорее всего записывались с отличным от используемого ключа шифрования, то есть имеет место попытка доступа к чужим данным, запретом чего мы и озадачены.

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

 Отправлено: 06.08.10 18:26. Заголовок: G-Serge пишет: Возм..

G-Serge пишет:

цитата:

Возможно, устроит такое решение.

Устроит. Еще как устроит !!!
Что-то подобное думалось мне, но решил спросить профессионалов.

G-Serge пишет:

цитата:

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

Можете разъяснить поподробней ?

 Отправлено: 06.08.10 18:34. Заголовок: Например, просуммиру..

Можно и поподробней :) Всё-таки центральный момент :)

Например, просуммировать все числовые поля, умножить на сумму всех asc() символов строковых полей, а итог разделить на номер кода ключа. Целую часть полученного результата ( или несколько последних цифр , зависит от длины CRYPTFIELD ) записать в CRYPTFIELD.
Главное - соответствие содержимого CRYPTFIELD всей этой арифметике в КАЖДОЙ записи базы данных :)

 Отправлено: 06.08.10 19:22. Заголовок: И вдогонку :) Отдель..

И вдогонку :)
Отдельное поле для проверочного значения можно и не вводить.
Вместо этого можно заполнить ПЕРВЫЕ несколько записей базы данных значениями, которые опять-же будут соответствовать некоторому ключу. Хотя подбирать значения для полей исходя из ключа - задача ещё более творческая :)

 Отправлено: 06.08.10 20:17. Заголовок: G-Serge пишет: прос..

G-Serge пишет:

цитата:

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

Это круто ! При изменение структуры базы, придется еще и пересчитывать все записи !
А нет ли какой готовой функции в Харборе подсчета (типа MD5) полей БД ?

G-Serge пишет:

цитата:

Вместо этого можно заполнить ПЕРВЫЕ несколько записей базы данных значениями, которые опять-же будут соответствовать некоторому ключу.

Тогда их нужно делать удаленными, чтоб в подсчетах не участвовали и не выводились вообще !
А этот метод можно будет легко подделать....

 Отправлено: 06.08.10 20:46. Заголовок: Andrey пишет: Это к..

Andrey пишет:

цитата:

Это круто ! При изменение структуры базы, придется еще и пересчитывать все записи !

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

Andrey пишет:

цитата:

Тогда их нужно делать удаленными, чтоб в подсчетах не участвовали и не выводились вообще ! А этот метод можно будет легко подделать....

Здесь тоже возможны варианты :) Всё зависит от того, КАК конкретная база данных используется.

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

Продемонстрировать клиенту, что ЕГО, КЛИЕНТА данные не читаются на машине с ЧУЖИМ ключом - это одно, всерьёз предполагать, что ОДИН ИЗ ВАШИХ КЛИЕНТОВ позаимствует файлы данных у ДРУГОГО ВАШЕГО КЛИЕНТА - это другое.

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

 Отправлено: 07.08.10 05:55. Заголовок: Если рассматривать с..

Если рассматривать самый простой вариант, то я бы сделал примерно следующее:
1) единственное, что отличает базы данных клиентов - это аппаратные ключи (компьютеры и их внутренности исключаем);
2) у меня в базе данных всегда есть таблица через которую пользователи авторизуются, хранят и получают настройки программы и прочее. В этой таблице у меня лично, только одно поле с неопределённым названием типа Fld1 и она зашифрована;
3) при первичной установке программы запускаем нашу программу с определённым параметром. Этот параметр запускает функцию, которая записывает номер HASP ключа в одно из полей (или как у меня - в определённое место поля) каждого пользователя;
4) теперь во время авторизации сверяем текущий ключ с разрешённым пользователю. Такой вариант позволит даже разделить доступ пользователям к разным БД по разным ключам, если таковых установлено несколько.

 Отправлено: 07.08.10 13:36. Заголовок: КСС Спасибо БОЛЬШО..

КСС

Спасибо БОЛЬШОЕ за идею !
Я такой вариант вообще не рассматривал....
Даже изящное решение....

А с какими ключами HASP работаешь ?

 Отправлено: 08.08.10 13:03. Заголовок: А может эту инфу в з..

А может эту инфу в заголовок DBF класть. Там, помнится, 31/32 байты резервированы

 Отправлено: 08.08.10 19:57. Заголовок: fil пишет: А может ..

fil пишет:

цитата:

А может эту инфу в заголовок DBF класть. Там, помнится, 31/32 байты резервированы

Т.е. туда можно записать свои 2 байта ?
А как бы точно узнать ?

 Отправлено: 08.08.10 20:43. Заголовок: Не понял, чего узнат..

Не понял, чего узнать ? Гуглим формат DBF. При инсталяции проги fwrite в DBF-ы признака пользователя(группы пользователей)

 Отправлено: 17.08.10 12:10. Заголовок: fil пишет: А может ..

fil пишет:

цитата:

А может эту инфу в заголовок DBF класть. Там, помнится, 31/32 байты резервированы

Не прокатит !
А если придет кому нибудь в голову, добавить в рабочую базу через утилиты (DBU или другие) записи другой "стыренной" базы ?
Слишком легкая защита !