Защита пароля в исходном коде? - PullRequest
37 голосов
/ 11 ноября 2010

В моем коде есть пароль, необходимый для подключения к серверу sftp. Как лучше всего «запутать» или спрятать его в коде?

Спасибо

Ответы [ 10 ]

27 голосов
/ 11 ноября 2010

Не храните свой пароль в исходном коде, храните его в защищенном разделе в вашем App.Config (или Web.Config).

См. Шифрование разделов файла конфигурации с использованием защищенной конфигурации раздел в этом Microsoft Doc

Это работает путем шифрования ключей шифрования с использованием встроенного в Windows материала, привязанного к адресу Mac и различных других недокументированных вещей.

Это будет работать, даже если вы используете более одного сервера:

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

Используя это, если кто-то хочет получить ваш пароль, он должен будет сначала взломать систему безопасности Windows на вашем сервере (не невозможно, но сложнее, чем проверять ваш IL на предмет пароля).

13 голосов
/ 11 ноября 2010

Не беспокойся.
Всё, что вы можете сделать, ваш атакующий может легко отменить.

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

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

12 голосов
/ 17 ноября 2016

Я считаю, что использование функции «защищенных разделов» в App.Config или Web.Config МЕНЬШЕ безопаснее, чем сохранение пароля в вашем коде.

Любой, имеющий доступ к серверу, может расшифровать этот раздел конфигурации так же быстро, как вы его зашифровали, выполнив команду расшифровки, описанную в статье, которую все продолжают цитировать:

aspnet_regiis -pd "connectionStrings" -app "/SampleApplication"

https://msdn.microsoft.com/en-us/library/zhhddkxy.aspx#Anchor_1

Таким образом, эта функция ASP.Net добавляет безопасность только в том случае, если хакер каким-то образом имел доступ к вашему web.config, но не ко всему вашему серверу (произошло в 2010 как @ djteller упоминается в комментарии к атаке оракула).Но если у них есть доступ к серверу, вы получаете один вызов cmd .Им даже не нужно устанавливать ildasm.exe.

Однако сохранение реальных паролей в вашем коде - кошмар обслуживания.Итак, одна вещь, которую я видел, это сохранение зашифрованного пароля в вашем файле web.config и сохранение ключа шифрования в вашем коде.Это позволяет скрыть пароли от случайного просмотра, сохраняя при этом поддержку.

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

Тем временем я также ищу лучшие ответы на этот шестилетний вопрос ...

3 голосов
/ 11 ноября 2010
2 голосов
/ 11 ноября 2010

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

2 голосов
/ 11 ноября 2010

Вы можете поместить его как зашифрованное значение в файл web.config.Это не выглядит слишком сложно: учебник К Скотта Аллена http://odetocode.com/blogs/scott/archive/2006/01/08/encrypting-custom-configuration-sections.aspx

Я думаю, что есть блог Скотта Гу со ссылками на другую информацию.http://weblogs.asp.net/scottgu/archive/2006/01/09/434893.aspx

2 голосов
/ 11 ноября 2010

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

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

1 голос
/ 11 ноября 2010

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

1 голос
/ 11 ноября 2010

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

У вас есть другой вариант?Доступ к сырому SFTP довольно опасен, может быть, вы можете создать какой-то прокси-сервис между ними, который позволяет выполнять только те действия, которые требует ваше приложение.Хранение пароля для этой службы в вашем коде не так рискованно, как сохранение вашего SFTP-пароля в вашем коде.

1 голос
/ 11 ноября 2010

Не сохраняйте свой пароль в исходном коде.

Прочитайте это: http://en.wikipedia.org/wiki/Security_through_obscurity

Нет хорошего способа.

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

Опытный реверс-инженер сможет его взломать.

...