O que você faria se percebesse que seu provedor de hospedagem de e-mail poderia ver suas senhas?

Question

Recebemos um e-mail no ano passado do nosso provedor de hospedagem em relação a uma de nossas contas. Ele foi comprometido e usado para fornecer uma ajuda bastante generosa de spam.

Aparentemente, o usuário redefiniu sua senha para uma variação do nome dela (o sobrenome é algo que você provavelmente poderia adivinhar na primeira vez.) Ela foi hackeada dentro de uma semana e sua conta enviou uma enxurrada de 270.000 e-mails de spam foi bloqueado muito rapidamente.

Até agora, nada particularmente incomum. Isso acontece. Você muda suas senhas para algo mais seguro, educa o usuário e segue em frente.

No entanto, algo me preocupou ainda mais do que o fato de uma de nossas contas ter sido comprometida.

Nosso provedor de hospedagem, em um esforço para ser útil, na verdade citou a senha para nós no seguinte e-mail:

Estou espantado. Devemos renovar nosso contrato em breve e isso parece um problema.

Quão comum é para um provedor de hospedagem descobrir a senha real usada em uma conta?

A maioria dos provedores de hospedagem tem um departamento de abuso de conta que tem mais acesso do que representantes de linha de frente (e pode procurar senhas se necessário) ou esses caras não estão seguindo as práticas recomendadas para tornar possível qualquer de sua equipe para acessar senhas de usuários? Eu achava que as senhas deveriam ser criptografadas e não recuperáveis? Isso significa que eles armazenam as senhas de todos em texto simples?

É ainda legal que um provedor de hospedagem possa descobrir senhas de contas dessa maneira? Parece tão incrível para mim.

Antes de analisarmos a mudança de provedor, eu gostaria de ter certeza de que isso não é uma prática comum, e que nosso próximo provedor de hospedagem também provavelmente não teria as coisas configuradas da mesma maneira.

Estamos ansiosos para ouvir suas opiniões sobre isso.

    

Answer 1

Sim, é comum que os provedores de serviços de e-mail e de e-mail armazenem sua senha em texto simples ou um formato facilmente recuperável para texto sem formatação.

A razão para isso tem a ver com os protocolos de autenticação usados com PPP (discada e DSL), RADIUS (dial-up, 802.1x, etc.) e POP (email), entre outros.

A desvantagem aqui é que, se as senhas são unidirecionais no banco de dados do ISP, os únicos protocolos de autenticação que podem ser usados são aqueles que transmitem a senha pela rede em texto sem formatação. Mas se o ISP armazenar a senha real, então protocolos de autenticação mais seguros podem ser usados.

Por exemplo, a autenticação PPP ou RADIUS pode usar o CHAP, que protege os dados de autenticação em trânsito, mas exige que uma senha de texto simples seja armazenada pelo ISP. Da mesma forma com a extensão APOP para POP3.

Além disso, todos os vários serviços que um provedor oferece oferecem protocolos diferentes, e a única maneira limpa de autenticá-los no mesmo banco de dados é manter a senha em texto simples.

Isso não aborda as questões de quem entre a equipe do ISP tem acesso ao banco de dados , e quão bem ele está seguro , no entanto. Você ainda deve fazer perguntas difíceis sobre isso.

Como você provavelmente já aprendeu, é quase inaudito que o banco de dados de um ISP seja comprometido, embora seja muito comum que usuários individuais sejam comprometidos. Você tem risco de qualquer maneira.

Veja também Estou errado em acreditar que as senhas nunca devem ser recuperáveis (uma forma de hash)? em nosso site irmão Segurança de TI

    

Answer 2

Isso é, infelizmente, bastante comum com hosts de orçamento e não é inédito, mesmo com hosts maiores. Coisas como o cpanel freqüentemente precisam de sua senha de texto simples para poder efetuar login em vários serviços como você, etc.

A única coisa que você pode fazer é perguntar antecipadamente se as senhas estão com hash.

    

Answer 3

Eles provavelmente armazenam senhas em texto simples ou usam algum tipo de criptografia reversível.

Como você supôs, isso é muito ruim.

Por causa da má-vontade ou negligência dos funcionários ou de um comprometimento de seus sistemas por uma parte externa, as senhas de texto simples sendo mal utilizadas criam um sério risco - não apenas para seus sistemas, mas para outros sistemas as pessoas podem ter usado a mesma senha em.

Armazenamento responsável de senhas significa o uso de funções de hashing unidirecionais em vez de criptografia reversível, com um sal (dados aleatórios) adicionados à entrada do usuário para evitar o uso de tabelas de arco-íris .

Se eu estivesse no seu lugar, eu faria ao provedor algumas perguntas difíceis sobre como, exatamente, eles armazenam senhas e como, exatamente, o representante do suporte conseguiu recuperar a senha. Isso pode não significar que eles armazenam as senhas em texto simples, mas talvez estejam registrando-as em algum lugar quando alteradas - também um grande risco.

    

Answer 4

Todas as outras respostas são ótimas e têm pontos históricos muito bons.

No entanto, vivemos na era em que o armazenamento de senhas em texto simples causa enormes problemas financeiros e pode destruir completamente as empresas. Enviar senhas em texto simples via e-mail inseguro também parece ridículo na era da NSA, sugando todos os dados de passagem.

Você não precisa aceitar o fato de que alguns protocolos antigos exigem senhas em texto simples. Se todos nós parássemos de aceitar tais serviços, provavelmente os provedores de serviço fariam algo a respeito e, finalmente, desaprovariam a tecnologia antiga.

Algumas pessoas podem lembrar que uma vez, quando você quer embarcar em um avião para outro país, você literalmente entra no avião do estacionamento da rua. Nenhuma segurança que assim sempre. Hoje em dia, as pessoas perceberam que são necessárias medidas de segurança apropriadas e que todos os aeroportos as implementaram.

Eu mudaria para outro provedor de e-mail. A pesquisa no "provedor de e-mail seguro" gera muitos resultados.

Houve alguns pontos positivos nos comentários. Provavelmente, procurar por "provedor de e-mail seguro" faria muito sentido, pois todos os provedores de e-mail se gabariam de que são seguros. No entanto, não posso recomendar uma empresa em particular e provavelmente não é uma boa ideia fazer isso. Se você identificar uma determinada empresa fazendo perguntas difíceis sobre segurança, será uma boa coisa para fazer.

    

Answer 5

Minha recomendação é sair e perguntar aos próximos caras quais são as políticas deles primeiro!
Se você está se sentindo bem, você pode dizer aos provedores antigos por que você está indo embora.

Também para endereçar a declaração de outra resposta, os dias das tabelas do arco-íris já passaram. Eles foram substituídos por GPUs de alta potência e ocupam muito espaço de armazenamento (hashes binários obviamente não compactam bem; e você não os armazenaria em ASCII de qualquer maneira). É mais rápido (re) calcular o hash em uma GPU do que lê-lo no disco.

Dependendo do algoritmo de hash usado e da GPU, espera-se que um computador moderno de cracking de senhas passe de 100 a um bilhão de hashes por segundo. De acordo com este (que é um pouco datado sobre o que ele acha que um computador / supercomputador pode fazer), significa que qualquer senha de 6 caracteres pode ser quebrada em segundos. Tabelas para 7 & 8 hashes de caracteres em todos os vários algoritmos (MD5, SHA-1, SHA-256, SHA-512, Blowfish, etc.) consumiriam quantidades excessivas de espaço em disco (você precisa armazená-los em um SSD, não em um disco magnético). platter, para velocidade de acesso) e você pode ver porque os ataques baseados em dicionário usando a GPU renderão senhas mais rapidamente.

Um bom artigo para quem entra em cena é Como me tornei um cracker de senha na Ars Technica.

    

Answer 6

Isso aconteceu comigo!

Alguns anos atrás, minha identidade foi comprometida quando meu provedor de hospedagem (que também era meu provedor de e-mail na época) sofreu uma violação de segurança. Acordei por não poder verificar meu e-mail porque minha senha foi redefinida. Com o controle do meu e-mail, eles tentaram redefinir minha senha na Amazon e no PayPal. Você pode adivinhar o que veio a seguir, certo? Cobranças de cartão de crédito fraudulentas!

Felizmente, consegui descobrir o que estava acontecendo com relativa rapidez, obter meu provedor de hospedagem por telefone e validar minha identidade cuidadosamente, apesar das informações sobre a conta e das questões de segurança estarem sendo alteradas (tudo em poucas horas). Durante esta conversa, o representante do atendimento ao cliente foi capaz de me informar meu histórico de senha, quando foi alterado e para quê. Isso era tudo que eu precisava ouvir para saber que precisava absolutamente mudar de fornecedor.

Não há nenhuma razão que aconteça com você, nossa empresa!

Eu tinha minhas suspeitas sobre o rigor desta empresa quando se tratava de segurança, coisas que eu tinha notado aqui e ali ao longo dos meus anos de lidar com eles. Mas eu sempre me convenci de que não era grande coisa ou talvez estivesse enganado. Eu não estava enganado, e você também não é!

Se eu tivesse agido quando suspeitei que eles não levariam a segurança a sério, todo esse mini-pesadelo nunca teria acontecido. Pensar o que poderia ocorrer no caso de uma conta corporativa valiosa ser comprometida? Você ficaria fácil se eles apenas enviassem SPAM. A empresa em que eu estava trabalhando na época também estava usando esse provedor e fizemos da nossa prioridade a transição o mais rápido possível.

Confie em seus instintos! Não passe a responsabilidade de migrar da preguiça ou porque sua configuração existente "funciona bem". A parte mais contundente dos descuidos da segurança, como o armazenamento de senhas em texto claro, configuração inadequada de servidores, etc., é que eles falam de uma incompetência geral e / ou preguiça em sua cultura técnica, e essa é uma cultura que eu não gostaria que a missão da minha empresa contrato de serviço em qualquer lugar próximo.

    

Answer 7

Eu posso ver uma explicação alternativa, em que Sua senha é realmente codificada nos servidores do seu provedor.

Como o provedor entrou em contato com Você apenas um dia depois, ele provavelmente (e isso é uma suposição) o extraiu dos logs do servidor, pois seu script de mudança de senha está enviando dados por meio do método GET.

Soa mais simples do que o seu provedor ter banco de dados cheio de registros de quando, quem e como mudou sua senha. Você sabe Navalha de Occam ...;)