Запретить программистам знать пароли, используемые во время выполнения

Question

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

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

РЕДАКТИРОВАТЬ: я знаю, что FTP не является безопасным. В идеале мне бы хотелось, чтобы техника работала в любой ситуации, когда требуются имя пользователя и пароль (например, соединение с базой данных).

Answer 1

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

Вам действительно нужен способ дать каждому пользователю уникальный токен.

Редактировать - больше информации:

Любая система, которая использует «секретную» информацию для входа в систему, одинаковую для каждой копии приложения, имеет недостатки в дизайне. Чтобы обеспечить безопасность, каждая установка вашего приложения должна иметь уникальный секрет, который он использует для аутентификации на сервере. То, как вы этого добьетесь, зависит от того, как вы лицензируете / распространяете свое приложение. Вот как бы я это сделал. (Выполните все коммуникации через соединение SSL).

1. Приложение запускается впервые - оно видит, что оно не сохранило информацию аутентификации.
2. Приложение запрашивает у вас регистрационный код, адрес электронной почты и / или как вы хотите идентифицировать своих пользователей.
3. Приложение генерирует открытую / закрытую пару ключей и отправляет открытый ключ с вашей идентификационной информацией с шага 2 на сервер.
4. Сервер теперь запоминает ваш ключ и использует его для идентификации вашего приложения.

Альтернативный шаг 3: приложение отправляет информацию из шага 2, а сервер отправляет обратно хэш-подпись info + salt. Хэш-подпись теперь является ключом вашего приложения.

Важно то, что между всеми вашими пользователями не существует «секрета».

Answer 2

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

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

Шаги к правильному решению вашей проблемы:

• Переключиться на безопасный протокол, такой как SFTP или FTP + SSL
• Использовать аутентификацию с открытым ключом вместо пароля (SFTP и FTP + SSL поддерживают это, хотя и немного по-разному)
• Предоставьте каждому развертыванию программного обеспечения (желательно уникальную, чтобы вы могли обнаружить общий доступ к учетным данным и отключить скомпрометированные учетные записи) копию личного ключа / сертификата, необходимого для входа в систему
• Храните закрытый ключ / сертификат наиболее безопасным способом на платформе, на которой вы работаете. В Windows это означает использование хранилища сертификатов - см. в этой статье MSDN Magazine , где можно найти хорошее введение

РЕДАКТИРОВАТЬ (после изменения исходного вопроса): первый абзац моего ответа в равной степени относится к таким вещам, как пароли базы данных и т. Д. Решение для таких ситуаций становится еще более специфичным для платформы. Если ваша конкретная комбинация базы данных / любой другой / ОС не поддерживает безопасный вход в систему, вы не можете ничего сделать.

Например: в Windows SQL Server поддерживает проверку подлинности NTLM, что позволяет устанавливать права доступа к базе данных на основе существующих учетных записей Windows, обеспечивая автоматическое безопасное хранение и передачу паролей, которые относительно трудно обойти. Если аутентификация NTLM не может быть использована, лучшее, что вы можете сделать (как это рекомендуется в .NET Framework), - это сохранить пароль, зашифрованный с помощью машинно-зависимого ключа, в файле конфигурации. Однако эту «защиту» тривиально обходят с помощью отладчика, поскольку в определенный момент требуется пароль в виде открытого текста.

Answer 3

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

Код программного обеспечения для конфигурирования, а затем не пускайте своих разработчиков.

Answer 4

Вы можете сослаться на мой старый вопрос и ответы здесь. Как хранить пароли в приложении Winforms? . Но с нетерпением жду и других идей.

Answer 5

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

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

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

Это та же самая старая проблема: «Я не хочу, чтобы кто-то получал доступ к компьютеру», что можно сделать, только отключив компьютер от всего, сварив его в стальной коробке, выливая бетон на него и бросая его в глубину пространство.

Answer 6

Я перепробовал много методов, и я не думаю, что шифрование - это способ в этом случае. Вместо этого сохраните пароль в файле конфигурации, таком как web.config / app.config / etc, или в реестре Windows, или в файле / etc, или в любом другом месте, к которому у разработчиков нет доступа (в производственной среде). , но вы делаете.

Answer 7

Не уверен, что вам нужно ... если вы ищете способ жестко закодировать личный пароль, отклоните мой комментарий.

Но если вы ищете способ сохранить пароль ...

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

Answer 8

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

• Сохраните комбинацию имени пользователя и пароля в конфигурационный файл.
• Настройка промежуточного сервера с одним именем пользователя / паролем, сервера тестирования с другим и сервера продукта с еще одним именем пользователя / паролем.
• пароль в конфиге файл (который все программисты будут знаю) это для постановочного сервера. Имя пользователя / пароль, предоставленные тестовой группе, предназначены для тестового сервера.
• Убедитесь, что производственный / тестовый сервер имеет другое имя пользователя / пароль.
• Распространите файл конфигурации с правильное имя пользователя / пароль для продукта.

Answer 9

Полагаю, вы уже видели достаточно «нет» ответов. Я хотел бы отметить (не отвечая непосредственно на ваш вопрос), что аналогичная проблема была (почти) решена с помощью источников данных jdbc на серверах веб-приложений: это ресурсы, в основном фабрики соединений, которые предоставляют уже подключенную базу данных. соединения без приложения, чтобы беспокоиться о любой настройке соединения, включая имена и пароли. Соединение устанавливается сервером приложений, сервер приложений также считывает файл конфигурации и знает пароль.

Я не знаю словарного запаса для этого в других средах (или применимости), но, поскольку вы задали независимую от языка информацию, а я не отвечаю на ваши вопросы напрямую, я считаю, что можно ограничить пример только Java.

Если вы найдете / напишите аналогичную абстракцию, обеспечивающую ftp-соединение, вы можете помешать программистам с исходным кодом знать пароли (поскольку используются только объекты соединения, предоставляемые каким-либо «контейнером»). Это не поможет от прослушивания телефонных разговоров или отладки доступа к запущенному приложению.

Надеюсь, это поможет, даже если он не отвечает напрямую и не является строгим "да"; -)

Answer 10

просто чтобы бросить идеи вокруг:

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

ftp, кстати, небезопасен. вам понадобится sftp или ftps, чтобы избежать передачи открытого текста.