E se o cliente precisar recuperar as senhas?

No momento, eu herdei um aplicativo no trabalho e, para meu desgosto, percebi que as senhas de usuário armazenadas no banco de dados são criptografadas usando uma função de criptografia interna, que também inclui a capacidade de descriptografar.

Então, tudo o que alguém realmente precisa fazer é copiar a tabela do usuário e o conjunto de criptografia (qualquer pessoa com acesso à produção do banco de dados) e, então, eles teriam acesso a 100.000 endereços de email e senhas em potencial para eles.

Estou tentando explicar à empresa por que isso não é uma boa ideia, mas os conceitos de segurança parecem ultrapassar a cabeça, pois eles não são tão tecnicamente preocupados (é para o governo). Além disso, existem funcionalidades realmente existentes no aplicativo para que os usuários administradores recuperem as senhas dos usuários para fazer login como eles e fazer coisas (o que eles disseram que exigem).

Então eles não entendem as implicações de segurança. E, para implementar uma política de segurança mais forte (hash de senhas para que não possam ser facilmente recuperadas), eu tenho que remover a funcionalidade existente para elas.

O que devo fazer? Eu não criei o sistema de senhas em primeiro lugar, por isso não posso ser responsabilizado se algo der errado. Por outro lado, não me sinto bem com isso e também não quero ter acesso a 100.000 logons de email em potencial.

Implemente a funcionalidade necessária de maneira segura. Os administradores que efetuam login como outro usuário podem ser implementados sem que eles saibam a senha do usuário. Eles podem fazer login como eles mesmos e, em seguida, ter alguma função de 'alteração de identidade' disponível.

Proteger um banco de dados de senhas não é uma preocupação comercial, é uma preocupação técnica. Não fazer isso é um bug. Se a empresa pensar em segurança como uma troca de funcionalidade, ela perderá. Você não deve dar a eles nenhum motivo para pensar dessa maneira.

Você precisa convencê-los de que eles realmente não precisam ser responsabilizados civilmente no caso de invasão do servidor. Nem precisam da reação de uma base de usuários informada que percebe que estão sendo negligentes.

Às vezes, existem casos bem definidos em que uma das partes está errada e a outra está certa. Este é um desses momentos.

Veja o que aconteceu com a Sony. Além disso, nosso site foi hackeado recentemente e uma das coisas que o impediu de ser um desastre não mitigado foi o fato de termos usado uma função de hash unidirecional (relativamente) boa (SHA512). Desde então, mudamos para o bcrypt para impedir ataques de força bruta / dicionário (ou pelo menos torná-los insustentáveis). Simplesmente não encontro mais nada de conspirável.

Fato: as pessoas usam a mesma senha em muitos sites

Seu chefe provavelmente não percebe que as pessoas costumam usar uma única senha (ou um conjunto muito limitado delas) para todos os tipos de serviços (incluindo serviços bancários ou Facebook e similares). Se os usuários puderem alterar sua senha em seu sistema, é altamente provável que usem a mesma senha que em outros lugares.

Se o seu chefe acha que esse acesso à senha não é um problema, você também deve contar esse fato e talvez eles comecem a pensar de maneira diferente. Mesmo que seu aplicativo esteja atrasado e não seja acessível ao público, ele pode representar uma ameaça à segurança de outros serviços online. Os nomes de usuários (especialmente quando são emails) são fáceis de adivinhar. Não consigo imaginar como seria engraçado fazer login na conta do Facebook do chefe e colocar algo em seu mural.

As senhas dos usuários devem sempre ser tratadas como informações de privacidade / confidenciais de primeira linha às quais apenas um número limitado de pessoas tem acesso. É melhor evitar armazenar essas informações voláteis. E mesmo quando o fizer, você deverá receber cada acesso único a essas informações. Como obter um papel confidencial de um cofre altamente seguro que só pode ser aberto com várias chaves. Então, as pessoas sabem quem recebeu acesso e quando.

Como implementar a delegação de contas

A delegação de conta no seu aplicativo deve ser feita de maneira diferente.

1. Os administradores devem fazer login como eles mesmos e, em seguida,
2. também (já que são usuários privilegiados)
   • digite apenas UserName ou
   • selecione um determinado usuário em uma lista para fazer login como eles

Definitivamente, isso não deve ser feito fazendo login com a combinação Nome de usuário + Senha .

É verdade que uma nova tela deve ser desenvolvida para permitir o logon delegado, mas ainda assim.

Por que o logon delegado é melhor?

Você também pode fornecer funcionalidades adicionais que deixariam claro que alguma ação foi executada pelo administrador em nome de algum usuário (o que você não pode saber agora porque os administradores agem como deuses e se conectam como quem quer que esteja fazendo coisas que podem prejudicar reputação real dos funcionários).

Você tem que concordar que as pessoas cometem erros. Administradores também são pessoas. E se cometerem um erro em nome de outra pessoa, tentarão culpá-la. Estou 100% certo disso. Isso tornará mais seguro para usuários não administradores, para que sua reputação no mundo real não sofra erros de outras pessoas.

Você não menciona o que o aplicativo faz. Se são aplicativos de passaporte, cheios de informações sobre roubo de identidade que devem ser protegidas, ela merece a proteção máxima. Mas se é "diga-me os acidentes de trânsito no meu caminho para casa", quais são as consequências de uma violação de senha? Alguns sistemas que escrevi nem têm senhas - basta digitar seu e-mail ou número de aluno ou outro identificador que as pessoas geralmente conhecem, e os proprietários do sistema valorizam a facilidade de uso e a incapacidade de serem bloqueados. sobre a possível violação de privacidade se as pessoas se passarem. Também não tenho nenhum problema com isso. Por que preciso de uma senha para configurar minha agenda de sessões preferidas em uma conferência, por exemplo?

Então, se eu estivesse sendo chamado para revisão de código e você me dissesse isso, é aí que começaríamos. O que você está protegendo? Quais são as consequências negativas de uma pessoa conseguir fazer login como outra pessoa? Quais são as consequências negativas da exposição de todos os dados armazenados? Talvez eles sejam horríveis. Você os listaria para mim. Então, quais são as consequências de as pessoas não poderem clicar em "me enviar minha senha por e-mail", mas precisar clicar em "redefinir minha senha"? Eles parariam de usar o site? E o pessoal que faz o login como pessoa? Isso economiza tempo, dinheiro, vendas perdidas ou o quê?

A parte final da história de custo / benefício, e a que você só conhece se houver uma diferença realmente grande entre os negativos aos quais você está exposto agora e os negativos que você terá ao remover a funcionalidade, é o custo para corrigi-la. Eu gastaria um milhão para me poupar da chance de uma exposição de mil dólares? Não. E o contrário? Depende das probabilidades, eu acho, mas minha primeira resposta seria sim.

ps - o governo canadense foi ao ar com um site de solicitação de passaporte que tinha IDs no URL: se você editou o URL com um ID diferente, viu o formulário pela metade de algum outro cidadão aleatório. E eu tenho clientes que se conectam como clientes para fins de atendimento ao cliente de maneira geral, então vejo o lado bom disso, apesar de não aceitá-lo se os dados por trás da senha forem realmente importantes para estranhos.

Pode ser contra a lei e pode levá-los a serem processados. Se eles mantiverem qualquer tipo de informação pessoal sobre o usuário, ou o sistema interage com outros sistemas como o usuário, pode ser necessário verificar se o sistema se enquadra em alguma das leis ou leis de privacidade estaduais ou federais. ie Sarbanes / Oxley, Califórnia OOPA, etc.

Além dos possíveis problemas legais, você também pode apontar que qualquer administrador pode, a qualquer momento, despejar a tabela inteira em um stick de dados portátil e sair com a capacidade de efetuar login como qualquer usuário e causar estragos ou vender os dados.

Mesmo que você assuma que todos os administradores são confiáveis, também torna devastador o comprometimento de uma senha de administrador.

Você também não precisa da senha de um usuário para executar operações como elas. Você pode implementar um sudorecurso semelhante.

Isso não pode ser um sistema de governo federal, já que os requisitos do FIPS e do FISMA proibiriam a criptografia reversível para senhas, e o departamento pai as levaria à lua.

E, para implementar uma política de segurança mais forte (hash de senhas para que não possam ser facilmente recuperadas), eu tenho que remover a funcionalidade existente para elas.

Na minha empresa anterior, continuei lutando pela capacidade de enviar e-mails de redefinição de senha para solucionar esse problema. E eu continuei sendo anulado. No final, eu cansei de fazer cocô na maré, então fui embora. Esse também era um chefe de cabelos pontudos que achava que as perguntas estúpidas feitas por alguns sites de bancos contavam como "autenticação de dois fatores". Discutir com ele era como um desenho animado de Dilbert (ele tinha a forma de um PHB).

Além disso, existem funcionalidades realmente existentes no aplicativo para que os usuários administradores recuperem as senhas dos usuários para fazer login como eles e fazer coisas (o que eles disseram que exigem).

Eu já vi isso implementado em uma instituição financeira. As pessoas na área de suporte ao cliente efetuariam login com suas próprias credenciais e, se tivessem o direito de fazê-lo, poderiam fingir estar efetuando login como cliente. Isso não os fez logon como cliente, apenas o personificou . Dessa forma, se o representante do serviço ao cliente decidir sacar dinheiro, ele não aparecerá como o cliente fazendo nos logs: mostrará o representante do serviço ao cliente tentando fazê-lo (além de enviar um alerta para que seja acionado assim que o rentacop poderia chegar ao chão).

Se mal executado, tornaria a equipe de suporte ao cliente capaz de fazer parecer que o usuário final se envolveu em alguma atividade que poderia resultar em sérios passivos financeiros ou legais.

O último site federal em que trabalhei arrecadou 1/4 bilhões de dólares por ano de usuários finais (dos quais havia cerca de 400 usuários); portanto, o registro teve que ser muito restrito e apenas o usuário final autorizado podia tocar as páginas da web em que relataram o material em que pagaram impostos.

A Sony foi uma das empresas com a mais recente violação de segurança. Não era apenas a rede PS3, era também a rede de jogos MMORPG, totalizando um número superior a 25.000.000 de nomes, endereços, números de cartão de crédito, nomes de usuário e senhas. Você pode acreditar que eu não sou nada feliz (eu quero minha fenda eterna!).

Refiro o Código de Ética da Engenharia de Software em preocupações como esta. Na minha interpretação, sua primeira prioridade não é minar o interesse público (não como a possibilidade de uma senha comprometida mais como este exemplo aqui, onde uma empresa modificou os laptops da Dell para que a empresa de aluguel pudesse espionar seus inquilinos sem que eles soubessem). Depois disso, sua responsabilidade é informar seu cliente sobre riscos potenciais e deixá-lo levar em consideração. Claro que é a linha de base mínima. Você tem que usar seu próprio julgamento para saber se isso ainda é mais do que você pode esperar e permitir.

É claro que quando você menciona um projeto do governo, se as informações privadas dos cidadãos estão em risco por causa dessas práticas, isso está prejudicando o interesse público.

Você pode imprimir a lista de e-mails e a senha descriptografada e colocá-la na mesa do seu chefe, com um grande aviso na capa: "Confidencial"

Faça a fonte minúscula para não desperdiçar papel.

Você também pode mostrar a eles como o bugzilla permite que os administradores representem pessoas sem usar sua senha.

Antes de tudo, concordo com as outras respostas, indicando que é muito mais seguro evitar isso e armazenar apenas hashes de senhas, não as próprias senhas ou qualquer coisa que possa ser transformada novamente em senha.

Há momentos, no entanto, quando você mais ou menos precisa permitir a recuperação. No caso de senhas, geralmente você deseja recuperar, simplesmente permitindo que um administrador altere a senha quando / se necessário, em vez de recuperar a senha existente.

Outra possibilidade, no entanto, é que você permita que o usuário armazene dados no servidor criptografado com sua própria senha. Nesse caso, simplesmente permitir que um administrador altere a senha não é suficiente. A nova senha não funcionará para descriptografar os dados e a maioria dos usuários achará inaceitável que todos os dados criptografados se tornem inacessíveis quando / se esquecerem / perderem uma senha. Para essa situação, há uma alternativa razoavelmente segura e ainda permite a recuperação quando realmente necessário.

Em vez de usar a senha do usuário para criptografar os dados, você cria uma chave aleatória para criptografar os dados. Em seguida, você armazena essa chave em alguns locais: uma vez criptografada com a senha do usuário e em outro local criptografada com uma senha de administrador. Então, quando (na verdade, se) o usuário perder sua senha e não puder mais acessar os dados diretamente, você poderá usar a senha de administrador para descriptografar a chave real e usá-la para recuperar os dados e / ou criptografar novamente a chave com a nova senha do usuário.

Se você não quiser confiar completamente em um único administrador, também poderá gerenciar isso. Por exemplo, você pode decidir que cinco pessoas terão chaves de administrador e deseja que pelo menos três delas concordem antes que uma chave possa ser recuperada. Nesse caso, ao armazenar a senha criptografada para fins administrativos, você a armazena várias vezes, uma para cada conjunto de três dos cinco administradores (o que não ocupa muito espaço, pois você armazena apenas várias chaves , a ~ 256 bits cada, não várias cópias dos dados). Cada uma dessas cópias é criptografada sucessivamente com (os hashes de) cada uma das senhas dos três administradores.

Para descriptografá-lo, você precisa identificar os três administradores que estão inserindo suas senhas e escolher a chave criptografada adequada para esse conjunto de três, depois descriptografar usando cada uma das três senhas para finalmente obter a chave original. Você pode usá-lo para recuperar os dados em si ou simplesmente criptografá-los novamente com a nova senha do usuário (hash da), para que eles ainda possam acessar seus dados.

Ao fazer isso, no entanto, você realmente precisa usar um algoritmo de criptografia padrão e (por forte preferência) uma implementação padrão, bem conhecida e bem estudada.

Isso me preocupa, já que é para um projeto do governo. Recuperar a senha de um usuário para executar uma ação sob seu ID torna um absurdo qualquer tipo de auditoria de segurança. A única razão que vejo para isso é criar uma trilha de auditoria falsa.

Realmente não há necessidade de usar criptografia reversível para senhas. Se houver um motivo legítimo para falsificar um ID do usuário, isso pode ser feito por:

• Armazene o hash da senha atual
• Substituindo por um valor conhecido
• (Atividade de trilha de auditoria falsificada, por exemplo, transferir fundos para uma conta no exterior)
• Substituir o hash da senha original

Eu ficaria desconfortável com o último passo - quem quer que seja representado no sistema deve saber que isso aconteceu. Talvez você possa convencer a empresa dizendo: "É como se seu banco me permitisse acessar sua conta sem o seu conhecimento, porque eu disse que realmente precisava"

Sua crença em um sistema de senha melhor não é o problema. Crie uma solução para permitir que um administrador / suporte represente uma conta de usuário e forneça sua correção para as senhas. A segurança costuma sofrer por conveniência. Torne-o conveniente e seguro.

Edit: Eles nunca, nunca, jamais compreenderão completamente o problema de segurança da senha, mas entenderão a perda de funcionalidade. Faça esta proposta e veja se você pode obter a aprovação para fazer as alterações necessárias. Eles nem sabem se vai demorar uma hora ou um ano. É uma alteração de recurso e não uma reconstrução completa.

Considerando os eventos atuais (o vazamento de dados Epsilon e o vazamento de dados da Playstation Network), seria de esperar que os problemas fossem óbvios.

Às vezes, no entanto, como desenvolvedor, você simplesmente não pode afetar a política.

Eu faria o possível para mostrar o potencial de escândalo e despesa, o que deve ser fácil, considerando novamente os eventos atuais. Mas se isso não der certo, o que você realmente pode fazer. Não muito. Saia em protesto, demonstre a vulnerabilidade para chamar a atenção. Nem soam como ótimas opções.

Eu desaconselharia isso, mas se você absolutamente precisar ter a capacidade de descriptografar senhas, deverá usar a criptografia de chave pública. Dessa forma, você pode criptografar todas as senhas usando a chave pública. Você pode verificar as senhas criptografando com a chave pública e comparando, e pode manter a chave privada em outro lugar (não no computador de produção).

Geralmente, o motivo para um administrador ver a senha do usuário é que, caso a perca, eles podem dar ao usuário. Pelo que sei, o Windows também não permite que o administrador veja a senha - então por que o seu aplicativo? Qualquer biblioteca de criptografia interna certamente será quebrada, porque tenho certeza de que quem a escreveu não funciona para a NSA.