O que fazer quando sua empresa não criptografa senhas

fundo

Fui contratado para ajudar uma empresa a manter seu servidor. Trabalho em alguns projetos PHP menores, mas também examino problemas de desempenho e, recentemente, varro os logs em busca de hackers.

Esses caras estão executando o servidor há algum tempo e têm o que eu chamaria de um aplicativo herdado nas últimas pernas. Ele usa aspas mágicas, variáveis ​​globais (que $idpodem ser sobrescritas por $_GET['id']), usa .htaccess como sua única segurança em alguns casos, o que você quiser. Um pesadelo de segurança e programação.

Nós fomos hackeados no passado, principalmente com injeções de SQL, que executavam SLEEP(99999999)comandos e agiam como um ataque do DOS. Felizmente eles não corriam "mesinhas de cabeceira",

XKCD: http://xkcd.com/327/

Então, eu reescrevi suas instruções SQL vulneráveis mysql_query()(não mysqli) para transações PDO. Também estou analisando as consultas para SLEEPe UNION, que não usamos, mas as injeções. Por enquanto, tudo bem.

Última edição

Recentemente, fomos informados de que os registros estão mudando no banco de dados para os usuários, como seus endereços de e-mail para aqueles supostamente criados por spammers.

Percebi que as colunas deles não tinham uma last_modifiedcoluna, então não conseguimos nem saber quando elas estavam sendo alteradas, muito menos por quem. Eu adicionei essa coluna, mas esse é apenas o primeiro passo.

Quando eu estava olhando para esta tabela, notei que as senhas não eram salgadas nem mesmo hash, apenas salvas como texto simples.

Comunicação com o Cliente

Como posso abordá-los sobre toda a situação, como contratada, sem agitar meus braços como um louco? Algum conselho? Eu estava pensando em uma abordagem calma de,

    PROBLEMA 1
        Sinopse
        Por que isso é um problema?
        O que pode acontecer se isso não for corrigido
        Correção sugerida

    EDIÇÃO 2
        Sinopse
        Por que isso é um problema?
        O que pode acontecer se isso não for corrigido
        Correção sugerida
        

A abordagem calma que você sugere seria a melhor. Salientando que quando esses dados são expostos, a maioria dos usuários fica vulnerável ao roubo de identidade devido à reutilização de senha. Esse seria um bom momento para ressaltar que esse é o mesmo problema que afetou a Target (supondo que a empresa não seja a Target). E seu gerente deve ser bastante receptivo a mudar isso.

No que diz respeito à legalidade dos dados, não acredito que nome de usuário / senha sejam considerados iguais a Dados CC, Informações pessoais, etc. Embora possa depender de qualquer informação que você tenha para seus usuários. Não sou advogado e esses aspectos seriam mais indicados em sua revelação e devem ser levados ao departamento jurídico da sua empresa para determinar as legalidades.

https://en.wikipedia.org/wiki/Information_privacy_law

E você tem este XKCD para ajudá-lo também:

Realmente depende do público em que você está tentando abordar isso. Trabalhei em empresas com sérios problemas de segurança, como você está afirmando, mas eles se recusaram a ouvi-lo até eu mostrar a eles.

Uma abordagem, se possível, é reunir basicamente o que você pretende fazer e especificar o que já aconteceu nesses hacks. Se o seu público não for técnico, você provavelmente precisará apontar o custo comercial que esses compromissos podem ter. Obviamente, as contas invadidas reduzem a credibilidade no seu sistema e o valor percebido do cliente pelo seu produto. Sem mencionar que um sistema comprometido com senhas de texto sem formatação e endereços de e-mail para usuários pode causar um efeito grave de ondulação.

A próxima coisa que você deve fazer, se possível, é provar. Se você conseguir suportar esse sistema em um ambiente de teste, faça-o. Em seguida, demonstre diante deles o tipo de impacto que você pode ter no sistema a partir do lado do cliente do aplicativo. Mesmo com o pessoal da tecnologia, isso provou ser bastante convincente para mim (embora eles ainda não agissem nos meus casos).

Obviamente, como você disse, você precisa explicar se alguma ação deve ser tomada e uma estimativa do esforço para conseguir isso. Isso os ajudará a justificar o custo, embora alguns lugares simplesmente não se importem. Pelo menos você pode limpar sua consciência e seguir em frente sabendo que tentou.

Se, como você diz, foi contratado para manter o servidor deles, certamente este contrato deve incluir na descrição da tarefa tarefas como garantir a integridade, segurança e disponibilidade do sistema operacional, aplicativos e todos os dados, etc ?! Se houver uma vaga indicação de que o contrato espera (e o responsabiliza) por garantir que o servidor esteja seguro, não perderia tempo reunindo casos de negócios e apenas fiz um bom trabalho para garantir que os problemas sejam corrigidos um backup antes e depois, mantendo um histórico da versão do seu código alterado).

Eu não esperaria que uma mudança como essa exigisse mais do que uma manhã de trabalho e, se perguntarem em que você gastou seu tempo trabalhando, você poderá manter um diário para explicar e justificar suas ações. Desde que você esteja trabalhando dentro do escopo do seu contrato, não deve haver problemas aqui. Às vezes, enlouquecer toda a segurança na frente dos tomadores de decisão causa pânico ou, na pior das hipóteses, cria uma oportunidade para eles dizerem que não se importam com esses problemas, por isso não corrija, enquanto isso o contrato ainda o responsabiliza no caso de uma violação! Talvez essa nem sempre seja a abordagem mais favorável aos negócios, mas minha ética profissional não me permitia deixar senhas não criptografadas em qualquer sistema que eu já tenha sido responsável por ter feito isso me chamar a atenção.

Por experiência pessoal, costumo encontrar sempre que começo a trabalhar para um novo empregador ou cliente, discutir cenários e expectativas antecipadamente pode economizar muito estresse de sua parte, por exemplo: se encontrar algum problema de segurança que possa resolver, você está feliz por para que eu prossiga e conclua este trabalho sem chegar a você o tempo todo, apenas notificando você sobre suspeitas de violações / incidentes? Eles quase sempre dizem sim a isso porque, do ponto de vista deles, não estão interessados ​​em se preocupar com segurança ou coisas de computador - é por isso que o contrataram! Talvez isso não responda à pergunta da maneira que você esperava, mas espero que isso dê motivo para pensar. Desejo a todos o melhor e espero que o problema seja corrigido!

Certamente, se a alteração do endereço de e-mail do cliente já está acontecendo, e isso é considerado um problema - a capacidade de alterar senhas também é um problema.

Agora, se você protegeu o banco de dados o suficiente para impedir que isso ocorra no futuro, a chance de alguém editar a senha do usuário é igualmente fixa e você precisa considerar se alguém pode ler a senha agora.

É claro que se eles puderem, ou se (no caso improvável ) de você não ter garantido totalmente o banco de dados, certamente a criptografia das senhas deve ser feita - como fazê-lo? Basta colocá-lo no mesmo contexto que o problema "ter endereços de email atualizados". Se isso exige que o aplicativo seja alterado e se esse é um problema "muito difícil" é outra questão que precisa ser levantada com eles. Veja o código e veja quanto será o custo da alteração antes de executar a correção sugerida.