Yeah, I agree that aspect of it seemed quite problematic to me as well from the beginning. And he obviously cannot include the email in the hash. So it’s better to just disallow the top x most common passwords, which we already have. (Though it’s not updated on the fly as the list changes over time.)
2 curtidas
What would really solve the issue here, in my humble opinion, would just to apply best practices like preventing an IP to try to login more than X times without success, don’t let people try passwords at non human time ( humans don’t try a password every 1 sec ) would fix the security issue without forbidding all the passwords.
The way I see is, someone can make a list that gives all the combinations of A-Z 1-9 up to X length. This means nothing if you can’t brute force the target, unless it’s a targed attack and then there’s not much you can do.
Is anything like that currently implemented?
Yes, there is extensive rate limiting across the whole of Discourse. By default login attempts are limited to 6 per minute and 30 per hour (per IP).
9 curtidas
Hmm, can you extrapolate here though? It would seem to me that the distribution of lengths might be quite different if you focus on the 1 mil most common ones since those will obviously tend to be shorter.
1 curtida
I think it’s a good idea to alert the user but maybe not prevent them from using the password if they insist. Explain it better, maybe something along the lines of
“The encrypted version of this password has been found in a public database of stolen user information and may put your account at increased risk of being hacked by brute force attacks. If you use this password across multiple web services we strongly recommend changing them to unique passwords to stay secure, especially for mail accounts.”
And let them hit submit a second time to use it anyway.
hopefully webauthn will make passwords a thing of the past someday 
2 curtidas
Isso não faz sentido para mim (daí o bump no tópico): uma vez que se sabe que uma senha foi quebrada (ou encontrada em texto plano), ela fica significativamente menos segura. Isso representa uma enorme redução na entropia, mesmo com suposições muito permissivas:
- uma senha aleatória de 10 caracteres, mesmo com um conjunto de caracteres muito limitado (exemplo de espantalho: apenas letras minúsculas: Pr = 1/26^10 = 1/1,4e14)
- uma senha que se sabe estar presente na lista do HIBP (Pr = 1/5e8)
no momento em que outra pessoa a usou e ela também foi violada e/ou decodificada — diferença crucial.
Qual é o problema prático em impedir o uso de uma senha que apareceu em apenas uma lista? Como usuário, definitivamente gostaria de saber disso para evitar usar essa senha novamente. Como administrador de site, não quero que meus usuários utilizem senhas comprometidas. Isso parece valer muito a pena em troca da usabilidade.
Não, não é uma diferença crucial porque, estatisticamente, todas as senhas serão violadas com o tempo.
Lembre-se de que já bloqueamos as um milhão de senhas mais comuns há anos, então você já está protegido nas questões que realmente importam.
3 curtidas
Estatisticamente, todos os algoritmos de criptografia e hash serão quebrados com o tempo. Assim que surgir o primeiro indício de que um algoritmo está próximo de ser quebrado, deixamos de usá-lo.
Por que as senhas deveriam ser diferentes? Toda segurança é uma aposta de que a entropia utilizada é suficiente para a tarefa em questão, e sempre há uma suposição sobre o comprimento ou a intensidade do ataque que pode ser suportada.
Considerando que você perde pelo menos 6 ordens de grandeza de entropia na primeira vez que uma senha aparece em uma lista (na realidade, provavelmente várias a mais), essa parece ser uma decisão fácil.
Sim, essa é uma situação muito melhor do que a existente em muitos outros pacotes de software disponíveis hoje. O HIBP ainda representa uma boa melhoria para sites que desejam garantias adicionais além disso.
Parece uma oportunidade para um botão
Por que gerar a senha no servidor?
Considerando que o usuário precisará salvá-la, não faria mais sentido deixar a responsabilidade da geração da senha a cargo do usuário? O gerenciador de credenciais de sua escolha provavelmente já faz isso.
2 curtidas
Porque pode ser melhor do que ficar dizendo continuamente que “apple”, “apple1”, “apple 123”, “apple 12345” não são aceitáveis sob a lista de 1 milhão de senhas proibidas. Pessoalmente, não esperaria muito essa funcionalidade no Discourse, mas se isso puder lidar de forma mais elegante com o problema das senhas comprometidas e deixar nas mãos do usuário o que fazer se algo der errado, talvez valha a pena considerar.
E você está sugerindo que gerenciadores de senhas do lado do cliente gerarão senhas como essa?
Incentivar seus usuários a usar um gerenciador de senhas será muito mais eficaz do que impor uma senha de um único site. O último apenas levará os usuários a usar essa mesma senha em todos os outros lugares, acelerando sua comprometimento.
Consertar a burrice é mais difícil do que consertar o que foi invadido. Manter as mãos com algo semelhante a https://www.useapassphrase.com/ joga um osso para aqueles que não se interessam pela parte acadêmica, na minha opinião.
Construí sistemas utilizados por dezenas de milhões de pessoas e já testamos diversas abordagens relacionadas a senhas, incluindo aquelas terríveis que exigem que a senha contenha x e y.
A menos que você eduque os usuários sobre gerenciamento de senhas, você só aumenta a probabilidade de fadiga de senhas, reutilização e o temido “post-it embaixo do teclado”.
Gerar senhas no servidor também cria um novo vetor de ataque e uma superfície que precisa ser protegida. Pessoalmente, eu poderia viver sem TODOS os itens acima.
3 curtidas
Eu pensaria que o JS geraria uma senha aleatória no lado do cliente, depois a hash e a compararia com uma lista. A parte educacional pode ser um stub acima de “Crie uma senha para mim”. Na verdade, não acho que isso seja algo com que o Discourse precise se preocupar, mas, desde que as pessoas estejam atribuindo a raiva por seus próprios comportamentos à marca, talvez valha a pena considerar.
Acho que sua melhor opção, então, é desenvolver ou encomendar um plugin que faça o que você sugere.
1 curtida
Isso é exatamente para o que este plugin serve.
Refleti sobre isso por um tempo desde que escrevi este plugin e acabei concordando com o Jeff.
“Violado” significa que alguém, em algum lugar, pensou nessa frase que apareceu em “uma lista”. Imagine se alguém criasse uma ferramenta que:
- Fizesse uma lista de strings pública.
- Gerasse e anexasse sistematicamente strings únicas à lista.
O argumento do Jeff é que isso significa que, eventualmente, todas as strings estarão “inseguras” porque aparecerão em alguma lista pública em algum lugar — e, com o tempo, sua frase de senha “super segura” também aparecerá nessa lista em constante expansão.
Toda a ideia de senhas em si depende apenas da “improbabilidade estatística” de alguém não conseguir adivinhar uma senha para sua conta. Um atacante tecnicamente não precisa saber a senha; ele só precisa fazer um muito bom palpite. Eles podem inclinar isso a seu favor ao considerar o que significa fazer um “bom palpite”:
- Se tiverem uma violação, tentem a mesma senha para a mesma conta.
- Se tiverem uma lista de violações, tentem as senhas que muitas pessoas usam.
Já discutimos como o Discourse é bom no item #2 acima. Acredito que o que você está tentando abordar é o #1, mas ter algo assim no núcleo (assumindo que nenhuma senha, não vinculada ao nome de usuário, deva ser usada) é desnecessário e um pesadelo de usabilidade… Mas se você deseja o que está descrevendo para seu site, este é o plugin para você.
4 curtidas
Sim. Francamente, esse é um argumento terrível, pois está completamente desconectado de qualquer noção de probabilidade, que é a única maneira correta de raciocinar sobre isso.
Felizmente, estamos falando de um caso extremo que só aparece depois de descartar as senhas mais comumente usadas, o que já é, por si só, uma estratégia bastante boa.
1 curtida