Sim, a comparação de strings (e/ou pesquisa de índice) pode, em princípio, vazar quantos bytes iniciais idênticos o hash de senha armazenado no banco de dados e aquele calculado do compartilhamento de senha inserido.
Em princípio, um invasor pode usar isso para aprender iterativamente um prefixo do hash da senha, byte por byte:primeiro eles encontram um hash que compartilha seu primeiro byte com o hash no banco de dados, depois um que compartilha seus primeiros dois bytes, e assim por diante.
Não, isso quase certamente não importa.
Por quê? Bem, por vários motivos:
-
Um ataque de tempo pode permitir que o invasor aprenda uma parte do hash da senha do usuário. Um esquema de hash de senha bem projetado (usando um sal e alongamento de teclas ), no entanto, deve permanecer seguro (assumindo, é claro, que as senhas em si não sejam fáceis de adivinhar) mesmo que o invasor conheça todo hash de senha. Assim, mesmo que o ataque de temporização seja bem-sucedido, as próprias senhas estarão seguras.
-
Para realizar o ataque, o invasor deve enviar senhas cujo valor de hash ele conheça. O valor do hash depende do sal. Assim, a menos que o invasor de alguma forma já conheça o sal, esse ataque não é possível.
(É verdade que, na maioria das análises de segurança de esquemas de hash de senha, o salt é considerado informação pública. No entanto, isso ocorre apenas porque tais análises assumem o pior cenário mencionado acima, onde o invasor já obteve uma cópia do todo o banco de dados do usuário, sais e hashes e tudo mais. Se o invasor ainda não conhece o hash, não há razão para supor que ele conheça o sal.)
-
Mesmo que o invasor conheça o salt, para realizar o ataque iterativo descrito acima, ele precisará gerar senhas que tenham um hash para um valor com um prefixo desejado. Para qualquer função de hash segura, a única maneira prática de fazer isso é por tentativa de erro, o que significa que o tempo necessário para fazer isso aumenta exponencialmente com o comprimento do prefixo.
O que isso significa na prática é que, para extrair um número suficiente de bits do hash para poder realizar um ataque de força bruta offline contra ele (que não precisa ser todos eles; apenas mais do que a quantidade efetiva de entropia no senha), o invasor precisa realizar o cálculo necessário para decifrar a própria senha. Para um esquema de hash de senha bem projetado e uma senha escolhida com segurança, isso não é viável.
-
O que o ataque iterativo pode dar ao invasor, em princípio, é a capacidade de fazer a maior parte do cálculo de força bruta localmente no final, enquanto envia apenas um número bastante pequeno de senhas ao seu sistema. No entanto, mesmo isso só vale se eles receberem informações de tempo detalhadas e confiáveis de cada um senha enviada. Na prática, ataques de tempo real são extremamente ineficientes , e exigem muitas consultas (geralmente milhares ou milhões) para gerar qualquer todas as informações úteis. Isso provavelmente cancelará qualquer vantagem de desempenho potencial que o ataque de temporização possa fornecer ao invasor.
Este ponto é amplificado se você usar um esquema de hash de senha de alongamento de chave adequado, pois esses esquemas são deliberadamente projetados para serem lentos. Assim, a comparação de strings no banco de dados provavelmente levará um tempo insignificante em comparação com o hashing da senha em primeiro lugar, e quaisquer variações de tempo causadas por ela serão perdidas no ruído.
