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

No ano passado, recebemos um e-mail do nosso provedor de hospedagem referente a uma de nossas contas - ela havia sido comprometida e usada para fornecer uma porção bastante generosa de spam.

Aparentemente, o usuário redefiniu sua senha para uma variação de seu nome (o sobrenome é algo que você provavelmente poderia adivinhar pela primeira vez). bloqueado.

Até agora, nada de incomum. Isso acontece. Você altera 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 email:

Estou surpreso. Devemos renovar nosso contrato em breve - e isso parece um desastre.

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

A maioria dos provedores de hospedagem possui um departamento de abuso de conta que tem mais acesso do que os representantes da linha de frente (e pode procurar senhas, se necessário), ou esses funcionários simplesmente não seguem as práticas recomendadas para possibilitar que qualquer uma das suas equipes acesse o usuário senhas? Eu pensei que as senhas deveriam ser hash e não recuperáveis? Isso significa que eles armazenam as senhas de todos em texto simples?

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

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

Ansioso para ouvir suas opiniões sobre isso.

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

O motivo disso está relacionado aos protocolos de autenticação usados ​​com PPP (discagem e DSL), RADIUS (discagem, 802.1x etc.) e POP (email), entre outros.

A desvantagem aqui é que, se as senhas tiverem um hash unidirecional no banco de dados do ISP, os únicos protocolos de autenticação que podem ser usados ​​são aqueles que transmitem a senha pela conexão em texto sem formatação. Mas se o ISP armazena a senha real, 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 sem formatação seja armazenada pelo ISP. Da mesma forma com a extensão APOP para POP3.

Além disso, todos os vários serviços oferecidos por um ISP usam protocolos diferentes, e a única maneira limpa de autenticar todos eles no mesmo banco de dados é manter a senha em texto sem formatação.

Isso não aborda os problemas de quem entre os funcionários do ISP tem acesso ao banco de dados , e quão bem ele está protegido . Você ainda deve fazer perguntas difíceis sobre elas.

Como você provavelmente já aprendeu até agora, no entanto, é quase inédito o comprometimento do banco de dados de um provedor de serviços de Internet, enquanto é 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 ​​(hash unidirecional)? no site irmão Segurança de TI

Infelizmente, isso é bastante comum com hosts de orçamento e não é inédito, mesmo com hosts maiores. Coisas como o cpanel frequentemente precisam da sua senha de texto sem formatação 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.

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

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

Devido a malícia ou negligência dos funcionários ou a um comprometimento de seus sistemas por terceiros, as senhas de texto sem formatação que são usadas indevidamente criam um risco sério - não apenas para seus sistemas, mas para outros sistemas em que as pessoas podem ter usado a mesma senha.

Armazenamento responsável de senhas significa o uso de funções de hash unidirecional em vez de criptografia reversível, com um salt (dados aleatórios) adicionado à entrada do usuário para impedir o uso de tabelas arco-íris .

Se eu estivesse no seu lugar, perguntaria ao provedor algumas perguntas difíceis sobre como, exatamente, eles armazenam senhas e como, exatamente, seu representante de suporte conseguiu recuperar a senha. Isso pode não significar que eles armazenam as senhas em texto sem formatação, mas talvez elas estejam sendo registradas em algum lugar quando alteradas - também um risco enorme.

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

No entanto, vivemos na época em que o armazenamento de senhas em texto sem formatação causa enormes problemas financeiros e pode destruir completamente as empresas. O envio de senhas em texto sem formatação por 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 sem formatação. Se todos nós parássemos de aceitar esses serviços, provavelmente os provedores de serviços fariam algo a respeito e finalmente depreciariam a tecnologia antiga.

Algumas pessoas se lembram de que, uma vez, quando você quiser embarcar em um avião para voar para outro país, você literalmente entrará no avião a partir do estacionamento na rua. Sem segurança, como sempre. Atualmente, as pessoas percebem que são necessárias medidas de segurança apropriadas e que todos os aeroportos as adotam.

Eu mudaria para outro provedor de email. A pesquisa no "provedor de email seguro" gera muitos resultados.

Houve alguns bons pontos nos comentários. Provavelmente, procurar "provedor de email seguro" faria muito sentido, pois todos os provedores de email se gabariam de serem seguros. No entanto, não posso recomendar uma empresa específica e provavelmente não é uma boa ideia fazer isso. Se você identificar uma empresa em particular, fazer perguntas difíceis sobre segurança primeiro será uma boa coisa a fazer.

Minha recomendação é sair e perguntar aos próximos caras quais são suas políticas primeiro!
Se você estiver se sentindo bem, poderá dizer aos antigos fornecedores por que está saindo.

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

Dependendo do algoritmo de hash usado e da GPU, pode-se esperar que um computador moderno de quebra de senha agite entre 100 milhões e um bilhão de hashes por segundo. De acordo com isso , (que é um pouco datado do que um computador / supercomputador pode fazer), isso significa que qualquer senha de 6 caracteres pode ser quebrada em segundos. As tabelas para hashes de 7 e 8 caracteres em todos os vários algoritmos (MD5, SHA-1, SHA-256, SHA-512, Blowfish etc.) consumiriam quantidades desordenadas de espaço em disco (saiba que você precisa armazená-las em um SSD , não um prato magnético, para velocidade de acesso) e você pode ver por que 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.

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 para não poder verificar meu e-mail porque minha senha havia sido redefinida. Com o controle do meu email, eles tentaram redefinir minha senha na Amazon e no PayPal. Você pode adivinhar o que veio a seguir, certo? Cobranças fraudulentas com cartão de crédito!

Felizmente, consegui descobrir o que estava acontecendo com relativa rapidez, ligar para o meu provedor de hospedagem e validar minuciosamente minha identidade, apesar de as informações da conta e as questões de segurança terem sido alteradas (tudo no espaço de algumas horas). Durante essa conversa, o representante do atendimento ao cliente pôde me contar meu histórico de senhas, quando foi alterado e para quê. Era tudo o que eu precisava ouvir para saber que eu absolutamente precisava mudar de provedor.

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

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

Se eu tivesse agido quando suspeitei que não estavam levando a sério a segurança, esse mini-pesadelo nunca teria acontecido. Para pensar o que poderia ocorrer no caso de uma valiosa conta corporativa ser comprometida? Você ficaria fácil se eles apenas enviassem SPAM. A empresa para a qual eu trabalhava na época também estava usando esse provedor e priorizamos a transição o mais rápido possível.

Confie nos seus instintos! Não exagere na migração por preguiça ou porque sua configuração existente "funciona bem". A parte mais prejudicial dos problemas de supervisão de segurança, como armazenar senhas em texto não criptografado, configurar servidores incorretamente etc. é que eles falam com 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 fosse crítica. contrato de serviço em qualquer lugar próximo.

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

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

Parece mais simples do que o seu provedor ter um banco de dados cheio de registros de quando, quem e como alterou sua senha. Você conhece a navalha de Occam ...;)