Devo impor um comprimento máximo às senhas?

162

Entendo que impor um comprimento mínimo às senhas faz muito sentido (para salvar os usuários deles mesmos), mas meu banco exige que as senhas tenham entre 6 e 8 caracteres e comecei a me perguntar ...

Isso não facilitaria apenas os ataques de força bruta? (Ruim)
Isso significa que minha senha está sendo armazenada sem criptografia? (Ruim)

Se alguém com (esperançosamente) alguns bons profissionais de segurança de TI trabalhando para eles estiver impondo um tamanho máximo de senha, devo pensar em fazer algo semelhante? Quais são os prós / contras disso?

security encryption passwords

— nickf
fonte

16

Quase certamente existe uma política de "três ataques e você está fora", que elimina a ameaça de um ataque de força bruta.

— Stu Thompson

23

Não há desculpa para isso para sistemas não herdados, como sites modernos.

— mparaz

7

Não acho que a resposta seja puramente TI. O tamanho mínimo (6) e um limite máximo de tentativa são "prováveis" de eliminar suposições malucas. Meu palpite é que o tamanho máximo (8) é limitar o número de chamadas (e, consequentemente, o custo) do suporte para "Opa, eu esqueço meu código" ou "Digito o código rapidamente" ou "Digito incorretamente um caractere" Além do papel no qual você escreve a senha, se não conseguir se lembrar dela.

— me ligue Steve

17

A universidade matriculada possui regras de senha insensatamente estúpidas: apenas 8 caracteres, pelo menos 1 número, mas não no começo ou no final da senha, precisa de caracteres de mais de 2 linhas superiores do teclado etc. etc. No final eles facilitam a aplicação de força bruta por ter essas regras -.-. Sei que você não é tão estúpido, mas por favor, não faça regras tolas assim! (Só tinha de tirá-lo do meu sistema :))

— cwap

17

@call Bem, se você impor um comprimento máximo por essa razão, então você vai ficar "Esqueci minha senha" chamadas de mim , porque minhas senhas de sites única são todos muito tempo, e limitando-me a 12 caracteres é uma maneira de garantir que vou não me lembro.

— Roman Starkov

193

As senhas são divididas em hash para 32, 40, 128, qualquer que seja o tamanho. O único motivo para um tamanho mínimo é evitar senhas fáceis de adivinhar. Não há finalidade para um comprimento máximo.

O XKCD obrigatório que explica por que você está fazendo um desserviço ao usuário se você impõe um tamanho máximo:

— epochwolf
fonte

6

Talvez um banco possa optar por limitar a senha, porque nos caixas eletrônicos você não pode inserir mais do que, digamos, 8 caracteres.

— André Chalella 19/09/08

11

bem, pelo menos nos caixas eletrônicos, se você tentar um ataque de força bruta, ele comerá seu cartão. Estou me referindo à senha para fazer logon apenas online.

— nickf

39

Infelizmente, isso pressupõe que as senhas sejam sempre hash. As senhas de comprimento máximo são um sintoma das senhas armazenadas em texto sem formatação.

— Jevon

14

Suspiro, mesmo em PayPal, "cavalo correta da bateria grampo" é de 8 caracteres acima de sua <censurado> comprimento máximo ... headdesk

— Roman Starkov

3

@kleinfreund porque, se fosse hash, o tamanho da senha não importaria para eles (as funções hash convertem uma string de qualquer tamanho em um comprimento fixo).

— Vicky Chijwani

75

Um comprimento máximo especificado em um campo de senha deve ser lido como um AVISO DE SEGURANÇA . Qualquer usuário sensível e consciente da segurança deve assumir o pior e esperar que este site esteja armazenando sua senha literalmente (ou seja, sem hash, conforme explicado pelo epochwolf).

Nesse caso, é o caso:

Evite usar este site como uma praga, se possível. Eles obviamente não sabem nada sobre segurança.
Se você realmente deve usar o site, verifique se sua senha é única - diferente de qualquer senha usada em outro lugar.

Se você estiver desenvolvendo um site que aceite senhas, não coloque um limite de senhas tolas, a menos que queira ser tarado com o mesmo pincel.

[Internamente, é claro que seu código pode tratar apenas os primeiros 256/1024 / 2k / 4k / (o que) bytes como "significativos", para evitar triturar senhas gigantescas.]

— atrasado
fonte

17

Também envio a esses sites um e-mail padrão, mencionando que eles me forçaram a usar uma senha mais curta e menos segura, que também reutilizo em todos os sites que impõem limites tolos. Isso permite que eles saibam que é um problema e também pode dar a Joe Coder alguma vantagem para mostrar aos superiores: evidência de que os usuários realmente pensam mal do site como resultado disso.

— Roman Starkov

3

Não sei se você deve supor que uma senha máxima significa que eles estão armazenando senhas em texto sem formatação. Às vezes, eles estão truncando a entrada e simplesmente passando os primeiros x caracteres para o hash (). (A maneira de verificar é definir uma senha além do limite e, em seguida, tente fazer login com uma variação dos caracteres da senha além do comprimento máximo).

— benc

5

@ Benc claro, isso é possível, mas o ponto é que, como usuário, você não tem como saber se é isso que eles estão fazendo. Um comprimento máximo (especialmente um curto) é um sinal de aviso e acho melhor assumir o pior (ou entrar em contato com o provedor para que ele confirme).

— tardate

1

Por favor elabore. Esta resposta é uma mera afirmação.

— kleinfreund

1

Uma senha máxima não significa necessariamente que está sendo armazenada como texto simples; pode ser por motivos técnicos, por exemplo, o bcrypt permite apenas senhas com até 72 caracteres.

— emorris

58

Permitir um comprimento de senha completamente ilimitado tem uma grande desvantagem se você aceitar a senha de fontes não confiáveis.

O remetente pode tentar fornecer uma senha tão longa que resulta em uma negação de serviço para outras pessoas. Por exemplo, se a senha tiver 1 GB de dados e você gastar todo o seu tempo, aceite-a até ficar sem memória. Agora, suponha que essa pessoa envie essa senha a você quantas vezes você desejar aceitar. Se você não tomar cuidado com os outros parâmetros envolvidos, isso pode levar a um ataque de negação de serviço.

Definir o limite superior para algo como 256 caracteres parece excessivamente generoso para os padrões atuais.

— Jason Dagit
fonte

35

Você ainda pode enviar 1 GB de dados com um limite máximo. O software que limita quase sempre fica atrás do servidor da web.

— epochwolf 19/09/08

6

Você ainda pode descartar todos, exceto os primeiros 256 caracteres, antes de fazer algo computacionalmente intensivo. A execução de um hash sha em 1 gb de dados levará muito mais tempo que o mesmo hash em 256 caracteres.

— Rcreswick 19/09/08

2

@Eyal: tudo o que acontece no lado do cliente de um aplicativo da web é inerentemente não confiável; assim, o hash se torna um equivalente de senha, tornando este um exercício de futilidade. (um navegador da web provavelmente não aceita uma entrada de texto de 1 GB e um cliente personalizado pode enviar uma sequência de 1 GB no campo de formulário "thisisthehashedpassword")

— Piskvor saiu do prédio em

4

@Iskvor: Mas não há como impedir a string de 1 GB. Um usuário sempre pode solicitar example.com/?password=abcabcabcabc ... e fazer com que sua solicitação seja tão grande quanto ele desejar. DoS padrão.

— Eyal

4

@Piskvor e Eyal, felizmente, Apache e IIS (e presumivelmente outros servidores maduros) limitar o comprimento dos campos passados via URLs: boutell.com/newfaq/misc/urllength.html

— sampablokuper

21

Primeiro, não presuma que os bancos tenham bons profissionais de segurança de TI trabalhando para eles. Muitos não .

Dito isto, o tamanho máximo da senha é inútil. Muitas vezes, exige que os usuários criem uma nova senha (argumentos sobre o valor do uso de senhas diferentes em todos os sites, por enquanto), o que aumenta a probabilidade de que eles simplesmente as anotem. Também aumenta bastante a suscetibilidade ao ataque, por qualquer vetor da força bruta à engenharia social.

— Sparr
fonte

Acordado! Olhe para que a cadeia de banco do Reino Unido on-line falhas de nos últimos anos segurança de acesso ...

— Stu Thompson

6

Eu já uso uma senha diferente em todos os sites através de um esquema que me permite lembrar de todas, mas todas são bastante longas. Os únicos websies cujas senhas eu escrevo em notas adesivas são aqueles que impõem limitações idiotas de comprimento máximo e, assim, me afastam da minha senha preferida e única ...

— Roman Starkov

@romkyns Acho que o seu esquema não usa símbolos? Tive um esquema desse tipo uma vez que produziu senhas curtas de força bruta, mas tive que abandoná-lo quando 10 a 20% dos sites que utilizava proíbem caracteres especiais comuns.

— Sparr

sem caracteres especiais, não, mas sempre adiciona números e caracteres maiúsculos, porque eu sabia que alguns sites exigem isso. Gostaria de saber sobre os limites máximos de comprimento quando o criei ... Mas os esquemas (mais simples) que eu criei para parentes próximos funcionaram perfeitamente até agora!

— Roman Starkov

1

@romkyns outros problemas com esses esquemas: sites que compartilham senhas. Se o seu esquema é algo como nameofwebsitefO0 (googlefO0 yahoofO0 etc), como você se lembra que deveria usar "yahoofO0" no flickr.com ou stackoverflowfO0 no askubuntu.com? sites que expiram senhas. você precisará estender o esquema para incluir uma parte que pode ser alterada. mas isso falhará se a regra de expiração verificar substrings.

— Sparr

13

Definir o tamanho máximo da senha com menos de 128 caracteres agora é desencorajado pelo OWASP Authentication Cheat Sheet

https://www.owasp.org/index.php/Authentication_Cheat_Sheet

Citando o parágrafo inteiro:

Senhas mais longas fornecem uma combinação maior de caracteres e, consequentemente, tornam mais difícil para um invasor adivinhar.

O comprimento mínimo das senhas deve ser imposto pelo aplicativo. Senhas menores que 10 caracteres são consideradas fracas ([1]). Embora a imposição de tamanho mínimo possa causar problemas na memorização de senhas entre alguns usuários, os aplicativos devem incentivá-los a definir senhas (frases ou combinação de palavras) que podem ser muito mais longas que as senhas típicas e muito mais fáceis de lembrar.

O tamanho máximo da senha não deve ser definido muito baixo, pois impedirá que os usuários criem senhas. O tamanho máximo típico é de 128 caracteres. As frases secretas com menos de 20 caracteres geralmente são consideradas fracas se consistirem apenas em caracteres latinos minúsculos. Cada personagem conta !!

Verifique se todos os caracteres digitados pelo usuário estão realmente incluídos na senha. Vimos sistemas que truncam a senha com um comprimento menor do que o usuário forneceu (por exemplo, truncado com 15 caracteres quando inseriu 20). Geralmente, isso é tratado ao definir o tamanho de TODOS os campos de entrada de senha como sendo exatamente o mesmo tamanho da senha de tamanho máximo. Isso é particularmente importante se o tamanho máximo da senha for curto, como 20 a 30 caracteres.

— kravietz
fonte

11

Esta fonte não desencorajar limites máximos de comprimento de palavra-passe, que desencoraja baixo (menos do que 128 caracteres) limites de comprimento máximo de senha.

— Matthew

9

Um motivo que posso imaginar para impor um tamanho máximo de senha é se o front-end deve interagir com muitos back-end do sistema legado, um dos quais impõe um tamanho máximo de senha.

Outro processo de raciocínio pode ser que, se um usuário for forçado a usar uma senha curta, é mais provável que ele invente uma tagarelice aleatória do que um slogan ou apelido facilmente adivinhado (por seus amigos / família). Obviamente, essa abordagem só é eficaz se o front-end aplicar números / letras misturadas e rejeitar senhas que possuam qualquer palavra do dicionário, incluindo palavras escritas em linguagem L33t.

— mbac32768
fonte

1

Embora compreensíveis, os sistemas legados às vezes precisam ditar o design. Sempre que possível, eles NÃO devem influenciá-lo. A última coisa que você deseja em um novo sistema é aquele com uma política de segurança projetada antes dos ataques de segurança modernos serem comuns. Ou pior, software mais recente, mas projetado incorretamente em primeiro lugar. Um sistema corporativo existente pode usar HTTP, mas isso não é justificativa para não usar SSL em um novo sistema ou extensão. Da mesma forma, as políticas de senha não devem continuar vulneráveis apenas porque os ÚLTIMOS caras fizeram errado. E, se mantendo, é melhor que haja um ENORME estudo de custo / benefício.

— Katastic Voyage

6

Um motivo potencialmente válido para impor um tamanho máximo de senha é que o processo de fazer o hash (devido ao uso de uma função de hash lento como o bcrypt) leva muito tempo; algo que poderia ser abusado para executar um ataque do DOS contra o servidor.

Por outro lado, os servidores devem ser configurados para descartar automaticamente os manipuladores de solicitações que demoram muito tempo. Então, duvido que isso seja um grande problema.

— AardvarkSoup
fonte

4

Eu acho que você está muito certo em ambos os pontos. Se eles estão armazenando o hash das senhas, como deveriam, o tamanho da senha não afeta o esquema do banco de dados. Ter um tamanho de senha aberto gera mais uma variável que um invasor de força bruta deve ter em conta.

É difícil encontrar uma desculpa para limitar o tamanho da senha, além do design inadequado.

— Lucas Oman
fonte

3

O único benefício que posso obter com um tamanho máximo de senha seria eliminar o risco de um ataque de estouro de buffer causado por uma senha muito longa, mas existem maneiras muito melhores de lidar com essa situação.

— DrStalker
fonte

1

Deve haver um comprimento máximo de entrada, sim, mas definitivamente não deve ser <64. Um comprimento máximo de 8 ou 12 é ridículo.

— precisa saber é o seguinte

2

Ignore as pessoas que dizem para não validar senhas longas. Owasp diz literalmente que 128 caracteres devem ser suficientes. Apenas para dar espaço suficiente à respiração, você pode dar um pouco mais, digamos 300, 250, 500, se quiser.

https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Password_Length

Comprimento da senha As senhas mais longas fornecem uma combinação maior de caracteres e, consequentemente, tornam mais difícil a adivinhação de um invasor.

...

O tamanho máximo da senha não deve ser definido muito baixo, pois impedirá que os usuários criem senhas. O tamanho máximo típico é de 128 caracteres . As frases secretas com menos de 20 caracteres geralmente são consideradas fracas se consistirem apenas em caracteres latinos minúsculos.

— CommonSenseCode
fonte

Não é relevante para a discussão. A questão é se há algum benefício em limitar o comprimento e não se 128 é suficiente.

— vikki 28/01

1

O armazenamento é barato, por que limitar o tamanho da senha. Mesmo se você estiver criptografando a senha, em vez de apenas hash uma cadeia de 64 caracteres, não será necessário muito mais do que uma cadeia de 6 caracteres para criptografar.

Provavelmente, o sistema bancário está sobrepondo um sistema mais antigo, de modo que eles só foram capazes de permitir uma certa quantidade de espaço para a senha.

— LizB
fonte

9

A menos que exista um motivo muito válido, as senhas devem ser colocadas em hash. Hashes resultam em cadeias de comprimento fixo. Não há argumentos de espaço a serem apresentados, a menos que o sistema esteja armazenando a senha real, o que é sem dúvida uma péssima idéia.

— Stu Thompson

8

Criptografar senhas é uma péssima idéia. Um funcionário sem escrúpulos é o suficiente para você vazar um zilhão de senhas. Salve o problema, nunca os armazene em primeiro lugar.

— Roman Starkov

1

Meu banco também faz isso. Ele costumava permitir qualquer senha, e eu tinha uma de 20 caracteres. Um dia eu mudei, e eis que ele me deu um máximo de 8 e tinha cortado caracteres não alfanuméricos que estavam na minha senha antiga. Não fez nenhum sentido para mim.

Todos os sistemas de back-end do banco funcionavam antes quando eu estava usando minha senha de 20 caracteres com caracteres não alfanuméricos, portanto, o suporte ao legado não pode ter sido o motivo. E mesmo que fosse, eles ainda devem permitir que você tenha senhas arbitrárias e, em seguida, crie um hash que atenda aos requisitos dos sistemas legados. Melhor ainda, eles deveriam consertar os sistemas legados.

Uma solução de cartão inteligente não iria bem comigo. Já tenho muitas cartas ... Não preciso de outro truque.

— Vincent McNabb
fonte

Eles cortam um espaço de chave importante que aumenta o tempo para ataques de força bruta quando (e quero dizer QUANDO) seu banco de dados de hashes é roubado (supondo que eles até salt / hash / stretch, o que eu tenho certeza que não). Hora de trocar de banco.

— 22714 Chris Gomez

1

Se você aceitar uma senha de tamanho arbitrário, será assumido que ela está sendo truncada no tamanho de uma cortina por motivos de desempenho antes de ser hash. O problema do truncamento é que, à medida que o desempenho do servidor aumenta com o tempo, você não pode aumentar facilmente o comprimento antes do truncamento, pois seu hash seria claramente diferente. É claro que você pode ter um período de transição em que ambos os comprimentos sejam hash e verificados, mas isso usa mais recursos.

— Do utilizador
fonte

1

Tente não impor nenhuma limitação, a menos que seja necessário. Esteja avisado: pode e será necessário em muitos casos diferentes. Lidar com sistemas legados é uma dessas razões. Teste bem o caso de senhas muito longas (seu sistema pode lidar com senhas longas de 10 MB?). Você pode enfrentar problemas de negação de serviço (DoS) porque as funções de defivação de chave (KDF) que você usará (geralmente PBKDF2, bcrypt, scrypt) levarão muito tempo e recursos. Exemplo da vida real: http://arstechnica.com/security/2013/09/long-passwords-are-good-but-too-much-length-can-be-bad-for-security/

— Marek Puchalski
fonte

0

Deveria haver um comprimento máximo? Esse é um tópico curioso da TI, pois senhas mais longas geralmente são mais difíceis de lembrar e, portanto, mais propensas a serem escritas (um grande não-não por razões óbvias). Senhas mais longas também tendem a ser esquecidas mais, o que, embora não seja necessariamente um risco à segurança, pode levar a problemas administrativos, perda de produtividade etc. Os administradores que acreditam que esses problemas estão pressionando provavelmente impõem comprimentos máximos às senhas.

Pessoalmente, acredito nessa questão específica, para cada usuário. Se você acha que consegue se lembrar de uma senha de 40 caracteres, ainda mais poder para você!

No entanto, as senhas estão rapidamente se tornando um modo de segurança desatualizado, cartões inteligentes e autenticação de certificados se tornam muito difíceis de impossibilitar a força bruta, como você afirma ser um problema, e apenas uma chave pública precisa ser armazenada no servidor com o serviço privado. sempre em seu cartão / computador.

— tekiegreg
fonte

As pessoas podem se lembrar facilmente de uma letra de música favorita, versículo da Bíblia ou outro ditado. Essas são muito longas em comparação com uma senha típica. Acabei de testar um e entrei com 79 caracteres! (Concedido, a possibilidade de um erro sobe quanto mais tempo uma senha é ainda pior quando um site ESTÚPIDO não mostrar-lhe o último caractere digitado na caixa de senha..)

— Katastic Voyage

0

Senhas mais longas, ou senhas, são mais difíceis de decifrar simplesmente com base no comprimento e mais fáceis de lembrar do que exigir uma senha complexa.

Provavelmente é melhor optar por um comprimento mínimo razoavelmente longo (10+), restringindo o comprimento inútil.

— benPearce
fonte

0

Os sistemas legados (já mencionados) ou a interface de sistemas externos do fornecedor podem exigir o limite de 8 caracteres. Também poderia ser uma tentativa equivocada de salvar os usuários deles mesmos. Limitá-lo dessa maneira resultará em muitas senhas pssw0rd1, pssw0rd2 etc. no sistema.

— Mandril
fonte

0

Uma razão pela qual as senhas não podem ser hash é o algoritmo de autenticação usado. Por exemplo, alguns algoritmos de resumo exigem uma versão em texto sem formatação da senha no servidor, pois o mecanismo de autenticação envolve o cliente e o servidor executando as mesmas contas na senha inserida (o que geralmente não produz a mesma saída sempre que a senha é combinado com um 'nonce' gerado aleatoriamente, que é compartilhado entre as duas máquinas).

Muitas vezes, isso pode ser fortalecido, pois o resumo pode ser parcialmente calculado em alguns casos, mas nem sempre. Uma rota melhor é que a senha seja armazenada com criptografia reversível - isso significa que as fontes do aplicativo precisam ser protegidas, pois contêm a chave de criptografia.

O Digst auth existe para permitir a autenticação em canais não criptografados. Se estiver usando SSL ou alguma outra criptografia de canal completo, não será necessário usar mecanismos de autenticação Digest, o que significa que as senhas podem ser armazenadas em hash (pois as senhas podem ser enviadas em texto sem fio pela conexão com segurança (para um determinado valor de segurança).

— Chris J
fonte

-4

Apenas 8 palavras-passe longas parecem simplesmente erradas. Se deveria haver um limite, pelo menos 20 caracteres é melhor idéia.

— user17000
fonte

3

Mas é isso - não deveria haver um limite.

— Luke Stevenson

-4

Eu acho que o único limite que deve ser aplicado é como um limite de 2000 letras, ou qualquer outra coisa insinentemente alta, mas apenas para limitar o tamanho do banco de dados se isso for um problema

— Josh Hunt
fonte

9

As senhas devem ser hash ... E o tamanho do banco de dados não seria um problema, pois a senha é hash.

— epochwolf 24/09/08

4

@epochwolf - Posso pensar em uma razão pela qual as senhas não deveriam sempre ser hash (porque eu a descobri hoje): uma senha que precisa ser enviada a terceiros em nome do usuário não pode ser armazenada como hash valor. [Por exemplo, um aplicativo que precisa para armazenar credenciais para enviar e-mails através de um domínio externo.]

— Kenny Evitt