E se o cliente precisar da capacidade de recuperar senhas?

Implemente a funcionalidade de que eles precisam 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 efetuar login como eles próprios e, em seguida, ter alguma função de 'identidade de mudança' disponível.

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

Você precisa convencê-los de que eles realmente não precisam ser civilmente responsáveis no caso de o servidor deles estar invadido. Eles também não precisam da reação de uma base de usuários informada que percebe que estão sendo negligentes.

Às vezes, há casos claros 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 impediram de ser um desastre absoluto foi que usamos uma função de hashing unidirecional (relativamente) boa (SHA512). Desde então, mudamos para o bcrypt para evitar ataques de força bruta / dicionário (ou pelo menos torná-los inutilizáveis). Eu simplesmente não encontro nada mais conscioná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 outro lugar.

Se o seu chefe achar que esse acesso à senha não é um problema, você também deve informar esse fato e talvez ele comece a pensar de maneira diferente. Mesmo que seu aplicativo esteja por trás do muro e não seja publicamente acessível, ele pode representar uma ameaça à segurança em outros serviços on-line. Os nomes de usuários (especialmente quando são e-mails) são fáceis de adivinhar. Não consigo imaginar o quão engraçado seria entrar na conta do chefe no Facebook e colocar algo na parede deles.

As senhas de usuários devem sempre ser tratadas como privacidade / informações confidenciais de nível superior às quais somente um número limitado de pessoas tem acesso. É melhor evitar armazenar essas informações voláteis. E mesmo quando você fizer isso, você deve ter acesso a cada acesso a essas informações. Como obter um documento 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 conta

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

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

Definitivamente, isso não deve ser feito fazendo login com a combinação UserName + Password .

É 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 poderia fornecer funcionalidades adicionais que deixariam claro que alguma ação foi feita pelo administrador em nome de algum usuário (que você não pode saber agora porque os administradores agem como deuses e fazem login como quem quer que seja e pode estar fazendo coisas que pode prejudicar a reputação real do funcionário).

Você tem que concordar que as pessoas cometem erros. Administradores são pessoas também. E se eles cometerem um erro em nome de outra pessoa, eles tentarão culpá-los. Eu tenho 100% de certeza sobre isso. Isso o tornará mais seguro para usuários não administradores, de forma que sua reputação no mundo real não seja afetada por 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, ele merece a proteção máxima. Mas se é "diga-me os acidentes de trânsito na minha rota para casa", quais são as consequências de uma violação de senha? Alguns sistemas que eu escrevi nem sequer têm senhas - basta digitar o seu e-mail ou o número do seu aluno ou algum outro identificador que as pessoas geralmente conhecem uns aos outros, e os proprietários do sistema valorizam a facilidade de uso e a incapacidade de serem bloqueados sobre a possível violação da privacidade se as pessoas se personificarem. Eu também não tenho nenhum problema com isso. Por que preciso de uma senha para configurar minha agenda de sessões preferenciais em uma conferência, por exemplo?

Então, se eu estivesse sendo trazido para revisão de código e você levantou isso para mim, é onde nós começaríamos. O que você está protegendo? Quais são as consequências negativas de uma pessoa conseguir logar como uma outra pessoa? Quais são as consequências negativas dos dados armazenados de todos que estão sendo expostos? Talvez sejam terríveis. Você os listaria para mim. Então, quais são as consequências de as pessoas não conseguirem clicar em "enviar e-mail minha senha", mas em vez disso, clicar em "redefinir minha senha"? Eles parariam de usar o site? E a equipe fazendo login como pessoa? Isso é economizar tempo, dinheiro, vendas perdidas ou o quê?

A parte final da história de custo / benefício, e a que você chega apenas se houver uma diferença realmente grande entre os negativos aos quais você está exposto agora e os negativos que você obterá ao remover a funcionalidade, é o custo para consertá-lo. Eu gastaria um milhão para me poupar a 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 entrou em operação com um site de solicitação de passaporte que tinha IDs na URL: se você editou a URL com uma ID diferente, viu a forma incompleta de outro cidadão aleatório. E eu tenho clientes que fazem login como seus clientes para fins de atendimento ao cliente para felicidade geral, então eu vejo o lado bom disso, embora eu não suportasse se os dados por trás da senha fossem realmente importantes para estranhos.

Pode ser contra a lei e pode abri-los para serem processados. Se eles retiverem qualquer tipo de informação pessoal sobre o usuário, ou o sistema interage com outros sistemas como o usuário, você pode precisar verificar se o sistema se enquadra em qualquer lei ou leis estaduais ou federais de privacidade. 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 dispositivo de dados portátil e sair com a capacidade de fazer login como qualquer usuário e causar estragos ou vender os dados. / p>

Mesmo que você considere que todos os administradores são confiáveis, isso 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 eles. Você pode implementar um recurso semelhante a sudo .

Isso não pode ser um sistema do governo federal, pois os requisitos do FIPS e FISMA proibiriam a criptografia reversível de senhas, e o departamento pai os colocaria na lua.

And in order to implement a stronger security policy (hashing passwords so they can't be easily retrieved), I have to remove existing functionality for them.

Para minha empresa anterior, continuei lutando pela capacidade de enviar e-mails de redefinição de senha para contornar esse problema. E eu continuei sendo rejeitado. No fim, cansei de acertar cocô contra a maré, então saí. Esse também era um chefe de cabelos pontudos que achava que as perguntas estúpidas que alguns sites de bancos pediam contavam como "autenticação de fator 2". Argumentar com ele era como um desenho animado de Dilbert (ele tinha a forma do PHB).

Plus there are actually existing functionality within the application for admin users to retrieve user's passwords in order to log in as them and do stuff (which they have said, they require).

Eu vi isso implementado em uma instituição financeira. As pessoas na área de suporte ao cliente entrariam com suas próprias credenciais e, se tivessem o direito de fazê-lo, poderiam fingir estar logando como cliente. Isso não foi registrado como o cliente, apenas representou o cliente . Dessa forma, se o representante do serviço de atendimento ao cliente decidisse retirar dinheiro, ele não mostraria o cliente fazendo isso nos registros: mostraria o representante do serviço ao cliente tentando fazê-lo (além de enviar um alerta para que fossem disparados o mais rápido possível). o rentacop poderia chegar ao seu andar).

Se for mal feito, o pessoal de suporte ao cliente poderá dar a impressão de que o usuário final está envolvido em alguma atividade que pode resultar em graves responsabilidades financeiras ou legais.

O último site federal em que eu trabalhei arrecadou 1/4 bilhão de dólares por ano dos usuários finais (dos quais havia cerca de 400 usuários), então o registro teve que ser muito apertado, e que apenas o usuário final autorizado foi permissão para tocar as páginas da web onde eles relataram as coisas que pagaram impostos sobre o consumo.

A Sony foi uma das empresas com a mais recente violação de segurança. Não foi apenas a rede PS3, foi também a sua rede de jogos MMORPG, totalizando bem mais de 25.000.000 nomes, endereços, números de cartões de crédito, nomes de usuários e senhas. Você pode acreditar que eu não estou feliz em tudo (eu quero o meu evercrack!).

Refiro-me ao Código de ética em engenharia de software sobre questões como essa. Minha interpretação, sua primeira prioridade não é para minar o interesse público (não como na possibilidade de senha comprometida mais como isto http://www.ajc.com/business/aarons-accused-in-suit-933851. html "> exemplo aqui , onde uma empresa modificou os laptops da Dell para que a empresa de aluguel pudesse espionar seus locatários sem que eles soubessem). Depois disso, sua responsabilidade é INFORMAR seu cliente sobre os possíveis riscos e deixá-los levar isso em consideração. Claro que essa é a linha de base mínima. Você tem que usar seu próprio julgamento sobre se você acha que isso é 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á minando 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"

Torne a fonte pequena para não desperdiçar papel.

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

Há momentos, no entanto, em que você mais ou menos precisa permitir a recuperação. No caso de senhas, você geralmente 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, é permitir que o usuário armazene dados no servidor criptografado com sua própria senha. Neste 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 considerará inaceitável que todos os dados criptografados fiquem 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 si. 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 (não realmente se) o usuário perder sua senha e não puder mais acessar os dados diretamente, você pode usar a senha do 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 em um único administrador completamente, também poderá gerenciar isso. Por exemplo, você pode decidir que 5 pessoas terão chaves de administrador e você deseja que pelo menos três delas concordem antes que uma chave possa ser recuperada. Nesse caso, quando você armazena a senha criptografada para fins administrativos, você a armazena várias vezes, uma vez para cada conjunto de três dos cinco administradores (o que não ocupa muito espaço, já que você está armazenando apenas vários chaves , a ~ 256 bits cada, não múltiplas cópias dos dados). Cada uma dessas cópias é criptografada sucessivamente com (os hashes de) cada uma das senhas para esses 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 e, em seguida, descriptografar usando cada uma das três senhas para finalmente obter a chave original. Você pode usar isso para recuperar os dados em si, ou pode apenas criptografá-los novamente com a (hash of) nova senha do usuário para que eles ainda possam acessar seus dados.

Quando você faz isso, porém, você realmente precisa usar um algoritmo de criptografia padrão e (por strong preferência) uma implementação padronizada, bem conhecida e completamente 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 absurda a falta de qualquer tipo de auditoria de segurança. A única razão que posso ver para isso é criar uma pista de auditoria falsa.

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 de senha atual
• Substituindo por um valor conhecido
• (atividade de rastreamento de auditoria falsificada, por exemplo, transferir fundos para uma conta no exterior)
• Substituir o hash da senha original

Eu ficaria desconfortável com a última etapa - quem quer que fosse representado no sistema deveria saber que isso aconteceu. Talvez você consiga persuadir os negócios dizendo "É como se seu banco me permitisse acessar sua conta sem o seu conhecimento, porque eu disse que precisava mesmo"

A crença deles em um sistema de senhas 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. Segurança muitas vezes sofre por conveniência. Torne conveniente e seguro.

Editar: Eles nunca, nunca vão compreender totalmente o problema de segurança de senha, mas eles entendem 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 levar uma hora ou um ano. É uma alteração de recurso e não uma reconstrução completa.

Considerando eventos atuais (vazamento de dados do Epsilon e vazamento de dados do Playstation Network), espera-se que os problemas sejam claramente ó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ândalos e gastos, o que deveria ser fácil, novamente considerando os eventos atuais. Mas se isso não der certo, o que você realmente pode fazer? Não muito. Pare em protesto, demonstre a vulnerabilidade para chamar a atenção. Nem soa como ótimas opções.

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

Normalmente, o motivo para um Administrador ver a senha do usuário é no caso de perdê-lo, ele pode fornecê-lo ao usuário. Tanto quanto eu posso dizer, o Windows não deixa o administrador ver a senha também - então por que sua aplicação? Qualquer biblioteca de criptografia interna certamente será quebrada, porque tenho certeza de que quem a escreveu não funciona para a NSA.