#python #linux #security #passwords #openssl
#python #linux #Безопасность #пароли #openssl
Вопрос:
Я реализовал HTTP-сервер (CherryPy и Python), который получает зашифрованный файл от клиента (Android). Я использую OpenSSL для расшифровки загруженного файла. В настоящее время я использую openssl -enc -pass file:password.txt -in encryptedfile -out decryptedfile для выполнения расшифровки на стороне сервера. Как вы можете видеть, пароль, используемый openssl, хранится в обычном текстовом файле (password.txt ).
Есть ли более безопасный способ сохранить этот пароль OpenSSL?
Спасибо.
Ответ №1:
Передайте его через более высокий FD и используйте этот FD в командной строке. Обратите внимание, что вам нужно будет использовать preexec_fn аргумент для настройки FD перед запуском процесса.
subprocess.Popen(['openssl', ..., 'file:/dev/fd/12', ...], ...,
preexec_fn=passtofd12(password), ...)
Комментарии:
1. Спасибо. Не могли бы вы, пожалуйста, объяснить, почему использование файлового дескриптора (FD) в этом случае более безопасно?
2. Поскольку вам не нужен временный файл для хранения пароля; процесс Python может внедрить его непосредственно в процесс openssl.
3. Не могли бы вы добавить еще несколько деталей к этому решению?
Ответ №2:
В целях конфиденциальности пользователя и по другим причинам пароли обычно не хранятся на серверах. Обычно пользователи выбирают пароль, который хранится в виде какого-либо хэша на сервере.
Затем пользователи проходят аутентификацию в веб-приложении, сверяя сохраненный хэш с хэшем, предоставленным на основе пользовательского ввода. После аутентификации клиента предоставляется идентификатор сеанса, позволяющий использовать серверные ресурсы. В течение этого времени пользователь может, например, загрузить файл. Шифрование файла на сервере не должно быть необходимым при условии, что хостинг-сервер защищен должным образом и отсутствуют другие проблемы.
В этом случае механизм аутентификации не прояснен, равно как и угрозы, которые представляют опасность, или жизненный цикл этого загруженного файла.
Кажется, что сервер получает зашифрованный файл, плюс некоторый тип пароля. Рассматривается ли защита пароля на этапе передачи или в качестве хранилища на сервере? Протокол HTTPS может помочь защитить от угроз, связанных с передачей файла / данных. Как я вижу из вашего описания, проблема, по-видимому, заключается в хранилище на стороне сервера.
Шифрование паролей после их получения сервером (либо по отдельности, либо с использованием мастер-пароля) добавляет еще один уровень безопасности, но этот подход не лишен недостатков, поскольку парольная фраза либо (1) должна храниться на сервере в виде открытого текста для доступа к файлам (2), либо должна вводиться администратором вручную, когда это необходимо, как часть любой обработки, требующей пароля — обратите внимание, что любые ресурсы, зашифрованные паролем, становятся непригодными для использования пользователями.
Хотя я не совсем понимаю, что происходит, самым безопасным решением было бы переработать веб-приложение и тщательно продумать дизайн и его требования.
Комментарии:
1. У меня есть зашифрованный файл на устройстве Android, который я хочу загрузить на сервер. Передача файла выполняется с использованием HTTP, а не HTTPS, поскольку файл большой и, следовательно, зашифрован в автономном режиме (для экономии заряда батареи и процессора). Клиент может не знать ключ шифрования. Как вы сказали, я могу предположить, что сервер «защищен» и хранить ключ в виде обычного текста на сервере или, возможно, клиент отправляет пароль по защищенному соединению (HTTPS). Сервер может сопоставить хэш SHA1 с хэшем пароля, а затем зашифровать файл с помощью пароля.
2. @Soumya Simanta: Имейте в виду, что HTTP-соединения более подвержены атакам MITM, чем HTTPS. Рассмотрите возможность передачи дайджеста сообщения для файла вместе с паролем по протоколу HTTPS и передачи файла по протоколу HTTP. Однако я бы все делал по протоколу HTTPS. Разница кажется номинальной, поскольку в обоих подходах выполняются одинаковые операции. HTTPS, вероятно, быстрее, потому что и передача, и шифрование выполняются параллельно, по сравнению с необходимостью шифровать весь файл перед его отправкой по сети. Сервер также экономит ресурсы, не прибегая к расшифровке.