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

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

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

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

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

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

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

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

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

Надежда, которой это помогает, даже если она не отвечает непосредственно и не строга "да" ;-)

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

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

ftp между прочим не безопасен. u'll нужны sftp или ftps, чтобы не передавать открытый текст.

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

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

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

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

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

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

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

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

Кодируйте программное обеспечение, чтобы настраиваться и затем не пустить Ваш devs.

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

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

Шаги к надлежащему решению Вашей проблемы:

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

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

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

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

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