Я разрабатываю веб-сайт, на котором будет мобильный компаньон (только для iPhone). Веб-сайт будет представлять собой приложение ASP.Net MVC 3. У меня также будет сайт веб-API ASP.Net(MVC 4) для предоставления услуг iPhone-приложению. Приложение iPhone будет иметь собственную форму для захвата имени пользователя и пароля от пользователя и отправки его в веб-API в заголовках JSON.
Я хочу рассматривать безопасность с самого начала, а не после мысли. Я не эксперт по безопасности. Я провел много исследований, чтобы узнать, как другие обрабатывают аутентификацию клиента мобильного приложения из веб-службы. Я думаю, что придумал достойное решение, которое не связано с подключением сторонних сторонников.
Я был бы очень признателен за любые мнения, советы, критику и общие WTF, которые любой из вас может предложить.:)
Мои самые большие проблемы:
- Обеспечение авторизации вызовов, сделанных в веб-API.
- Сведение к минимуму риска повторных атак (следовательно, временные метки в приведенных ниже вызовах)
Приложение iPhone будет разработано как таковое:
Две строки жестко закодированы в приложении iPhone (одинаковые значения для каждого пользователя):
- Идентификатор приложения
Это строка, которая используется для идентификации типа клиента, который обращается к веб-API (iPhone, Android, телефона Windows и т.д.). < ш > - Сочетание хищников приложений
Это строка, которая используется для солевых хешей для пользовательских запросов.
Две строки хранятся в локальной базе данных приложения iPhone (значения уникальны для каждого пользователя):
- Ток доступа к API-интерфейсу
Это строка (токен), предоставляемая клиенту веб-API при успешной аутентификации и позволяющая клиенту получить доступ к веб-API без отправки имени пользователя и пароля в каждом запросе. - Сопровождение пользователя
Это строка, которая используется для солевых хэшей для запросов, сделанных против установленных учетных записей пользователей.
IPhone выполнит вызовы веб-API следующим образом:
Метод API: создать учетную запись
Клиент отправляет:
- Новые данные учетной записи (имя пользователя, пароль, имя, фамилия и т.д.)
- Идентификатор приложения
- Временная метка UTC
- Хеш отметки времени UTC + Идентификатор приложения, соленая с помощью соляной аппликации
Возврат API:
-
Идея заключается в том, что при создании учетной записи я могу использовать приложение hardcoded salt, так как это не представляет большой угрозы безопасности, если эта соль когда-либо выходила (через декомпиляцию или какую-то другую средства).
Но для методов, которые обеспечивают доступ и изменение пользовательских данных, я использую соль, которая принадлежит только этому пользователю, поэтому она не может использоваться злоумышленником для олицетворения других.
Метод API: получить учетную запись
(Используется для получения пользовательской хеширующей соли для учетных записей, созданных на веб-сайте, но еще не синхронизированных на iPhone. Это происходит, когда пользователь пытается выполнить регистрацию на iPhone и iPhone обнаруживает, что у него нет записи для этого имени пользователя.)
Клиент отправляет:
- Имя пользователя
- Пароль (хэшируется с помощью соляной аппликации)
- Идентификатор приложения
- Временная метка UTC
- Хеш отметки времени UTC + Идентификатор приложения, соленая с помощью соляной аппликации
Возврат API:
- Существующая пользовательская соляная сварка
Метод API: вход (аутентификация)
Клиент отправляет:
- Имя пользователя
- Пароль (хешированный с помощью Hash Salt)
- Идентификатор приложения
- Временная метка UTC
- Хеш отметки времени UTC + Идентификатор приложения, соленый с помощью Hash Salt
Возврат API:
- токен доступа к API
Метод API: любая команда (т.е. создание сообщения, обновление профиля, получение сообщений и т.д.)
Клиент отправляет:
- Данные команды
- токен доступа к API
- Идентификатор приложения
- Временная метка UTC
- Хеш отметки времени UTC + Идентификатор приложения + Пользовательский токен пользователя API, соленая с помощью Hash Salt
