Se você não quiser sua senha no histórico do shell (ou facilmente pesquisada em ps ), então não coloque a senha na linha de comando .
Uma alternativa é colocar a senha em um arquivo, definir as permissões para 600 com chmod e usar $(cat passwordfile) no lugar da senha na linha de comando.
Isso não é seguro se você não confiar na raiz do sistema ou se achar que outros usuários do sistema podem adquirir privilégios de administrador.
por exemplo,
- edite
/.mysecretpassworde adicione sua senha. -
chmod 600 ~/.mysecretpassword -
executar:
echo "thisismydatastring and my saltbits" | openssl aes-256-cbc -k "$(cat ~/.mysecretpassword)" -base64
Da mesma forma, se "thisismydatastring and my saltbits" for sensível, não coloque isso na linha de comando. coloque-o em um arquivo e canalize-o em openssl .
openssl tem uma opção para ler a senha de um descritor de arquivo. Isso é útil principalmente se você escrever um script wrapper para executar o openssl.
#!/bin/bash
# use file descriptor 99 for no particular reason. a completely arbitrary choice,
# as long as it's not already in use (probably isn't).
exec 99< ~/.mysecretpassword
openssl aes-256-cbc -base64 -k fd:99
Salve isso em algum lugar em seu $ PATH, torne-o executável com chmod (700 é provavelmente o melhor se você estiver preocupado com bisbilhoteiros) e você pode canalizar ou redirecionar seus dados para ele. É provavelmente um pouco melhor que o método $(cat ...) porque não nomeia ~/.mysecretpassword em qualquer linha de comando (para que não seja salvo no histórico ou visível em ps ).
Esse método de descritor de arquivo ainda é apenas segurança por obscuridade, portanto, não é seguro contra uma conta raiz não confiável ou usuários que podem obter raiz.
Você pode melhorar um pouco a segurança usando um sistema de arquivos criptografado que você monta manualmente (e digite a senha manualmente ... e espere que ninguém esteja registrando as teclas digitadas) quando precisar, e desmonte quando terminar. Applescript implica que você está usando um Mac - não sei como você faria isso no OS X, mas no Linux, você usaria o FUSE se não tivesse raiz na máquina.
Geralmente, é considerado uma má idéia estar fazendo coisas criptografadas em uma máquina que você não controla completamente, ou que tem outros usuários (potencialmente hostis) nela. (para criptografia mais segura, não faça isso em uma máquina conectada a uma rede ... melhor ainda, use uma máquina sem rede em uma gaiola de faraday em uma sala revestida de chumbo na parte inferior de um bunker de concreto de 100 'de profundidade transferir os dados criptografados em base64 por disquete - não por um dispositivo USB - ou por código QR ... impresso ou exibir o QR na tela e digitalizar com o telefone)
Mais simples: se você tiver algum motivo para suspeitar que não pode confiar totalmente na máquina em que está, e é importante que os dados permaneçam em segredo, não os use para criptografia. Há muitas maneiras de cometer um erro, e é preciso apenas um para ser completamente comprometido.
BTW, se você estiver usando bash , poderá remover linhas individuais do ~/.bash_history antes de sair desse shell ao clicar na seta para cima até ver a linha que deseja remover e depois digitando Ctrl-U e pressionando a seta para cima novamente.
Como alternativa, você pode limpar todo o histórico da sessão do shell executando history -c antes de sair desse shell. Isso não limpará nada que já tenha sido salvo no arquivo .bash_history.
Se a senha ou outros dados confidenciais já estiverem salvos em sua .bash_history, sua única opção será excluir ou editar seu arquivo de histórico quando você fizer o login novamente. NOTA: Já pode ser feito backup ou snapshot - ou seja, é tarde demais para corrigir.