Запретить пользователю (хакеру) просматривать строку, встроенную в настольное приложение .NET

Я создаю приложение, которое использует секретный ключ для связи с REST API (через https). Я не хочу, чтобы пользователь/хакер обнаружил этот ключ и создал собственное приложение, которое могло отправлять ложные данные на сервер. Каковы наилучшие варианты защиты этого «струнного» внутри приложения?

Вот варианты, о которых я думал:

1) Жесткий код этой строки внутри приложения и обфускации сборок. Я думаю, что все-таки некоторые методы деобфузии могут расшифровать это.

2) Передайте его в app.config и зашифруйте при установке с использованием этого встроенного механизма .NET. Насколько я понимаю, ключ дешифрования хранится где-то внутри окон и не отображается пользователям. Кто-то должен иметь хорошие системные знания и навыки взлома, чтобы получить это, да? Если да, то еще, когда пользователь загружает установочный пакет, он сможет распаковать его и увидеть секретный ключ, не так ли?

Есть ли у меня другие возможности?

Я знаю, что на клиентской машине нет никакого способа обеспечить безопасность - нет 100% методов защиты.

Bartek

2
nl ja de
Является ли аутентификация пользователя опцией?
добавлено автор paparazzo, источник
Пользователь все равно аутентифицирован, но «хакер» может создать собственное приложение, которое будет использовать мой REST API для отправки ложных данных. Крайне важно, чтобы WEB API потреблял только реальные данные, созданные только моим приложением.
добавлено автор bodziec, источник
Даже запутывается? Может быть, это не невозможно, но это тяжелее, да?
добавлено автор bodziec, источник
Хранение секретного ключа как части приложения - плохая идея. Все копии приложения будут иметь один и тот же секретный ключ. Тривиально перечислять все строки управляемого приложения. То есть легко извлечь «секретный» ключ из двоичного кода.
добавлено автор Brian Rasmussen, источник

3 ответы

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

  • заставьте ваш REST-ключ трудно воспроизвести (не используя его)
  • сделать вызовы трассируемыми на сеанс одного пользователя

Вот как вы можете имитировать, как браузеры аутентифицируют пользователей. Еще одним примером является поток веб-приложений на стороне клиента OAuth2.

  1. Ask for the user's password
  2. Authenticate the user, probably using the same REST API you want to protect. By definition, this is not an authenticated call. Think of a login form, it is always public, on an HTTPS connection.
  3. On the server side, generate a random number, called nonce and save it.
  4. The user is still waiting for his logon, send him the nonce. That will be his very own REST password

Теперь, когда ваш пользователь щелкает где-то в вашем богатом клиенте, который должен сделать вызов REST

  1. Добавьте пару имени пользователя-не-тега к вашему вызову REST
  2. На сервере, когда приходит вызов REST, убедитесь, что имя пользователя-nonce действительны.
  3. Вызовите какой-то вариант выхода из вашего API, и срок действия nonce истекает через некоторое время, если не используется.

Сам по себе nonce должен быть трудно догадаться, GUID не будет делать. SHA-1 (или лучше) GUID в порядке.

Это много неприятностей? Правда, но это ваша единственная надежда. Скорее всего, ваша архитектура сервера и клиентская библиотека уже поддерживают некоторую схему проверки подлинности, которую вы можете использовать повторно, например, HTTP BASIC auth.

2
добавлено

Проблема с одним секретным ключом - это когда вы выберете secrete, тогда вы не можете доверять никаким данным.

Любая форма учетных данных, поступающих с устройства, может быть взломана.

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

Учетными данными могут быть пользователь/пароль, сертификат или даже секретный ключ.
Не удалось настроить приложение для запроса сертификата.

1
добавлено
Вы не можете предотвратить это, но вы можете наверняка закрыть его. НАПРИМЕР. аннулировать сертификат. Проблема с одним секретным ключом не может отключить выбранные устройства.
добавлено автор paparazzo, источник
Это приложение будет иметь пару валидационных форм - логин, ключ сеанса и т. Д. В любом случае, я считаю, что я не могу этого предотвратить ...
добавлено автор bodziec, источник

Не храните секрет на клиенте. Храните его и используйте его на сервере.

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

Вы правы: когда кто-то является администратором системы, вы не можете доверять системе, чтобы сохранить что-то в безопасности.

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

1
добавлено
Спасибо за ответ, но, может быть, я перефразирую свой вопрос: как обеспечить безопасность веб-api, чтобы принимать заявки от доверенного клиентского приложения, созданные мной? Любой вариант, о котором я думаю, позволит обнаружить секретный ключ, идентифицирующий доверенное приложение, деобфушающий код, чтобы увидеть алгоритм, и использовать эти знания для создания ложного приложения, которое представит себя как доверенное.
добавлено автор bodziec, источник
Это немного, как это будет работать. Я просто хочу быть уверенным, что даже если я это сделаю, «вредоносный» пользователь может попытаться декомпилировать сборки, узнать, как это работает, создать собственное приложение, которое подписывает соединение с этим сертификатом, да?
добавлено автор bodziec, источник
создавать сертификаты, передавать их доверенным пользователям, принимать только соединение, защищенное этими сертификатами. Другими словами: настроить сервер только для приема лицензированных клиентов.
добавлено автор Erno de Weerd, источник
Кибербезопасность АСУ ТП: RUSCADASEC Community
Кибербезопасность АСУ ТП: RUSCADASEC Community
1 389 участник(ов)

Группа открытого независимого сообщества специалистов по кибербезопасности АСУ ТП / RUSCADASEC для интерактивного обмена информацией по теме Подробнее: www.ruscadasec.ru Наш канал для основных новостей и материалов @RUSCADASECnews

secinfosec
secinfosec
697 участник(ов)

Эта группа про информационную безопасность. Целевая аудитория: пентестеры, ресерчеры, ибшники всех мастей. Реклама, криминал, политика и прочая чушь карается родовыми проклятьями. Митапы: https://www.youtube.com/channel/UCagEjp1FmxY9gsVxi6_d4SQ

Linux Security
Linux Security
652 участник(ов)

Данная группа принципиально про безопасность и в частности про безопасность Linux. Прочие темы просим обсуждать в профильных чатах.

Chat Security / ИБач чат
Chat Security / ИБач чат
601 участник(ов)

Чат канала @ibach Обсуждение всего, что касается информационной безопасности Правила: https://t.me/chat_security/65