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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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? методу. При этом будет выполнено такое же одностороннее шифрование, как и при сохранении пароля. Таким образом, сравниваются односторонние зашифрованные пароли. Это означает, что вы никогда нигде не сохраняете ссылку на фактический пароль, что является большим преимуществом.