Pergunta

No meu script de rubi, preciso passar o nome de usuário e

  • Senha como um texto simples em um formulário para fazer login. O nome de usuário e a senha estão atualmente armazenados no meu script.

  • Eu tenho nenhum controle sobre o servidor, faço login no script. O script é local funcionando bem e no futuro eu quero passar para o meu

  • Provedor de hosts da web e execute -o a partir daí (eu tenho acesso ssh)

  • Usando Cron. Existe alguma maneira/método como

  • proteger a senha Caso alguém tenha acesso a esse script por acaso?

Foi útil?

Solução

Quanto mais penso sobre isso, mais acho que você deve confiar no seu serviço de hospedagem. Eu garantiria que o serviço de hospedagem tenha "Skin in the Game": isto é, que eles hospedem contas de "alto perfil" suficientes que ser encontrado não confiável seria muito caro para eles (em contas e vendas perdidas).

E se você acha que o serviço de hospedagem é ou não confiável, você deve ter um plano para o caso de a conta de destino estar comprometida. Quem você notificará, como você obterá essa conta desativada, etc.

A única solução tecnológica em que consigo pensar-você faz login manualmente, capturar o cookie e fornecer esse cookie ao script-fornece a senha, mas presumivelmente um host hostil poderia usar esse cookie para causar qualquer dano que ele quisesse no alvo Sistema usando quaisquer privilégios anexados a esse cookie, incluindo a alteração de sua senha. Portanto, não há nenhuma solução.

Ah, por falar em privilégios: a tarefa que você precisa automatizar pode ser realizada com uma conta de destino que reduz os privilégios, como uma conta somente leitura ou que não pode fazer alterações em seu perfil? Ter apenas suas credenciais de baixa privilégio no serviço de hospedagem reduziria seu risco (ou "exposição", como a multidão polissilábica gosta de dizer).

Resposta anterior, considerada impraticável, abaixo da linha.


Você pode criptografar o ID do usuário e a senha usando mais uma senha. Para executar, o script deve ser fornecido com Está senha. Ele usa essa senha para descriptografar o nome de usuário e a senha do serviço da web. Certifique -se de que a senha do script não seja armazenada em nenhum lugar, mas apenas mantida na memória e apenas por tempo suficiente para descriptografar o melhor ID do usuário e senha.

Se isso realmente importa, verifique se sua conexão para executar o script é criptografia (ssh, ssl etc.) e verifique se o script usa apenas o HTTPS para fazer logon.

Isso não o torna invulnerável a alguém com privilégios de raiz na caixa (em algum momento, o User-ID e a senha do texto simples estarão na memória e, portanto, vulneráveis), mas faz com que seja necessário mais trabalho para que eles possam ser capazes Para obter o usuário-ID/senha.

Atualizada: O requisito de que isso seja automatizado torna a solução acima não boa.

Outras dicas

Se um script automatizado precisar executar algo com uma senha, você precisará fazer com que ela seja legível pelo script (que abre a possibilidade de outra pessoa lê -lo) ou então não o forneça na automação.

O truque é ignorar a parte da "automação" com uma startup única: execute o script como um pequeno processo contínuo que acordará periodicamente e executará. Peça ao processo que peça a senha na inicialização ou através de outro tipo de solicitação de API (não na linha de comando!).

Se o servidor reiniciar, a senha será perdida até você fazer login e inserir a senha novamente. Dessa forma, a senha está apenas na memória, não no sistema de arquivos.

Você pode querer que um trabalho cron verifique o processo e alertá -lo se não estiver em execução.

Se você precisar passar a senha para um formulário que presumivelmente não pode alterar para usar um esquema mais seguro, há pouco que você pode fazer além de ofuscar a senha para que não seja óbvia imediatamente. No entanto, qualquer pessoa com acesso ao próprio script pode simplesmente descobrir onde é passado para o formulário e inserir um comando para imprimir a senha lá - ela precisa ser "descriptografada" naquele momento para você transmitir, não importa o que .

Para protegê-lo de não programadores, você poderia xorá-lo com algo ou girar as letras por alguma quantidade, mas eu não gastaria muito tempo com isso, pois será inútil contra praticamente qualquer pessoa com um entendimento rudimentar da programação. Em vez disso, proteja o script de outros usuários (defina os direitos de acesso a arquivos corretamente, não o coloque em um diretório visível da Web, etc.). E se você não confia na administração do servidor, não o faça o upload lá!

Você deve armazenar uma versão de hash da senha no seu banco de dados. Um hash é uma criptografia única, por isso é impossível usar a lógica para adivinhar a senha da senha de hash.

Crie um método para hash a senha e fazer algo assim:

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

Quando você obtém a senha de texto simples do formulário, você o passa para o seu valid_password? método. Isso fará a mesma criptografia unidirecional que a senha foi armazenada. Portanto, as senhas criptografadas de uma maneira são comparadas. Isso significa que você nunca armazena uma referência à senha real em qualquer lugar, o que é uma grande vitória.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top