Безопасно используя пароль в качестве аргумента bash

Question

Я извлекаю часть веб-приложения, которая обрабатывает регистрацию, другая часть будет переписана.

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

Проблема заключается в том, что некоторые конфиденциальные данные, в частности пароль администратора новой учетной записи, будут передаваться через bash.

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

Это будет на том же частном сервере, поэтому риск кажется минимальным, но я не хочу рисковать.

Спасибо.

Answer 1

Со справочной страницы bash:

HISTIGNORE Разделенный двоеточиями список шаблонов, используемых для определения того, какой команда строки должны быть сохранены в списке истории. Каждый шаблон является закреплен в начале строки и должен совпадать ком- полная строка (не добавлено неявное ‘*’). Каждый шаблон является проверяется по линии после проверок, указанных HISTCONTROL прилагаются. В дополнение к нормальной оболочке шаблон совпадающие символы, ‘&’ соответствует предыдущей строке истории. «&» может быть экранирован с помощью обратной косой черты; обратная косая черта удален перед попыткой матча. Второй и последующие линии составная многострочная команда не тестируется и добавляется к история независимо от значения HISTIGNORE.

Или, основываясь на вашем комментарии, вы можете сохранить пароль в защищенном файле, а затем прочитать его.

Answer 2

Используйте переменную среды $ HISTFILE, отмените ее (это для всех пользователей):

echo "unset HISTFILE" >> /etc/profile

Затем установите ее снова.

Дополнительная информация о переменной $ HISTFILE здесь: http://linux.about.com/cs/linux101/g/histfileenviron.htm

Надеюсь, это поможет!

Answer 3

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

#!/bin/bash
echo "-- shopt --"
    shopt | grep -i hist
echo "-- set --"
    set -o | grep -i hist
echo "--vars --"
    for v in ${!HIST*}
    do
        echo "$v=${!v}"
    done

Запустите это так:

$ ./histshow

и сравните вывод с полученным из него следующим образом:

$ . ./histshow

В первом случае обратите внимание, что HISTFILE не установлен и что опция set history равна off. Во втором случае поиск сценария запускает его в интерактивном сеансе и показывает ваши настройки.

Мне удалось заставить скрипт хранить историю в памяти, выполнив set -o history внутри скрипта, и записать его историю в файл, также задав HISTFILE, а затем выполнив явное history -w.

Answer 4

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

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

ЧтоВы могли бы передать конфиденциальную информацию через файл, не забудьте установить umask на очень строгие настройки перед созданием файла.