Можно ли в .NET безопасно хранить учетные данные?

#c_sharp #net #безопасность

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

Можно захардкодить ее в коде, но это не безопасно, так как .NET приложение можно
декомпилировать и узнать эти данные.


Есть ли способы безопасного хранения учетных данных непосредственно в коде C# или
конфигах?
Какие есть альтернативы такому хардкодингу?

    

Ответы

Ответ 1

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

Т.е. пользователь всегда может просто взять и перехватить вызов того же HttpWebRequest.GetResponse()
(и любого другого способа работы см удаленным ресурсом), и достать сырые имя и пароль
из заголовков или тела запроса. Или еще проще - он может поставить fiddler и просто
просмотреть траффик.

То же самое касается любых других видов соединения - от SQL Server до самописных
протоколов. Точно так же нельзя "спрятать" имя и пароль от SQL Server при подключении
к SQL напрямую из desktop app.



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


Ответ 2

Можете хардкодить в программе шифрованные строки Ваших учетных данных любым симметричным
криптостойким алгоритмом, к примеру криптопровайдер AES(128/192/256). В App.сonfig
либо при запуске программы запрашиваете переменную-ключ. Пользователь вводит ключ,
вы раскодируете учетные данные и логинитесь на сервере. Аутентификация на сервере пройдет
успешно только при полном соответствии ключа, в противном случае расшифрование даст
просто набор рандомных символов. Такой способ безопасен при декомпиляции, так как логин
и пароль зашиты в виде шифрованного текста. Даже при успешной декомпиляции восстановить
исходные данные (логин и пароль в открытом виде) по шифрованному тексту без  наличия
ключа - крайне трудоемкая задача.

UPD:

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

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


Ответ 3

Возможно вам поможет Data Protection Application Programming Interface