Punindo usuários por senhas inseguras [fechado]

Estou pensando em limitar os direitos dos usuários que escolhem senhas inseguras (insegurança de uma senha sendo determinada pelo tamanho, quantos tipos de caracteres (maiúsculas / minúsculas, números, símbolos etc.) são usados ​​e se podem ser localizado em uma tabela arco-íris) para limitar quanto dano sua conta pode causar se comprometida.

Ainda não tenho um aplicativo para essa idéia, mas digo que estou escrevendo um fórum ou algo assim: os usuários que usam 1234 como senha podem precisar preencher um captcha antes de postar ou estar sujeitos a rigorosas medidas anti-spam, como como tempos limite ou filtros bayesianos que rejeitam seu conteúdo. Se este fórum for muito hierárquico, permitindo a "promoção" de moderadores ou qualquer outra forma, isso os impediria de obter privilégios ou dizer-lhes que têm privilégios, mas não permitiria exercitá-los sem alterar a segurança. senha.

Obviamente, essa não poderia ser a única medida de segurança, mas poderia ir bem ao lado de boas práticas de segurança.

O que você acha? Isso é exagerar, desviar o foco das práticas de segurança mais importantes ou é uma boa maneira de limitar os riscos e incentivar os usuários a usar senhas mais seguras (e convencer as pessoas de que você está usando boas práticas de segurança)?

YAGNI , KISS , DRY , a regra dos 10 segundos e o fato de que "os usuários não se importam com VOCÊ" provavelmente devem reduzi-la a uma solução: não.

• É mais trabalho de desenvolvimento que precisaria de muitos testes para ser confiável e seguro.
• Provavelmente reduz a segurança do site da maneira que você o vê. A chance de algum bug levar à escalação de privilégios com uma senha terrível é muito grande.
• Aumenta a complexidade para o desenvolvedor, testador, mantenedor, DBA, sysadmin e usuário.
• Quanto mais complexidade, mais difícil é evitar se repetir de alguma maneira.
• Os usuários não têm atenção para ler suas informações e acompanhá-las. Eles estão acostumados a ajustar o formulário de registro até que ele aceite a entrada, não até atingirem o nível ideal.
• Os usuários simplesmente não se importam.

Force uma senha segura na alteração do registro ou use um OpenId (Jeff Atwood 2c: http://www.codinghorror.com/blog/2010/11/your-internet-drivers-license.html ). Em seguida, concentre-se em funcionalidades mais interessantes.

Por um lado, os usuários estão acostumados a criar senhas seguras ou a usar seu OpenId, por isso é simples para eles.

Por que permitir senhas que você considera ruins em primeiro lugar? Interromper o problema na fonte economizará muito tempo de design, tentando descobrir quais classes de senhas são mapeadas para quais funções. Como um administrador, por definição, teria todos os direitos, você já precisaria de funcionalidade para garantir que ele não digite uma senha que o restringisse.

Minha resposta realmente se resume ao KISS .

Como usuário, isso provavelmente me convenceria a não usar seu site. Quero dizer, sério, meu banco me diz que um código de 6 dígitos é perfeitamente seguro para transações bancárias on-line, mas quando quero escrever um comentário em algum blog menos conhecido, devo lembrar uma senha única contendo pelo menos 8 - e caracteres minúsculos, um dígito, um caractere especial e um símbolo grego ou cirílico que só podem ser inseridos se você conhecer a sequência unicode de cor. E mude isso regularmente.

Não me interpretem mal, a segurança é importante. Mas se você não deve incomodar seus usuários, a menos que tenha motivos realmente fortes para acreditar que alguém tentará decifrar suas senhas para obter acesso ao seu site. Se o seu site fornecer acesso VPN à rede do FBI, vá em frente, irrite. Mas se é um fórum de usuários em que qualquer pessoa com um endereço de e-mail pode se inscrever, qual é o sentido?

Melhor solução: carinhas felizes.

Estou falando sério! Ler livros de economia comportamental como "Nudge: Improving Decisions About Health, Wealth, and Happiness" me convenceu de algumas coisas:

1. Você não pode forçar todos a tomar decisões sábias.
2. As pessoas gostam de ser livres para escolher, mas não gostam de muitas opções.
3. No entanto, você pode influenciar significativamente suas escolhas para melhor com truques simples.

Vejo que esses princípios se aplicam à sua situação assim:

1. Restringir usuários com base em senhas inseguras provavelmente os frustrará e os confundirá ... especialmente para a maioria das pessoas que não lêem as explicações cuidadosamente escritas nas caixas de diálogo e simplesmente liga para o Helpdesk para dizer: "Isso não acontece". trabalhos."
2. Ao criar senhas, os usuários não precisam ver uma lista de todas as possibilidades de caracteres especiais e, portanto, eles podem usar. Melhor mostrar a eles um pop-up sugerindo que eles adicionem alguma complexidade apenas se a entrada deles não atender aos requisitos.
3. As pessoas são fortemente influenciadas por sinais sociais - mesmo os pequenos, como rostos felizes, mostrando que aprovamos seu comportamento, ou rostos carrancudos, se não o fazemos. Alguns sites melhor projetados mostram uma barra de progresso colorida que muda de vermelho para Não é bom o suficiente :( para verde para Bom trabalho! :) , à medida que o usuário digita sua senha (proposta) e confirmação. Essa interface do usuário dá a eles alguma pressão social para atender aos padrões - fazer com que a barra fique verde ou transformar a testa franzida em um sorriso - conforme eles descobrem por si mesmos como criar senhas mais seguras com a ajuda do feedback imediato do mudanças de cor.

Para não empilhar, mas pensei em outro motivo para registrar isso em "Bad Idea" que ainda não vi mencionado - suporte ao cliente.

Se este é um produto que terá representantes de suporte ao cliente, eles não vão gostar muito disso. Uma das suposições subjacentes do suporte é que eles entendem e podem prever a experiência do usuário - se estiverem ajudando um usuário comum, a Página 1 deverá ter links para as Páginas 2, 3 e 4, onde eles podem executar X, Y, Z etc.

Agora, você está dando a eles outra variável que eles precisam acompanhar. Se o usuário não vê o link para a Página 4, é porque fez algo estúpido? Ou é porque a senha deles é péssima e seu sistema os está punindo, negando o acesso a eles? Espere ... porcaria, está negando acesso a um dos castigos por uma senha incorreta ou estou pensando em Page 5? Deixe-me procurar, apenas um momento ... ok, ele diz que, para uma senha que não combina letras maiúsculas e minúsculas, o acesso a páginas pares é permitido, mas restrito a somente leitura ... ok, senhor, sua senha, consiste em todas as letras maiúsculas ou minúsculas? Caso. Quando você apenas digita a letra, é minúscula; quando você usa turno, é quando está em maiúscula. Você misturou os casos na sua senha? A senha que você usou para fazer login no sistema. O que você acabou de usar. Ok, vá para Editar, selecione Preferências e Segurança. Selecione "Senhas salvas" ... não, senhor, não consigo ver suas senhas daqui ....

Sim. Não faça isso.

Restrinja senhas ou informe aos usuários os riscos de senhas fracas. Acho que se um usuário não se importa com os dados, você pode restringir o acesso a outros. Talvez os usuários se sintam mais confiantes se aqueles que seguem práticas de senha descuidadas são eliminados. Qual é o sentido de exigir uma senha mais forte se ela acabar com uma nota adesiva embaixo do teclado ou colada no laptop (não é possível inventar essas coisas; eu já vi isso acontecer).

e se ele pode ser localizado em uma mesa arco-íris

Eu acho que você quer dizer dicionário e não tabela de arco-íris. O ataque do dicionário funciona apenas para testar todas as palavras do dicionário, se elas corresponderem à senha. Esse ataque pode ser corrigido por 5 tentativas e bloqueado por x minutos ...

Uma tabela arco-íris só será usada se você fizer o hash da senha e o invasor souber o hash. Do que ele poderia encontrar o hash na tabela do arco-íris se fosse apenas "12345" ou algo semelhante.

Apenas para completar a viagem de ida e volta: para tornar inútil uma tabela de arco-íris, salve as senhas. E use um sal unqiue para cada senha e não apenas uma para todos. Se você fizer isso, o atacante precisará criar uma tabela arco-íris com o sal exclusivo para cada conta que ele deseja acessar. Inteligente ao seu lado, você pode incrementar o hash com o algoritmo de múltiplos hash de concatenação, para que uma geração possa demorar meio segundo. Se você fez isso, o acesso a uma conta em seu site deve valer dias, provavelmente um mês para gerar hashes para encontrar uma correspondência com essa conta ... Não consigo pensar em um invasor que tentará obter todas as senhas quando quiser. demora tanto.

Para o tempo de hash: Pense em 500ms de tempo de espera para um mecanismo de login. Eu acho que é aceitável ... (um lembrete: quase um segundo leva um aperto de mão para SSL)