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

Я создаю приложение и веб-сайт для проекта, который у меня есть, но я не уверен, что делать с логином. Это не «Я noob, и я хочу приложение с логином» -question. Я несколько опытен как с веб-технологиями, так и с базами данных и приложениями, но я никогда не затрагивал тему безопасности перед тем, чем не применял шаблоны приложений.Какова стандартная процедура, используемая для систем входа в iOS-приложения?

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

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

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

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

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

источник

2014-01-14 Sti

Я имел дело с этим с помощью WebView, чтобы отобразить веб форму входа, и, при успешном входе в систему, установив печенье с маркером проверки подлинности, ассоциированные с пользователем в интерфейсе. – Linuxios

@ Linuxios Я где-то читал, что некоторые приложения были отклонены Apple за это. В любом случае, даже если это «разрешено», это не совсем то, что я хочу. Я хочу создать свою собственную регистрационную форму для iOS-UI. Спасибо, в любом случае. – Sti

Вместо использования алгоритмов хэширования (md5, sha), не предназначенных для использования с паролями, учитывая использование более безопасного (например, PBKDF2). См. Сообщение SO здесь: http: //stackoverflow.com/q/8569555/558933 –

передача пароля

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

Запоминание Логины

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

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

источник

2014-01-14 00:47:43

Хорошо. Хотя у вас есть какая-то большая и актуальная информация здесь, я думаю, вы немного неправильно поняли мой «Хранение логинов» - вопрос. Я имел в виду на устройстве, в приложении; как пользователь остается включенным в мою службу на устройстве. «Какова стандартная процедура хранения учетных данных локально». «Должен ли я использовать, и если да, то как создавать и использовать токены». «Должен ли я отправлять учетные данные вместе с каждым запросом сервера» и т. Д. И мы используем Java на базе, кстати :) – Sti

Я думаю, вы неправильно поняли мой ответ, а затем :). Я считаю, что JSP имеет встроенную обработку сеанса, поэтому, если вы используете библиотеку http с постоянным банком cookie в своем приложении, логины будут храниться точно так же, как и в веб-браузере. Сервер автоматически создаст токен сеанса и отправит его в приложение в качестве файла cookie; приложение автоматически отправит этот файл cookie вместе со всеми запросами. –

О, ладно .. Ну, мы не используем JSP. У нас есть сервер приложений Google App Engine с Java, с его собственным API/библиотекой, и я не думаю, что они используют файлы cookie. Возможно, я ошибаюсь, и мы могли бы сделать это сами. Но действительно ли большинство приложений с логином действительно используют куки в наши дни? Все, что я читал, это токены, какая разница? – Sti

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

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

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

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

источник

2014-01-14 06:01:04

С этим, что лучше всего подходит для аутентификации?Должно ли устройство отправлять имя пользователя и пароль в качестве аргументов каждый раз, когда он выполняет действие, связанное с db, а затем проверяет подлинность каждого шага? – Sti

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

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

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

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

Alex

источник

2014-01-14 10:01:54 below

Одна проблема с использованием * Auth - вы доверяете, что другая служба обеспечила хорошие пароли. Также вы доверяете своей безопасности, и они могут быть гораздо более крупной целью хакера. Поэтому я не использую ее. – zaph

В настоящее время мы используем Google App Engine как бэкэнд (java), а OAuth2, похоже, поддерживается и рекомендуется многими, но мы не можем найти документацию, которая имеет смысл для нашей цели. Вы использовали App Engine? – Sti

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

ответ

Смежные вопросы