A senha única baseada em HMAC (HOTP) foi publicada como um IETF RFC 4226 informativo em dezembro de 2005. Em maio de 2011, uma única vez baseada em tempo O Algoritmo de senha (TOTP) tornou-se oficialmente RFC 6238. Quais vantagens ele apresenta?
Resposta
Uma das vantagens está puramente ligada o lado humano da segurança. Do resumo da RFC 6238 “:
O algoritmo HOTP especifica um algoritmo OTP baseado em evento, onde o fator de movimento é um contador de eventos. o fator de movimentação em um valor de tempo. Uma variante baseada no tempo do algoritmo OTP fornece valores OTP de curta duração, que são desejáveis para aumentar a segurança .
(Grifo meu.)
As senhas TOTP têm vida curta, elas se aplicam apenas a um determinado quantidade de tempo humano. As senhas HOTP são potencialmente mais duradouras, aplicam-se por um período de tempo humano desconhecido.
A referência a “segurança aprimorada” faz referência a (pelo menos) duas áreas: O valor de um comprometido e capacidade de atacar uma.
Primeiro, se uma senha HOTP atual for comprometida, ela será potencialmente válida por um “longo tempo”. Garantir o uso frequente de HOTP em tempo humano não faz parte do o design HOTP, por isso não se sabe quanto tempo o atual A senha HOTP será válida para e temos que assumir o pior caso, ou seja, que será um “longo” tempo. Isso permite que o invasor use uma senha comprometida em seu lazer. Porém, se o TOTP atual for comprometido, ele não será útil por muito tempo, porque em um incremento de tempo de TOTP ele será invalidado. Obviamente, em teoria, o invasor poderia pegar e usar a senha em um tempo desprezível, mas isso impede um aspecto humano prático. Por exemplo, alguém que dá uma olhada em sua chave Paypal atual (que gira a cada 30 segundos, IIRC) não pode ir para casa e tentar usá-la mais tarde, eles teriam que correr para um computador no momento. Alguém que os comprometa a chave pode não perceber isso até que a chave tenha expirado. Etc.
Segundo, se você está atacando uma chave, seu trabalho é potencialmente invalidado ou retrocedido a cada incremento do TOTP porque o alvo foi movido. Talvez um invasor tenha descoberto um ataque contra um esquema de OTP que permite prever a próxima senha apenas se tiver algum número das últimas 10 senhas, mas leva cerca de 2 horas de tempo de computação para fazer isso. Se o OTP mudar a cada minuto , o ataque deles é praticamente inútil. Os ataques de força bruta também são inibidos, porque a próxima senha é escolhida na mesma distribuição todas as vezes; é possível usar a força bruta exaurindo o espaço da senha e não encontrar a senha. TOTP não elimina esses tipos de ataques, mas espero que limi ts quais têm a capacidade de ser eficazes.
Comentários
- Há algum caso em que o HOTP requer uma conexão com a internet enquanto o TOTP não ' t? Ou vice-versa?
- Acho que o verdadeiro desafio é conseguir tempo para SER SINCRONIZADO na extremidade do cliente junto com o servidor, no caso de TOTP.
- @JaderDias – Nenhum dos os algoritmos precisam de uma conexão com a internet
- Cada tentativa de força bruta aleatória tem a mesma probabilidade de sucesso, independentemente da rotação da senha alvo. Assim, o TOTP não ' realmente inibe ataques de força bruta: o número médio de tentativas de quebrar uma senha permanece o mesmo, mas o limite superior é removido.
Resposta
Nenhuma das duas vale a pena. A alteração dos códigos numéricos foi inventada pela RSA em 1984 para bloquear keyloggers. Mais de 90% das invasões atuais da Internet ocorrem como resultado de phishing, e estamos observando a incidência de países inteiros com mais máquinas infectadas com malware do que máquinas limpas (os bandidos do boleto embolsaram US $ 1 bilhão em dinheiro até agora, & ainda estão fortes).
TOTP e HOTP são quase completamente ineficazes contra os riscos atuais.
Você precisa de soluções que incluam autenticação mútua e transação verificação, não aparelhos de 30 anos de idade.
Comentários
- Esta resposta não faz sentido em relação à pergunta. TOTP e HOTP destinam-se a ser uma forma de autenticação (geralmente como um fator “o que você tem”, já que os valores são lidos em um token). Eles não têm nada a ver com outros aspectos do estabelecimento de um canal seguro.
- @Chris Devo estar faltando alguma coisa … como isso responde à pergunta sobre as vantagens potenciais (comparando RFC 4226 e RFC 6238)? Além disso, você declara – você tem alguma fonte confiável para fazer backup dessa declaração?(Observe que não estou pedindo um link para algum blog estranho, mas uma indicação para um ou mais artigos científicos que fornecem análises e provas da “total ineficácia” que você afirma existir.)
- @Chris: Você esqueceu a tag de fechamento:
</rant>
- @PriiduNeemre Na verdade, ele esqueceu
[8]