Пароли приложения и безопасность SQLite
Я искал на Google информацию относительно паролей приложения и безопасности SQLite в течение некоторого времени и ничего, что я нашел, действительно ответил на мои вопросы.
Вот то, что я пытаюсь выяснить:
1) Мое приложение будет иметь дополнительное действие пароля, которое назовут, когда приложение будет сначала открыто. Мои вопросы для этого a) Если я храню пароль через предпочтение андроида или базу данных SQLite, как может я гарантировать безопасность и конфиденциальность для пароля и b) как восстановление пароля должно быть обработано?
Относительно b) сверху, я думал о требовании адреса электронной почты, когда опция пароля активирована, и также вопрос о подсказке пароля для использования при запросе восстановления пароля. После успешного ответа на вопрос подсказки пароль затем посылается по электронной почте на адрес электронной почты, который был отправлен. Я не абсолютно уверен в безопасности и конфиденциальности почтового метода, особенно если электронное письмо послано, когда пользователь подключен к открытой, общедоступной беспроводной сети.
2) Мое приложение будет использовать базу данных SQLite, которая будет сохранена на SD-карте, если у пользователя будет тот. Независимо от того, хранится ли это по телефону или SD-карта, какие опции я имею для шифрования данных, и как это влияет на производительность приложения?
Заранее спасибо в течение времени, потраченного для ответа на эти вопросы. Я думаю, что могут быть другие разработчики, борющиеся с теми же проблемами.
1 ответ
1) Восстановление пароля опасно. Надежность пароля подрывается ответом на вопрос, это главное самое слабое звено. Взлом электронной почты Сары Пэйлин стал возможным из-за этой (очень) небезопасной функции. Также, если вы храните пароль в «восстанавливаемом формате», например, в блочном шифре, таком как AES, или потоковом шифре, таком как RC4, или асимметричном шифре, таком как RSA, то вы явно нарушаете CWE-257 . Если вам действительно нужна эта функция, вы должны потребовать, чтобы пользователь сбросил свой пароль, если они его не знают, то зачем вам сообщать им?
Пароли всегда должны хешироваться с использованием безопасных Дайджест сообщения. В настоящее время многие функции дайджеста сообщений небезопасны, md4, md5, sha0 и sha1 очень неработоспособны и никогда не должны использоваться для паролей. В настоящее время лучше всего использовать любую функцию из семейства sha2, я рекомендую SHA-256. NIST в настоящее время проводит конкурс для sha3, и он не будет завершен до 2012 года.
Пароли также должны быть «подсолены» с большим случайным значением. Это может быть еще один столбец в вашей базе данных, который затем добавляется к паролю в виде обычного текста перед передачей его в функцию дайджеста сообщения. Это делает словарные атаки невозможными, если злоумышленник не может получить соль, а также делает заранее вычисленные атаки гораздо более ресурсоемкими для успешного проведения. Несмотря на общеизвестное мнение, "соление" не останавливает радужные таблицы, это просто означает, что вам нужен НАМНОГО БОЛЬШЕ набора радужных таблиц.
2) Куда вы собираетесь положить ключ для своей зашифрованной базы данных? Sqlite - это просто файл, который вы можете зашифровать, а затем расшифровать при запуске приложения, это просто добавляет некоторое время загрузки, но во время выполнения это будет так же быстро. Настоящая проблема в том, что нет абсолютно никакого места , где можно поставить секрет на устройстве, который злоумышленник не сможет получить. Злоумышленник имеет больше контроля над устройством, чем вы. Злоумышленник может взломать устройство и делать все, что захочет. Даже если ключ передается во время выполнения, его все равно можно получить, просмотрев память устройства. Любые попытки зашифровать базу данных могут быть подорваны, это может усложнить задачу, но не остановит опытного хакера.