Предотвращение модификации данных из внешнего источника в SQLite

Недавно я создал диспетчер паролей, используя Java для моего проекта колледжа в ООП. Для обработки базы данных я выбрал SQLite, так как использование MySQL или SQL-сервера становилось беспокойным для небольшого проекта. Хотя я уже сделал это с представлением, я думал, могу ли я сделать дальнейшее улучшение в проекте.

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

Теперь здесь возникает две проблемы -

  • Будет отображен список паролей пользователей.
  • Любой пользователь сможет изменить данные с помощью диспетчера SQLite.

Чтобы решить первую проблему, я уже использовал шифрование AES, и он работает нормально. Однако вторая проблема остается.

Итак, в оболочке ореха, Как я могу предотвратить изменение моей базы данных SQLite, за исключением самого Менеджера паролей?

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

Примечание.. Мне было интересно, можем ли мы использовать ограничение SQLite, что за один раз можно установить только одно соединение для записи данных. Используя это, злоумышленник не сможет его изменить. Но я не уверен, как это можно реализовать.

Ответы

Ответ 1

Ограничить доступ пользователей

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

Шифрование

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

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

Также рассмотрите вопрос SQLite с защитой от шифрования/пароля.

Атака

Что произойдет, если у кого-то есть доступ к файлу базы данных?

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

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

Резервные

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

Заключение

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