Безопасное хранение персональных данных пользователя на устройстве iOS

Question

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

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

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

Неужели это просто страшная идея хранить эту информацию локально? Или существуют относительно простые средства для безопасного шифрования этого? Поддерживает ли iOS и Android O/S какую-либо помощь?

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

спасибо!

Answer 1

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

Существует еще один уровень шифрования, который вы можете наложить на это, используя код доступа, называемый Data Protection, который предотвращает чтение данных, если пароль не введен.

Вы можете вручную включить защиту данных в своем приложении, используя NSFileManager для доступа к файлам и установки атрибута NSFileProtectionKey на NSFileProtectionComplete. См.: Implementing and Testing iOS data protection.

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

Возможно, вы сможете легко включить защиту данных через профиль обеспечения для своего приложения, даже если вы не используете класс NSFileManager с NSFileProtectionComplete. См.: Data Protection/NSFileProtectionComplete - successfully supported through entitlements.plist?

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

Answer 2

Просто следуйте за этим сообщением от года назад. То, что я решил сделать, это создать случайный ключ сеанса (аналогично предложению @Marcus Adams), но использовать его как соль. Затем я объединяю этот ключ сеанса с выбранным пользователем открытым текстовым паролем и сохраняю это значение на устройстве (если пользователь решил сохранить свой пароль). я.е, устройство сохраняет это значение:

device_hash = sha256 (device_salt || открытого текст)

Это хэшированное значение, то становится строкой, что я перейти на HTTP-сервер для проверки. На стороне сервера у меня есть другое значение соли, хранящееся там. Когда сервер получает хеш-значение устройства, он имеет свое собственное значение соли, которое оно объединяет с этой строкой, а затем выполняет свой собственный хэш. Этот конечный хеш - это пароль, который хранится в базе данных сервера. то есть, сервер хранит эту строку:

server_hash = sha256 (server_salt || device_hash))

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

Любопытно, если кто-либо критикует этот подход.