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

Question

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

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

EDIT: Я знаю, что FTP не защищен. В идеале, мне нужна техника, которая будет работать в любой ситуации, когда требуется имя пользователя и пароль (например, соединение с базой данных).

Answer 1

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

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

Edit - подробнее:

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

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

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

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

Answer 2

Вы можете сослаться на мой старый вопрос и ответы здесь. How to store passwords in Winforms application?. Но, с нетерпением жду некоторых других идей.

Answer 3

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

Answer 4

Нет, это не возможно сделать безопасно. ftp в любом случае не является безопасным протоколом, поэтому людям не нужен исходный код, чтобы видеть ваше имя пользователя и пароль, только сниффер локальной сети. Вы можете избежать этой проблемы, используя туннелирование ssh, но если вы отправляете исходный код, всегда будет тривиально для людей с доступом к нему, чтобы получить от него имя пользователя и пароль. Даже без источника и даже с защищенным протоколом выделенный злоумышленник с дизассемблером/отладчиком и некоторое свободное время все равно сможет получить эту информацию из исполняемого файла. Если имя пользователя и пароль должны быть безопасными, не включайте его в код, даже если он запутан!

Answer 5

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

Answer 6

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

Answer 7

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

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

Answer 8

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

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

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

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

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

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

Answer 9

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

Как говорится, вы можете поместить зашифрованный пароль в файл конфигурации, который читается во время выполнения. Пусть разработчики подключаются к другому ftp (или с другой учетной записью, которая позже удаляется), и поместите зашифрованный пароль, который вы хотите защитить в конфигурационном файле при развертывании приложения.

Answer 10

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

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

Answer 11

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

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

FTP кстати не является безопасным. u'll нужно SFTP или FTPS, чтобы избежать передачи открытым текстом.

Answer 12

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

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

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

Надеется, что это не помогает, даже если он не отвечает прямо и нет строгого «да» ;-)

Answer 13

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

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

Answer 14

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

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

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

Answer 15

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

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

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

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