Предотвращать программистам знание паролей, используемых во время выполнения

Ответ 1

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

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

Изменить - подробнее:

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

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

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

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

Ответ 2

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

Ответ 3

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

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

Ответ 4

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

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

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

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

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

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

Ответ 5

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

Ответ 6

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

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

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

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

Ответ 7

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

Ответ 8

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

Ответ 9

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

Ответ 10

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

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

Ответ 11

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

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

Ответ 12

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

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

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

Ответ 13

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

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

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

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

Ответ 14

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

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

Ответ 15

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

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

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