Защита доступа к базе данных приложения на ПК пользователя

Привет!

Мне нужно развернуть компактную базу данных с приложением, над которым я работаю. База данных действует как кеш для данных, которые приложение уже просматривало, и эти данные никогда не изменятся, поэтому кешированные значения никогда не устареют. Я выбрал SQLite и пишу на C #.

Я хотел бы защитить файлы базы данных, чтобы они не могли быть легко доступны или отредактированы пользователем, сохраняя доступ только к моему приложению. Теперь один из вариантов - использовать защиту паролем, что нормально, за исключением того, что с такими инструментами, как Reflector, можно легко просмотреть почти исходную версию источника и проверить пароли / то, как они генерируются для каждого файла, и воспроизвести это.

Есть какие-то предложения, как добиться такого результата или чего-то близкого? Делали ли люди что-то подобное в прошлом?

Спасибо!


sqlite c# password-protection
person filip-fku    schedule 29.06.2010    source источник

Ответы (3)


arrow_upward
4
arrow_downward

Безопасность неизвестностью.

Если ваши приложения могут его расшифровать, то ваш пользователь тоже сможет это сделать.

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

person mmx    schedule 29.06.2010
comment
+1 - Точно, если ничего другого, они могут подключить его к отладчику и заглянуть в (незашифрованную) память процесса. - person Eric Petroelje; 30.06.2010
comment
Вот чего я боялся. Хотя я мог подумать, что что-то подобное будет достаточно распространенным, чтобы существовало стандартное решение .. Не имеет смысла иметь базу данных на сервере, поскольку она действует как кеш для определенных запросов от пользователя, и есть ли там чисто как повышение производительности. - person filip-fku; 30.06.2010
comment
@ filip-fku: Если бы было реальное решение, ребята из DRM уже использовали бы его. По сути, это классическая проблема с дырой. - person mmx; 30.06.2010
comment
@Mehrad - дырочная проблема, мне нравится! Спасибо за предоставленную информацию. - person filip-fku; 30.06.2010

arrow_upward
1
arrow_downward

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

Все, что вы можете сделать, - это усложнить им задачу.

person Caladain    schedule 29.06.2010

arrow_upward
0
arrow_downward

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

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

Допустим, у вас есть эта таблица, хранящаяся в базе данных вашего сервера (а не в базе данных клиента!)

RealAccountNumber   ClientOnlyAccountNumber
981723              ABC123
129847              BCD234
923857              CDE345
...

Таким образом, клиент видит только номера учетных записей в столбце ClientOnlyAccountNumber, и когда клиент отправляет запрос на сервер для выполнения действия над учетной записью «ABC123», сервер знает, как преобразовать это в учетную запись номер 981723.

person Dr. Wily's Apprentice    schedule 29.06.2010
comment
Хорошая идея для другого вопроса! :) Все, что меня беспокоит, это блокировка доступа пользователей к локальным файловым базам данных. - person filip-fku; 30.06.2010