Насколько безопасна эта аутентификация на основе подписи для мобильных устройств

Question

Я внедряю приложение, в котором у меня нет системы, требующей имя пользователя и пароль. Что мне нужно, так это имя и номер телефона.

Сценарий таков:

1) пользователь впервые открывает приложение

2) приложение делает запрос на мой сервер и получает уникальный UserKey

3) с этого момента один любой запрос приложения к моей REST-службе также имеет подпись. Подпись на самом деле является SHA (UserKey: данные, указанные в запросе Base64Encoded)

4) Сервер также выполняет тот же хэш для проверки подписи

Почему я не использую SSH:

• не желает платить за сертификат
• Мне не нужно отправлять конфиденциальные данные, такие как пароли, поэтому я не вижу выгоды от их использования
• Мне просто нужен простой способ вызова собственных служб WCF REST из собственного приложения

Я понимаю, что на шаге 2 возникает поток безопасности, когда UserKey вводится в виде открытого текста, но это происходит только один раз, когда приложение впервые открывается. Как вы думаете, насколько это опасно?

Что бы вы порекомендовали? Есть ли какая-нибудь библиотека .NET, которая может мне помочь?

Answer 1

На самом деле, есть несколько проблем с этим подходом.Предположим, что когда вы делаете запрос к серверу, есть человек посередине.Анализируя, например, 100 отправленных пакетов, он распознает аналогичный шаблон с подписью в ваших запросах.Затем он подделает свой запрос и добавит вашу подпись.Сервер проверяет хеш - все в порядке, это вы и ваш уникальный ключ пользователя.Но это не так.

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

Еще лучше, поскольку проблема действительно распространена, вы можете использовать OAuth для авторизации пользователей на вашем веб-сайте.Он безопасен, широко используется (Facebook, G +, Twitter, вы называете их) и имеет реализации уже на разных языках.

Answer 2

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

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