Обработка функций входа в систему для подключения собственного приложения к веб-сервису

После обширных исследований я не смог найти четкого ответа на мой вопрос. Во-первых, может ли кто-нибудь сказать мне основную логику обработки "функций входа в систему" для родного приложения iphone, подключающегося к веб-службе? Например, приложение facebook запрашивает имя пользователя и пароль сразу после запуска, а оттуда у вас есть полный доступ к вашей учетной записи во всех последовательных представлениях приложения. Каждый раз, когда вы публикуете что-то и т.д., Вам не нужно повторно регистрироваться... Может ли кто-нибудь объяснить мне этот процесс? Это делается через файлы cookie или сеансы? вовлечен ли Брелок?

У меня сейчас работает полурабочее приложение, но я почти уверен, что могу сделать это лучше и безопаснее. Вот что я делаю:

1) Настройте локальный сервер с базой данных пользователей (столбцы имени пользователя и пароля и другие таблицы и т.д.) с помощью mysql. Написал простой веб-сервис, который принимает данные POST и запрашивает базу данных, чтобы проверить, что имя пользователя существует... и если да, то пароли равны. Использование хэширования sha1. Echo true или false соответственно.

2) Мое приложение имеет начальный экран входа с двумя текстовыми полями (1 для имени пользователя и 1 для пароля) и кнопкой, вызывающей метод входа. Мой метод входа в систему выполняет следующие действия:

init a * NSURL со строкой (URL-адрес моей веб-службы: @ "http://webservice.com/login.php" )
init a * ASIFormDataRequst с этим URL
установите значение post с текстом пароля и электронной почты в текстовых полях
установите делегат для себя
вызов startAsycronous по запросу
реализовал метод requestFininshed для извлечения "истинного" или "ложного" эха из веб-службы
в зависимости от ответа, перейдите к следующему представлению, иначе сделайте предупреждение, чтобы пользователь повторил

Итак, мои вопросы:

1) Безопасно ли это для отправки паролей? (через ASIHTTPRequest и метод POST?) 2) В последующих представлениях пользователь должен иметь возможность взаимодействовать со своей учетной записью (например, отправлять сообщения и статус и фотографии на Facebook). Как я сохраняю статус пользователя, зарегистрированного в журнале, так что каждый раз, когда пользователь взаимодействует с базой данных, я может гарантировать, что пользователь все еще зарегистрирован и что он тот же пользователь? Например, единственный способ, которым я могу это сделать, - хранить файлы cookie на пользовательском устройстве с именем пользователя и паролем, а затем каждое последующее взаимодействие с веб-службой/базой данных, он выполняет аутентификацию с значениями cookie (имя пользователя и пароль).

Должен быть лучший способ сделать это? Может быть, сеансы или куки? или с помощью keychain??

Спасибо за помощь, ребята, и извините за длинный вопрос!

Ответ 1

Вот мои мысли, основанные на том, что я знаю:

1) Is this secure for sending passwords? (via ASIHTTPRequest and the POST method?)

Вам нужно убедиться, что вы отправляете эту информацию через https (SSL), а не простой Http. Причина в том, что у вас нет контроля над тем, где находится беспроводная точка доступа пользователя. Насколько вам известно, пользователь может подключиться к открытой точке доступа, принадлежащей определенному хакеру. Передача этого сообщения позволит ему обнюхать пакет и получить необходимую информацию для доступа к WebService, даже если пароль хэшируется. Передача через https гарантирует, что пакет зашифрован сильным ключом. Даже если хакеру удается обнюхать пакет, ему потребуется много времени, прежде чем он сможет расшифровать сообщение.

2) В последующих представлениях пользователь должен иметь возможность взаимодействовать со своей учетной записью (например, отправлять сообщения > сообщения и статус и изображения на Facebook). Как я сохраняю статус пользователя, зарегистрированного в журнале > , чтобы каждый раз, когда пользователь взаимодействует с базой данных я могу гарантировать, что пользователь все еще зарегистрирован и что он тот же пользователь?

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

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

для проверки подлинности через login
Телефон украден хакерами, которые могут взять маркер, осмотрев локальное хранилище.

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

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

Существует много алгоритмов для генерации этого токена. Например, язык программирования Java предоставляет класс SecureRandom, чтобы обеспечить криптографическую хаотичность, и .NET имеет схожую безопасную RandomGenerator.

Если вы хотите взглянуть на алгоритм, OATH предложил Алгоритм одноразового пароля (TOTP), основанный на времени, который является расширением HOTP. Большинство языков/платформ будут иметь криптографически сильный случайный генератор, который вы могли бы использовать сразу, но без необходимости писать его самостоятельно.

В зависимости от вашей реализации/платформы службы вы можете спросить SO о подходящем классе/модуле для криптографически случайного генератора, например, запрошенного здесь "Как вы создаете криптографически безопасную случайные числа с php"