Você usa a mesma senha de root para todos os dispositivos?

Question

Isso está relacionado às Melhores práticas de senhas , mas mais específicas.

Você usa a mesma senha de root para todos os servidores da sua organização? Para dentro de uma classe de dispositivos?

    

Answer 1

Eu gostaria de dizer "sim, em todos os lugares", mas ainda é "não" em alguns casos. Minha empresa está usando Senha Segura para gerenciar senhas para nossos Clientes, criando "cofres" de acordo com o cliente. Muitos clientes têm senhas exclusivas atribuídas aleatoriamente para raiz, administrador local, dispositivos, etc. Infelizmente, algumas delas (seja devido ao trabalho feito por fornecedores anteriores ou por preguiça de nossa parte) podem ter a mesma senha usada em vários dispositivos ou em várias computadores servidores.

Para minhas senhas pessoais, fui intersetado para me mudar para um utilitário como o Passwordmaker , que usa uma "frase secreta mestre" e algum outro fato (nome do site, nome de usuário, etc) e cria uma senha aleatória a partir de uma função hash segura. Contanto que você saiba sua "senha mestra" e o "outro fato", você pode usar o software para regerar sua senha toda vez que precisar dela (ou seja, a senha nunca é armazenada em lugar algum, criptografada, texto simples ou qualquer outro). p>

Ainda não encontrei uma ferramenta de "segurança" de senha corporativa que faz tudo que eu quero:

• acesso baseado em SSL de navegadores como a interface do usuário
• Autenticação LDAP, permissões para acessar senhas no banco de dados com base na associação do grupo LDAP.
• Mantém uma trilha de auditoria das senhas acessadas por cada usuário (para que eu saiba o que mudar quando alguém sai da empresa).
• Notificações configuráveis para expiração de senha com base no usuário (isto é, "Expirar todas as senhas que 'bob' já usou desde que o demitimos"), com base no último conjunto de senhas de data ou com base no número de usuários únicos que acessaram o password ("Todo o helpdesk, o departamento de TI e a equipe de zeladoria acessaram essa senha-- expiram isso".)
• Metadados em cada senha, incluindo a parte a ser notificada por e-mail em caso de expiração, data de criação, data da última alteração, notas.
• Sistema de plug-in opcional para permitir que o próprio sistema de senha se conecte a sistemas e atualize senhas expiradas automaticamente.
• O ideal é ser executado em um servidor da Web baseado em Windows ou Linux, provavelmente usando o sqlite como back-end.

Eu estaria disposto a gastar dinheiro ou tempo de desenvolvimento em um projeto como esse, mas nunca encontrei nada que se aproximasse ou quisesse gastar tempo para tirá-lo do chão.

    

Answer 2

Eu uso chaves SSH, uso o mesmo para todos os servidores e mantenho uma boa senha no meu arquivo de chaves. Poupa muito agravamento.

Para dispositivos em que isso não funcionaria, eu usaria uma senha que tivesse um núcleo difícil de adivinhar e, em seguida, usasse o nome do dispositivo DNS, o IP ou outra característica comum (como SO ou marca) para Torne a senha exclusiva para o dispositivo. Isso funcionou especialmente bem para grupos de dispositivos semelhantes. Basta manter o padrão / segredo mnemônico, juntamente com o núcleo, e você tem uma senha difícil e exclusiva que era fácil de lembrar.

    

Answer 3

senha diferente para cada máquina, mas mantemos todas em um pwsafe. PITA para olhar para cima, mas impede uma brecha de nos ter pwnd.

    

Answer 4

Não, nunca. O que eu faço para ajudar mnemônicos é ter um longo prefixo comum (12 chars ou mais) que é modificado por um atributo de comprimento médio (6 caracteres) de cada servidor se eles estiverem no mesmo rack (ou o que você considerar um grupo de servidores , que deve ser determinado em uma necessidade de acesso à base (veja o comentário de Ernie e minha resposta)).

Por exemplo, se o grupo de servidores for composto por mercúrio (10.0.1.1, smtp), mars (10.0.1.2, firewall), bacchus (10.0.1.3, web) e o prefixo comum é R %% SDO23jfida, então

- mercury: R%%SDO23jfida11001mersmtp
- mars: R%%SDO23jfida21001marfirewall
- bacchus: R%%SDO23jfida31001bacweb

    

Answer 5

O usado na organização em que eu estava trabalhando:

A senha do computador / PC local é a mesma (mas como todas as nossas máquinas são fantasmas, essa é a única maneira de fazer isso, e se alguém encontrar essa senha, ainda poderemos alterar nossa imagem fantasma inicial, e atualize todas as máquinas para receber a nova imagem e ficaremos bem.

Cada servidor tem uma senha diferente. Então, novamente, nós não lidamos com muitos servidores, se bem me lembro sobre 6 que eu tinha acesso (mas tenho certeza que tínhamos mais), e em vez de fazer uma senha excessivamente complexa, eles optaram por simples, fáceis de lembrar senha, adicionando razoável | eet5peak para eles, e tornando-os realmente muito longos (mas, novamente, fácil de lembrar):)

Pessoalmente, acredito que para PCs desktop, você deseja manter a senha root / admin a mesma, garantindo o gerenciamento fácil usando a conta de administrador local.

Para servidores, é melhor ser diferente, para garantir que haja uma violação, ela está contida apenas no servidor e não vai além. Além disso, a complexidade da senha mudará dependendo da importância do servidor (ou seja, o servidor que mantém os usuários / senha na maior complexidade, o servidor que mantém os registros em menor complexidade, etc.).

Meu 5c

    

Answer 6

Nós usamos a mesma senha root em todos os lugares, embora siga as melhores práticas (geradas aleatoriamente, na verdade). É necessário apenas no caso em que temos que colocar as mãos fisicamente em uma máquina, por exemplo, para fazer uma verificação do sistema de arquivos ou perícia após um comprometimento. Como o Geoff, o ssh é o único protocolo de acesso remoto e está desativado para o usuário root.

    

Answer 7

Usamos uma senha longa retardada gerada aleatoriamente em cada caixa e nunca a salvamos em lugar algum. autenticação de usuário normal é gerenciada por meio de LDAP, como Sudoers, portanto, a única vez que NUNCA precisamos de uma senha é quando o acesso à rede não está funcionando, caso em que é totalmente aceitável baixar o servidor e ir para um único usuário , e traga de volta.

    

Answer 8

mercury: R%%SDO23jfida11001mersmtp
mars: R%%SDO23jfida21001marfirewall
bacchus: R%%SDO23jfida31001bacw

myc0mm0npa$$w0rd.105
myc0mm0npa$$w0rd.web

Eu vi muitas pessoas fazerem isso, mas ninguém poderia explicar como isso é mais seguro do que usar a mesma senha. O que impede alguém de ver uma das senhas de descobrir as outras? A única vantagem parece ser hashes diferentes, mas sais diferentes em máquinas diferentes resolvem isso também.

Alguém pode me esclarecer sobre isso?

    

Answer 9

Considerando que a senha é a última linha de defesa, eu diria que ela não é tão importante quanto antes.

No entanto, a última coisa que você precisa é de alguns yahoo em seu escritório correndo soltos, o que é muito mais comum.

Nossa política de senha é usar um prefixo comum difícil de adivinhar e usar uma senha comum para cada classe de servidor. Isso reduz o número de senhas que devo lembrar enquanto protejo outros servidores contra "erros". Diferentemente da Vinko, no entanto, não usamos nenhum sistema que integre qualquer coisa relacionada à máquina. Eu recomendaria contra isso, uma vez que uma vez que alguém dentro da organização tenha acesso a uma senha (porque eles precisam dela), eles podem descobrir as outras senhas facilmente.

Eu registro todos os logins do root e deixo o filtro de erros (verificar no meu caso) passar para o meu e-mail, para que eu saiba quando alguém está tentando decifrar a senha do root. Restrições de onde isso pode ser feito, garantem que meu e-mail não seja preenchido para transbordar com esses registros.

    

Answer 10

Eu notei que ninguém falou sobre a troca frequente de senhas. Sim, é uma dor ... em algum lugar, mas mais cedo ou mais tarde qualquer senha vazaria (alguém que desiste?). Eu acho que qualquer tipo de senha deve ser alterada após algum tempo, não importa o que você use como regra para construí-la. Nossa política é adivinhar uma senha totalmente aleatória a cada ano e, em seguida, proceder para alterá-la gradualmente em nossos dispositivos. A mudança gradual nos permite ter, ironicamente, um pouco mais de segurança, já que a qualquer momento nós não temos a mesma senha em todos os lugares (o que não é uma coisa boa) .

    

Answer 11

Não. Uma política no meu último trabalho era compartilhar uma senha gerada comum para dispositivos na mesma rede e adicionar um separador e alguns caracteres relacionados ao endereço IP ou ao tipo de dispositivo. Por exemplo:

myc0mm0npa$$w0rd.105
myc0mm0npa$$w0rd.web

Mas ainda é inseguro. O que eu faço agora é gerar uma senha de root diferente para cada servidor ou dispositivo.

    

Answer 12

Eu estou surpreso que ninguém mencionou isso ainda, mas eu estaria usando o ldap com kerberos para criar um único login que usaria chaves SSH para dispositivos específicos. Obviamente, isso pressupõe que os dispositivos que estou tentando conectar suportem a autenticação LDAP. Com o LDAP, posso criar grupos de usuários com acesso a dispositivos específicos. Além disso, todos os meus usuários estão efetuando login por meio de um servidor kerberos centralizado, portanto, os logins só podem acontecer localmente e eu posso revogar imediatamente uma conta caso ela seja comprometida por algum motivo.

Se você tiver senhas ou chaves em mais de 100 máquinas, divirta-se alterando todas essas senhas ou arquivos authorized_keys. Eu não tenho que me preocupar com isso.

    

Answer 13

Usar a mesma senha de root para mais de uma conta ou dispositivo é uma má ideia. Isso nunca se sustentará em uma auditoria de TI, já que não há responsabilidade. Uma vez que alguém tenha a senha, eles podem acessar várias contas e você não pode provar quem fez ou não fez alguma coisa. Eu tenho visto algumas vezes pessoas tentando trazer responsabilidade através do registro de endereços IP, mas isso é complicado e fácil de hackear.

Para trazer responsabilidade e passar SOX, PCI, HIPAA, etc., você precisa limitar o acesso a contas genéricas a uma única pessoa por vez, rastrear o que é acessado e depois alterar a senha quando elas forem concluídas.