Citações por inadmissibilidade de senha globalmente exclusiva

Estou tendo um desacordo com alguém (um cliente) sobre o processo de identificação / autenticação de usuário de um sistema. O ponto principal é que eles querem que cada usuário tenha uma senha globalmente exclusiva (ou seja, dois usuários não podem ter a mesma senha). Eu expus todos os argumentos óbvios contra isso (é uma vulnerabilidade de segurança, confunde identificação com autenticação, é inútil etc.), mas eles estão insistindo que não há nada de errado com essa abordagem.

Eu fiz várias pesquisas no Google procurando opiniões autoritativas (ou semi-autoritativas ou até mesmo independentes) sobre isso, mas não consigo encontrar nenhuma (principalmente é apenas uma falsa paleta óbvia que não parece digna de advertência, pois Até onde eu sei). Alguém pode me indicar uma opinião independente, por favor?

[EDIT]
Obrigado por todas as suas respostas, mas eu já entendo os problemas com essa abordagem / requisito proposto e posso até explicá-los ao cliente, mas o cliente não os aceita, portanto, meu pedido de fontes independentes e / ou autorizadas .

Eu também encontrei o artigo do Daily WTF, mas sofre com o problema que Jon Hopkins apontou - que este é um WTF tão evidente que parece não valer a pena explicar o porquê .

E sim, as senhas serão salgadas e hash. Nesse caso, pode ser difícil garantir a exclusividade global, mas isso não resolve o meu problema - significa apenas que eu tenho um requisito de que o cliente não se mexa, isso não é apenas desaconselhado, mas também é difícil de resolver. implemento. E se eu estivesse em posição de dizer "Eu não estou começando a usar sal e hash", estaria em posição de dizer "Não estou implementando senhas globalmente únicas".

Quaisquer indicações para fontes independentes e / ou autorizadas sobre por que essa é uma má idéia ainda recebida com gratidão ...
[/ EDIT]

Sempre que um cliente tenta criar uma senha que já existe, recebe feedback de que algum usuário já usa essa senha, geralmente uma violação do contrato de privacidade.

Além disso, os nomes de usuário são muito mais fáceis de adivinhar (e, se houver um fórum, você pode encontrar muitos nomes de usuário lá) e está sugerindo maneiras de o usuário invadir o site.

Deve haver alguma página na internet em algum lugar que descreva a parte de violação do contrato de privacidade, além de que seja apenas senso comum: eles basicamente estariam fornecendo a alguém uma chave e uma lista de endereços residenciais.

EDIT: Não é perto do autor, mas talvez seja útil depois de explicar o que significa o WTF: http://thedailywtf.com/Articles/Really_Unique_Passwords.aspx

As melhores práticas impedem o cumprimento do requisito:

Você não pode fazer isso porque não sabe quais são as senhas, portanto não pode compará-las porque tudo o que você armazena é o hash da senha e um salt (que você pode armazenar ao lado da senha do hash). Esta é uma prática recomendada, e é isso que você faz. Feito.

Outra edição: Doh! A retrospectiva é fácil - você ainda pode verificar a singularidade, porque (é claro) você tem sal ... apenas atire em mim agora ... é claro que não precisa mencionar esse detalhe ao cliente.

FWIW, não é tão burro quanto você pensa que é - o objetivo é impedir que grupos de usuários concordem e compartilhem a mesma senha, o que as pessoas farão acreditando que isso facilitará suas vidas.

Se aplicado com a exigência de alterar a senha regularmente e com uma restrição que impeça as pessoas de reutilizarem uma senha atual ou usada anteriormente (de todo), além de requisitos sensíveis de "força" (ou pelo menos um dicionário pré-carregado de "bloqueado") "senhas), você chegará a um ponto, com bastante rapidez, em que as probabilidades não estão a favor do hacker.

Ok, minha resposta começou originalmente com:

Notionalmente, há muito pouco de errado com isso, dadas algumas ressalvas - a maioria das quais é que eu estou sendo grossa ...

Humor inapropriado aparentemente - o ponto era que, se você não tem a restrição globalmente única, está criando oportunidades diferentes, talvez menos perigosas - eu não sei.

A imposição de senhas irrepetíveis vaza informações

Quão? Como toda vez que um cracker tenta criar um novo usuário com uma senha simples, seu sistema responde com "Não, não pode ter essa senha", o cracker diz "Goody, esse é um da lista".

Vazar informações sobre sua segurança geralmente é uma coisa ruim. OK, terceiros sabendo que o algoritmo é bom (ele precisa de revisão por pares), mas permitindo que um cracker deduza as chaves - ruim, muito, muito ruim.

Recursos que descrevem políticas de gerenciamento de senhas boas e ruins

Leia este artigo do especialista em segurança Bruce Schneier para uma discussão aprofundada sobre a força da senha.

Leia este PDF dos pesquisadores de segurança Philip Inglesant e M. Angela Sasse para uma discussão aprofundada sobre "O verdadeiro custo das políticas de senhas inutilizáveis". Para citar a conclusão:

Contra a visão de mundo de que "se apenas [os usuários] entendessem os perigos, eles se comportariam de maneira diferente" [12], argumentamos que "se apenas os gerentes de segurança entendessem os verdadeiros custos para os usuários e a organização, eles definiriam políticas de maneira diferente".

Falso senso de segurança

Portanto, o cliente insere: "Se ninguém tiver a mesma senha, se uma for quebrada, apenas uma pessoa será afetada". Não. Todos são afetados porque o cracker demonstrou que seu sistema de senhas é fundamentalmente defeituoso: é vulnerável a um ataque de dicionário em um sistema on-line. Não deveria ter sido possível para um cracker tentar várias suposições contra uma senha em primeiro lugar.

Para acesso on-line, basta 6 caracteres

Falando fora do tópico, mas achei que valeria a pena mencionar para os leitores interessados. Em termos de segurança, um sistema on-line é aquele que possui um processo de gerenciamento de segurança ativo, monitorando e controlando o acesso aos dados. Um sistema off-line é aquele que não possui (como ter dados criptografados em um disco rígido que foi roubado).

Se você possui um sistema de senhas on-line, não precisa de senhas de alta segurança. As senhas precisam ser suficientemente complexas para evitar suposições dentro de 20 tentativas (portanto, um simples ataque de "nome do cônjuge / filho / animal de estimação" falhará). Considere o seguinte algoritmo:

1. O cracker adivinha a senha usando a abordagem "raiz mais sufixo" para minimizar as suposições
2. Credenciais rejeitadas e novas tentativas de login impedidas por N * 10 segundos
3. Se N> 20 bloquear a conta e informar o administrador
4. N = N +1
5. Informe ao usuário que o próximo login pode ocorrer no horário T (calculado acima)
6. Vá para a etapa 1

Para uma senha simples de 6 caracteres, o algoritmo acima evitará ataques de dicionário, permitindo que até mesmo o usuário mais inepto de um teclado móvel passe eventualmente. Nada impedirá o chamado "ataque da mangueira de borracha", onde você vence o titular da senha com uma mangueira de borracha até que eles avisem.

Para um sistema off-line quando os dados criptografados estão espalhados em uma unidade flash e o cracker tem a liberdade de tentar qualquer coisa contra isso, você deseja a chave mais resistente que puder encontrar. Mas esse problema já está resolvido .

Se você os aconselhou contra esse curso de ação, e forneceu-lhes razões, eu aceitaria a palavra deles e apenas implementaria o sistema, conforme sugerido. Pode não ser satisfatório, mas você fez o seu trabalho e eles estão pagando a conta; portanto, devem conseguir o que querem.

Há uma exceção. Se as conseqüências negativas de uma violação do sistema forem severas (por exemplo, se informações muito particulares provavelmente serão comprometidas por uma violação de segurança), você poderá, de fato, ter um dever profissional de não implementar o sistema desejado. Não espere que ele se torne popular se você recusar, mas não deixe que esse seja o seu guia.

Eu só quero reforçar a resposta de Murph. Sim, é um problema de segurança e há vulnerabilidades de divulgação de informações na sua implementação. Mas do ponto de vista do cliente, ele não parece estar muito preocupado com isso.

O que você deve salientar é que é fisicamente inviável implementar realmente uma verificação de "senha exclusiva". Se você está salgando e hash a senha, e não as armazenando como texto não criptografado, são operações O (n) (caras) que realmente executam a verificação de exclusividade.

Você pode imaginar se você possui 10.000 usuários e leva 30 segundos para passar pela senha de todos os usuários para verificar a exclusividade sempre que alguém se cadastra ou altera sua senha?

Eu acho que essa é a resposta que você precisa dar ao seu cliente.

Pensando em termos de local apropriado para fazer a pergunta, a seção de segurança de TI do Stack Exchange deve ser um ponto útil para você. Experimente /security/tagged/passwords - várias pessoas focadas na segurança de TI devem poder fornecer respostas específicas.

Ele provavelmente gostaria da criptografia RSA de dois fatores. Se você estiver usando a associação ao Active Directory ou ASP.NET, isso é óbvio.

O token de hardware ou software gera uma senha exclusiva dependente do tempo, seguida por um código PIN. Juntos, isso fornece uma senha exclusiva para cada usuário.