Какова стандартная процедура, используемая для систем входа в iOS-приложения?

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

То, что я представляю, - это "простая" система входа в систему, такая как Skype, Facebook, NetFlix, действительно любое приложение, к которому вы можете войти в систему, в котором также есть веб-сайт для входа в систему.

Часть моего вопроса касается безопасности процесса. Моя первоначальная мысль состоит в том, что пароль в чистом тексте никогда не должен быть отправлен через Интернет, что заставляет меня думать, что пароли должны быть хэшированы/зашифрованы на телефоне, а также на веб-сайте при входе в систему. хэширования/шифрования времени раньше, но просто используя sha1 и md5 для "преобразования" текста. Каков правильный способ сделать это? С моими текущими знаниями я предполагаю, что если я использую md5 для шифрования пароля, любой может также расшифровать его с помощью md5, но я мог бы использовать SALT (?) Или некоторую форму для изменения ключа. Это то, как это делают "большие мальчики", или есть секретный проход, о котором я не знаю?

Теперь на реальный вопрос. Как я должен безопасно хранить логин?

То, что я пробовал: при создании "тестового проекта" в Xcode для этого я просто создал класс User с полем для username. Когда "входе", введя имя пользователя и пароль, я просто отправил POST -method HTTP-request на мою .php -страницу, которая просто выполнила SELECT * FROM User WHERE Username = '$_POST['username']' AND Password = '$_POST['password']';. Если база данных вернула одну строку, тогда пароль был правильно, и страница может распечатать пользователя в JSON или что угодно. Когда устройство получило успешный вход в систему, я преобразовал пользовательский объект в приложение, теперь содержащий имя пользователя (и потенциально UserID, E-mail, адрес и т.д.) До NSData* и используя NSKeyedArchiver и NSKeyedUnarchiver, чтобы сохранять и загружать пользователя, а не снова проверять подлинность. Если пользователь нажимает "Выход", я протираю этот "архив". Это работает, но я чувствую, что это не особенно безопасный способ сделать это. Если да, то почему именно это?

(Наш back-end в настоящее время является Google App Engine (java), который поддерживает OAuth. Некоторые рекомендуют это, но мы не можем найти подходящую документацию, которая имеет смысл для нашего плана с пользовательскими пользователями)

Ответ 1

Передача паролей

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

Сохранение логинов

Ваши пароли должны храниться в базе данных как соленый хеш (случайная соль с устойчивой к столкновению хэш-функцией, такой как SHA256). Не храните текстовую версию пароля в любом месте. Если вы используете PHP на стороне сервера, вы можете использовать новую функцию password_hash() или crypt() для генерации и сравнения ваших соленых хэшей.

Если вы надежно передаете SSL, вы должны просто использовать возможности сеанса вашего веб-сервера для отслеживания логинов (например, $_SESSION['user_id'] = ...).

Ответ 2

Если вы хотите безопасно хранить свое имя пользователя/адрес электронной почты или адрес или что-то еще, то встроенный keychain единственный счастливый способ Apple.

Посмотрите SSKeychain (или PDKeychain или UICKeychain) и расширьте его, чтобы включить каждое свойство, которое вы хотите сохранить. Как правило, он использовался для хранения комбинаций имени пользователя и пароля, но может быть расширен для безопасного хранения произвольных данных.

Что касается передачи защищенных данных на ваш сервер, сделайте это через HTTPS.

Я могу привести примеры, если вы хотите.

Ответ 3

Другой вариант - добавить какой-то процесс входа в систему OAuth или XAuth.

Таким образом, вы не храните пароли, а только так называемые "токены". Токены истекают и могут быть отменены.

Не сохранять имя пользователя и пароль вообще - лучший способ их защитить.

Алекс