Какой наименее небезопасный способ хранения пароля, который используется сценарием?

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

Какие меры предосторожности следует предпринять, чтобы наиболее безопасно хранить эти учетные данные, при этом оставляя доступ к сценарию?

Уточнения:

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

— ændrük
источник

не храните парольную часть учетных данных, возможно?

— Томас Уорд

Разве это не работает для доступа к GNOME Keyring или что-то подобное?

— Firefeather

Возможно, если бы вы могли хранить его как криптографический хеш (такой как SHA-1), это было бы неплохо.

— Аноним

ROT13 затеняет его, но никак не защитит.

— Аноним

@ Аноним Если пароль хранится в виде криптографического хэша, как вы порекомендуете его восстановить?

— rndrük

Ответы:

Какой сервис? Некоторые службы имеют другие методы аутентификации, например, ключи SSH для SSH в сочетании с агентом SSH.

Я бы хранил пароль отдельно от сценария и следил за тем, чтобы у всех компонентов пути были установлены правильные разрешения. Например, убедитесь , что на пути /path/to/file, /, /pathи /path/toпринадлежат пользователю , которому вы доверяете ( root) , и что они не доступны для записи кем - то , кто не имеет права видеть файлы. Наконец, рекомендуемые разрешения для file600 или 400.

Это fileможет выглядеть так:

PASSWORD='something that you cannot remember'

В своем скрипте используйте следующий код для импорта переменной:

. /path/to/file

Что касается вашего сценария, убедитесь, что он не содержит дыр, которые могут позволить злоумышленникам выполнить код в контексте сценария (например, неконтролируемая среда, в которой может быть установлен произвольный $PATHнабор переменных или недопустимое использование других файлов (например, получение доступного для записи файла) ,

Что касается фактической защиты вашего пароля, вы не можете. Он должен быть доступен как-то для другой службы. В качестве альтернативы, вы можете зашифровать файл / скрипт, содержащий пароль, opensslили gpgвам нужно ввести пароль, прежде чем учетные данные будут разблокированы. Это особенно полезно, если пароль вашей службы трудно запомнить.

— Lekensteyn
источник

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

Получите пароль cat /dir/to/file/with/.passwordвместо того, чтобы читать файл и сохранять его содержимое в переменной.

— Rinzwind
источник

Некоторые инструменты даже имеют возможность считывать пароль из файла напрямую по этой причине, например, в gpg --passphrase-file.

... и сделайте его .dotfile (/dir/to/file/with/.password)

— knb

chmod 400для файлов (только для чтения). Конечно, вы должны обеспечить ведущие каталоги (700 или 500, или даже 100, если вы параноик). Обратите внимание, что 400 (или 500 для каталогов) достаточно, другие режимы (100) можно рассматривать как защиту от неясности , так же, как скрытие файла, поставив точку перед именем.

— Лекенштейн

Я знаю, что это старый вопрос, но я столкнулся с подобной проблемой, и я использовал брелок Ubuntu, чтобы решить ее. Вот решение для Ubuntu 18.04LTS Откройте терминал Запишите, keyring set {{service}} {{username}} например, если вы используете это для регистрации школьных паролей:

keyring set school mohamed

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

Чтобы получить этот пароль, напишите в терминале:

keyring get school mohamed

использовать это в контексте сценария:

password=$(keyring get school mohamed)

Теперь пароль содержит пароль, который вы ввели ранее.

— Мохамед Ашреф
источник