Как защитить текстовый пароль в моем скрипте? (Рубин)

Question

в моем скрипте ruby ​​мне нужно передать имя пользователя и

• пароль в виде простого текста в форме для входа в систему. И имя пользователя, и пароль в настоящее время хранятся в моем скрипте.

• У меня нет контроля над сервером, на котором я вхожу из скрипта. Сценарий локально работает нормально, и в будущем я хочу перейти на мой

• провайдер веб-хостинга и запустите его оттуда (у меня есть доступ по ssh)

• с использованием cron . Есть ли способ / способ как

• защитить пароль на случай, если кто-нибудь получит доступ к этому сценарию случайно?

Answer 1

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

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

Answer 2

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

Хитрость заключается в том, чтобы обойти часть «Автоматизация» путем однократного запуска: запустить сценарий как небольшой непрерывный процесс, который периодически просыпается и запускается.Пусть процесс запрашивает пароль при запуске или через какой-либо другой API-запрос (не в командной строке!).

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

Возможно, вы захотите, чтобы задание cron проверило процесс и предупредило вас, если оно не запущено.

Answer 3

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

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

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

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

Предыдущий ответ, признанный неработоспособным, ниже черты.

---

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

Если это действительно имеет значение, убедитесь, что ваше соединение для запуска скрипта крипто (ssh, ssl и т. Д.), И убедитесь, что скрипт использует только https для входа в систему.

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

Обновлено : Требование, чтобы это было автоматизировано, делает вышеуказанное решение бесполезным.

Answer 4

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

Создайте метод для хэширования пароля и сделайте что-то вроде этого:

require "digest/sha1"
class User
  attr_accessor :password

  def initialize(password)
    @password = hash_password(password)
  end

  def hash_password(password)
    Digest::SHA1.hexdigest(password)
  end

  def valid_password?(password)
    @password == hash_password(password)
  end
end

u = User.new("12345")
p u.password # => "8cb2237d0679ca88db6464eac60da96345513964"
p u.valid_password?("not valid") # => false
p u.valid_password?("12345") # => true

Когда вы получаете простой текстовый пароль из формы, вы передаете его вашему valid_password? методу. При этом будет выполнено то же одностороннее шифрование, что и при сохранении пароля. Таким образом, один способ шифрования паролей сравнивается. Это означает, что вы нигде не сохраняете ссылку на фактический пароль, что является большим выигрышем.