2017-01-19 2 views
1

Итак, просто немного фона на настройке.Как правильно защитить учетные данные api в приложении C#

В настоящее время у меня есть веб-проект Api2, который является серверной частью этого спокойного api. Клиенты в настоящее время используют комбинацию имени пользователя/пароля для получения токена-носителя, который затем используется в последующих вызовах api. Проект хранится в частном проекте GitHub.

Я ищу для создания и развертывания службы windows C#, которая будет использовать этот api. Какова будет наилучшая практика в отношении развертывания и хранения учетных данных вместе с этой службой Windows.

Я управляю обоими концами api, и я буду управлять развертыванием службы Windows. Это будет упаковано в виде msi и развернуто через какое-то стороннее программное обеспечение (автоматическое).

Ниже приведены требования

  • Полномочия не могут быть сохранены в системе управления версиями
  • полномочий не может быть в виде текста на стороне клиента.

Таким образом, мой вопрос: как я могу получить учетные данные api на клиенте, а не в обычном тексте, но в удобном для использования формате?

Или я должен искать другой тип аутентификации для api? Я коротко посмотрел на oauth2, но насколько я могу сказать, вам понадобится кто-то на стороне клиента, чтобы принять его?

Если у кого-то есть какие-либо советы или ресурсы о том, как это сделать, это было бы потрясающе.

ответ

1

Я не то, что эксперта, но у меня был подобный случай, я возьму свой шанс на получение некоторых вниз голосов: 0)

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

Но если вы хотите сделать это автоматически и сохранить учетные данные, это не очень хороший способ сделать это. Вы можете запутать учетные данные и не разрешать детям сценариев видеть их, но для более серьезных хакеров это будет довольно легко взломать.

Есть еще несколько вариантов, но все они являются взломами. Другим подходом будет регистрация каждой машины на вашем сервере с MAC-адресом и случайной строкой (GUID выполнит задание), которая будет сохранена с использованием класса ProtectedData, и тогда только эта конкретная пара ключей и значений сможет получить данные от вашего API. У вас есть 2 проблемы здесь:

  1. Если пользователь удалить приложение и установить его заново, то он не сможет подключиться к серверу (так как он не может повторно производить тот же GUID). Вы можете удалить пользователя на сервере и создать нового пользователя, но вы не можете просто изменить руководство на сервере, так как каждый сможет взломать пользовательские данные на сервере.
  2. Любой пользователь сможет открыть пользователя на вашем API и использовать его.
+0

Я собираюсь отметить это как ответ, потому что, хотя он не решал напрямую проблемы, он поставил меня на правильный путь. На клиентских серверах уже есть GUID, которые могут быть доступны как часть другого программного обеспечения третьей стороны. Эти GUID также могут быть доступны с серверной стороны, поэтому мы решили использовать технически «открытую» api, которая использует этот GUID в качестве аутентификации – tjackadams