Ответ 1
LocalStorage в нормальных условиях доступен только для вашего приложения. Это так же безопасно, как песочница на конкретной платформе (iOS, Android) способна защитить данные вашего приложения от чтения другими приложениями.
Иногда эта песочница не так сильна, как вы могли бы ожидать, например, в следующих случаях:
- устройство рутировано или взломано
- производитель не смог предоставить обновления безопасности или пользователь просто не обновил
- злоумышленник имеет физический доступ к устройству, например, если оно украдено.
Если у злоумышленника есть доступ к паролю и имени пользователя в виде открытого текста, он может попробовать их также для других учетных записей (не только для вашего сервиса). Поэтому, если пользователь вашего приложения использовал один и тот же пароль для нескольких служб, злоумышленник также может получить к ним доступ.
Как насчет хранения хэша пароля?
Для серверных приложений это отличная идея, поскольку они работают в защищенной среде (центры обработки данных с контролем доступа, системные инженеры, занимающиеся обновлениями безопасности).
С другой стороны, телефон легко украсть, и пользователи часто не устанавливают или не могут устанавливать обновления безопасности.
Если хеш не засолен, очень просто получить пароль в виде открытого текста, используя радужные таблицы, если вы получили хеш. Если хеш солен, очень просто получить пароль в виде открытого текста для простых паролей. Кроме того, очень легко генерировать небезопасные хэши паролей.
Решение: хранить произвольно сгенерированные токены доступа: независимо от того, насколько простой или сложный пароль, просто невозможно получить пароль в виде простого текста, посмотрев на токен.
TL; DR
Если вы используете учетные данные для аутентификации на каком-либо API-сервисе, вы не должны хранить пароль и имя пользователя локально, даже в безопасном хранилище, таком как цепочка для ключей iOS.
Вместо этого вам следует хранить только случайно сгенерированный токен (НЕ хэш пароля!), Который вы получаете от этого API (аналогично концепции хранения идентификатора сеанса в файле cookie, а не в комбинации пользователь/пароль). Одной из возможностей будет использование OAuth.
Таким образом вы гарантируете, что реальные учетные данные никогда не будут пропущены, даже если песочница не сможет защитить данные или телефон будет украден.