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

Question

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

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

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

1. пользователя будет виден
2. Любой сможет изменить данные с помощью SQLite менеджера.

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

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

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

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

Answer 1

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

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

Шифрование

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

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

Также взгляните на вопрос SQLite with encryption/password protection.

Атака

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

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

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

Резервные

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

Заключение

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