Избежать подмены БД...

[kibernetics]

Подходит к концу реализация моего проекта с использование БД. И тут я подумал, что прогу-то могут использовать в корыстных целях даже не ломая её
Просто, подкладывая собственную БД вместо исходной. Поэтому возникает вопрос: Что делать-то?

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

Или может я слишком стар и система защиты постоянно обновляемых БД уже давно существует? Кто копал в данном направлении - поделитесь плиз.

[alibek]

Неправильная архитектура.

[kibernetics]

Неправильная архитектура.

Извини, не совсем понял. Делать неправильную архитектуру БД или у меня спланирована Неправильная архитектура действий?

[alibek]

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

[kibernetics]

Исключено.
Юзеров - все желающие. Чтобы работать с БД им придется запрашивать лицензию, это несовсем удобно.

[tyomitch]

Ну сделай один ключ на всех, и шифруй им свою базу.
Тогда кто-нибудь угадает ключ и зашифрует им левую базу для работы с твоей прогой.
Устраивает?

[iGrok]

Вопрос, насколько вероятна возможность вообще подмены базы? Это кому-то выгодно???

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

Пользователи только читают базу? Где она размещается? На сервере/локально на машинке клиента/еще где-то..
Как часто обновляется..

В общем-то способ защиты придумать можно, если очень захотеть..
Но в целом, против опытного "взломщика" не устоит ни один.

[kibernetics]

Пользователи могут только читать базу. Локально. Вообще-то, база сконвертирована в MDE-файл, но хотя и в этом случае записи можно добавлять..., тем неменее записи добавлять/редактировать НЕЛЬЗЯ.

Базу шифровать? А смысл? Потом опять расшифровывать из программы? Аааа, чтоб не догадались о структуре БД? Понятно... Хм, вообщем-то неплохой вариант, а вообще уже есть что-нить похожее на крипт/декрипт mdb? Да и данные там не совсем чтобы важные, а больше, как бы это выразится, эталонные чтоли.

[SAS]

В одной из своих программ я просто шифровал базу паролем, который знала моя программа, и переименовал расширение с .mdb на .kit. Просто в строке подключения к базе пароль указываешь и все. Лучше использовать достаточно длинный.

[alibek]

Пароль на базу данных -- очень слабая защита. Снимается он на раз.
Более надежно преобразовать базу в MDE, создать для нее MDW (файл рабочих групп), в котором пользователю admin назначить сложный пароль и забыть его, создать нового пользователя и дать ему права на объекты. Это тоже вскрывается, но значительно сложнее.

[Andrey Fedorov]

Более надежно преобразовать базу в MDE, создать для нее MDW (файл рабочих групп), в котором пользователю admin назначить сложный пароль и забыть его, создать нового пользователя и дать ему права на объекты. Это тоже вскрывается, но значительно сложнее.

Тем не менее и это вскрывается на два.
Не поможет и упомянутое выше переименование файла - по заголовку он дюже легко определяется...

Если только целиком свой формат изобретать с шифрованием...

[iGrok]

Вариант для извращенцев:
При старте проги считаем хеш файла БД.. md5, например.
И сравниваем с заданным в проге значением.

Минус - при обновлении базы придется обновлять экзешник. =))

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

[Sebas]

Каждую запись нужно хешировать своим супер пупер ключом и для каждой таблицы добавлять хэш-колонку. И какждый раз сравнивать.

[dormouse]

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

хулиган не знает заранее имя распакованной базы и пароль к архиву. так сойдёт?

[Andrey Fedorov]

заархивировать базу раром с шифрованием (расшифровка рара-то не на раз-два происходит? )

Особенно когда размер базы сотни мегабайт

хулиган не знает заранее имя распакованной базы и пароль к архиву. так сойдёт?

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

[dormouse]

но сама программа уже не будет пользоваться этой базой. а заменить базу во время работы программы нельзя будет, если файл базы будет "открыт" с блокировкой

kibernetics'у нужно же, чтоб для exe-шника нельзя было подменить базу?

в моём варианте база и эксешник друг без друга ничего не будут значить

[Andrey Fedorov]

но сама программа уже не будет пользоваться этой базой. а заменить базу во время работы программы нельзя будет, если файл базы будет "открыт" с блокировкой

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