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

Question

в моем рубинового сценарии мне нужно передать имя пользователя и

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

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

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

• используя хроны. Есть ли способ/метод, как

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

Answer 1

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

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

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

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

Предварительный ответ, найденный неработоспособным, под линией.

---

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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