Como de costume, leve qualquer coisa relacionada a Steve Gibson com um caminhão de sal. Attrition.org obrigatório link .

Vamos dar uma olhada na descrição de Gibson de seu protocolo.

• O código QR apresentado perto do login prompt contém a URL do serviço de autenticação para o site. O URL inclui um longo número aleatório gerado com segurança para que cada apresentação da página de login exiba um código QR diferente. (Em círculos de criptografia, esse número aleatório longo é conhecido como “nonce”.)

• O aplicativo de autenticação SQRL do smartphone criptograficamente faz o hash do nome de domínio do site digitado pelo usuário “s chave mestra para produzir um par de chaves públicas específicas do site.

• O aplicativo assina criptograficamente a URL inteira contida no código QR usando a chave privada específica do site. Como o URL inclui um número aleatório longo seguro (o nonce), a assinatura é exclusiva para esse site e código QR.

• O aplicativo emite uma consulta HTTPS POST segura para o QR URL do código, que é o serviço de autenticação do site. O POST fornece a chave pública específica do site e a assinatura criptográfica correspondente do URL do código QR.

• O site de autenticação recebe e reconhece a consulta POST retornando um HTTP padrão “200 OK” sem nenhum outro conteúdo. O aplicativo SQRL reconhece o envio bem-sucedido do código QR assinado pelo usuário.

• O site de autenticação tem a URL contendo o nonce que voltou da página de login por meio do usuário smartphone. Ele também tem uma assinatura criptográfica desse URL e a chave pública específica do site do usuário. Ele usa a chave pública para verificar se a assinatura é válida para o URL. Isso confirma que o usuário que produziu a assinatura usou a chave privada correspondente à chave pública. Depois de verificar a assinatura, o site de autenticação reconhece o usuário agora autenticado por sua chave pública específica do site.

O a maior coisa que salta para mim é o uso de uma ” chave mestra ” pelo usuário. Se estou lendo o protocolo corretamente, essa única chave mestra controla a identidade online inteira do usuário …

Presumivelmente, essa chave mestra está armazenada no telefone do usuário em um banco de dados de aplicativo. O que abre um enorme vetor de ataque na forma de malware projetado especificamente para roubar a chave mestra.

Então, vamos comparar a diferença entre o que acontece quando uma senha é comprometida e o que acontece quando a chave mestra fica comprometida. Supondo que você esteja seguindo boas práticas de senha de senhas longas, exclusivas e altamente aleatórias armazenadas em um gerenciador de senhas, tudo o que você precisa fazer é alterar uma única senha se ela for comprometida. O que acontecerá se sua chave mestra for comprometida? terá que de alguma forma obter todos os sites com os quais você se autenticou para reconhecer que sua chave mestra foi comprometida. O único problema é que você não tem nenhum outro meio de autenticação no site, como nomes de usuário ou endereços de e-mail, como o site saberá que é você mesmo que está tentando revogar a chave mestra?

Como tudo que sai da Gibson, esse esquema SRQL é altamente falho e não oferece benefícios em relação ao convencional métodos.

Comme nts

• ” Se você ‘ estiver seguindo boas práticas de senha ” é uma grande advertência, e a maioria dos internautas ‘ não o faz.Parte da promessa do SQRL ‘ é reduzir a necessidade de ‘ dos usuários permanecer no topo das práticas recomendadas. Além disso, a especificação SQRL exigirá que a chave mestra seja armazenada criptografada com uma senha mestra e será impossível usar a força bruta (ajustada para levar aproximadamente 60 segundos para uma tentativa). Obter a senha geralmente não é trivial, pois o SQRL promove a autenticação fora de banda (ou seja, o keylog de uma máquina hackeada ‘ nem sempre ajuda você). Portanto, embora as consequências do comprometimento total sejam altas, a probabilidade de comprometimento é um pouco baixa.
• SQRL ainda pode ter falhas que precisam ser corrigidas, mas afirma para resolver uma série de problemas encontrados em abordagens existentes para autenticação, e qualquer crítica ao SQRL que afirme que ” não oferece benefícios ” deve incluir refutações dessas afirmações em vez de esperar que a afirmação seja cegamente aceita.
• > Como qualquer coisa que sai de Gibson , este esquema SRQL é altamente falho e não oferece benefícios em relação aos métodos convencionais. — Isso não ‘ não parece ajudar a responder à pergunta, e eu realmente sinto que você tem problemas com a tecnologia por causa de quem a criou. Alguns dos pontos que você mencionou como falhas são, na verdade, tratados pela ” especificação “. Por exemplo, o próprio SQRL não ‘ t menciona como a chave mestra é armazenada, mas Steve Gibson ‘ os comentários sobre isso são de que um celular cliente, por exemplo, iria criptografá-lo com uma senha mestra usando uma criptografia que leva 60 segundos em média para ser executada.
• Gibson explicitamente aborda a proteção da chave mestra.
• Espere um segundo. Você equipara sua chave mestra SQRL sendo roubada a uma de suas chaves LastPass sendo roubadas. Não seria ‘ uma analogia melhor compará-lo com todo o seu banco de dados de senhas LastPass descriptografado sendo roubado?

Em geral, o protocolo não parece aumentar a segurança em relação à tecnologia existente. Se você está procurando a melhor maneira de proteger sua identidade online, sem dúvida não . Mas vamos examinar os prós e os contras:

Vantagens

É impossível ” compartilhar ” uma senha no sentido estrito de que um site malicioso não pode usar a autenticação fornecida a um site para fazer login em outro site.

Um ataque de força bruta contra o token de autenticação é não é viável.

As credenciais não são armazenadas no seu computador. Isso protege você contra um pequeno subconjunto de ataques direcionados à estação de trabalho. Especificamente, você está protegido contra ataques que roubam sua senha de seu computador. Você não está protegido contra qualquer tipo de sequestro de sessão ou ataques de controle do navegador, e agora você também está suscetível a ataques relacionados ao telefone. Mais sobre isso mais tarde.

Desvantagens

Esta técnica é perigosamente suscetível a ataques MITM e engenharia social. Provavelmente mais do que qualquer outro esquema de autenticação em uso, incluindo senhas. A etapa de autenticação e a etapa de iniciação do login são inerentemente desconectadas no sentido de que o telefone será autenticado corretamente em relação a qualquer código QR apresentado, não importa como ou onde seja apresentado ao usuário.

Então, por exemplo, um site de phishing pode exibir um código QR de login autêntico que registra o invasor em vez do usuário. Gibson está confiante de que os usuários verão o nome do banco, loja ou site no aplicativo de telefone durante a autenticação e, portanto, exercerão vigilância suficiente para impedir ataques. A história sugere que isso é improvável, e a expectativa mais razoável é que ver o nome correto no aplicativo tranquilizará falsamente o usuário, fazendo-o pensar que o site é legítimo porque foi capaz de acionar a conhecida solicitação de login no telefone. A cautela já imposta aos usuários em relação à segurança de senha não se traduz necessariamente em novas técnicas de autenticação como esta, que é o que torna este aplicativo provavelmente menos resistente à engenharia social.

Esta técnica combina autenticação e identidade em um objeto físico que é frequentemente perdido ou roubado. Nesse sentido, ” é mais como um passaporte do que uma senha. Qualquer pessoa em posse de seu telefone fica de repente exclusivamente em posse de sua identidade: não apenas o invasor pode se passar por você, mas sem uma segunda cópia em um segundo telefone ( improvável), agora você perdeu a capacidade de se identificar.As chaves de autenticação não são revogáveis, portanto, sem a recuperação fora de banda de cada site, você não pode recuperar sua identidade. E mesmo se a recuperação fora de banda existir, quando confrontado com dois usuários, um com a posse da identidade e outro sem, pode ser difícil ver por que o operador do site deve confiar em você.

Esta técnica combina todos os seus tokens de autenticação em uma única chave a menos que você crie outros manualmente. Isso torna sua chave um alvo extremamente interessante para os invasores. Além disso, a chave é armazenada em seu telefone, cujos dispositivos normalmente possuem segurança interna ridiculamente porosa. Combinar alvos extraordinariamente interessantes com segurança abaixo do padrão não o deixa seguro.

Alternativas

O aspecto mais problemático desse esquema é o quão ruim ele se compara às alternativas disponíveis.

A opção mais segura universalmente aceita hoje é lastpass, keepass e outros sistemas de senha integrados ao navegador. Em particular, a criptografia do lado do cliente alivia a necessidade de confiar em terceiros. E o mais importante, a integração do navegador torna o phishing praticamente impossível . LastPass ou KeePass só preencherá a senha se servido pelo domínio correto, o que significa que se for apresentado a um site malicioso, o usuário não terá acesso à sua senha.

Além disso, o LastPass recentemente adicionou um recurso que incita os usuários a mudarem senhas que não são globalmente exclusivas. Isso ajuda a evitar a reutilização de senhas, o que significa que o principal benefício da técnica de Gibson pode ser facilmente obtido usando esta ferramenta hoje em sites existentes, sem a insegurança adicional que seu esquema implica.

Os esquemas de autenticação de segundo fator existentes que usam telefones ou dispositivos semelhantes ajudam a proteger os logins de usuários hoje em dia, de tal forma que não o tornam imediatamente vulnerável a roubo de identidade caso seu dispositivo seja roubado. A segurança da autenticação de dois fatores reside no fato de que nem o dispositivo nem a senha podem ser usados se roubados sem o outro. A técnica de Gibson é amplamente resistente a ser incluída em um esquema de dois fatores, o que torna esse nível de proteção ção indisponível.

TL; DR:

A técnica de autenticação de Gibson não cria benefícios suficientes para superar os custos adicionais de segurança que também impõe. Esses custos são uma parte fundamental do próprio esquema e provavelmente não podem ser resolvidos sem descartar todo o projeto.

Você poderia argumentar que é melhor do que nada, mas não pode argumentar que é melhor do que qualquer coisa que já temos.

Atualizações de Gibson

Gibson anunciou recentemente alguma proteção adicional contra phishing porque esta foi uma grande crítica. A proteção deles é a seguinte: Se você NÃO estiver usando os códigos QR, telefone celular, etc. e, em vez disso, tiver um agente de autenticação em seu sistema (no navegador, por exemplo), então o servidor pode verificar se a autenticação a resposta vem do mesmo IP que a solicitação de autenticação. Isso é muito bom, mas todo o propósito deste protocolo é mover sua identidade para o seu telefone celular. Se a única maneira segura de usar o protocolo é não usar seu núcleo recurso, então talvez devêssemos repensar o que estamos tentando realizar.

Teoricamente, você poderia continuar a usar seu telefone celular se (e somente se) seu celular soubesse que estava usando o mesmo IP do seu computador. O que, é claro, ele não pode saber porque não conhece o endereço IP do seu computador.

Uma solução melhor

Como afirmado antes, se a medida de autenticação estiver em seu navegador, então todo o problema de phishing é imediatamente resolvido sem esforço ou verificação por parte de o usuário. Mesmo o usuário menos capaz não pode “ser induzido a autenticar no site errado porque o token de autenticação do site está associado ao nome de domínio e o navegador venceu” t permitir autenticação no domínio errado. Esta é uma técnica já em uso hoje, é totalmente automática, e não requer a cooperação do site ou qualquer inteligência por parte do usuário.

Este método pode ser reforçado exigindo um segundo fator de autenticação (como uma chave que varia com o tempo em um telefone celular) que, novamente, já está disponível e em uso hoje, o que o protege (principalmente) contra erros por parte do site ou empresa de destino.

Quanto às preocupações sobre a vulnerabilidade da autenticação do lado do navegador a ataques de estações de trabalho do cliente: embora o seja verdadeiro, também é verdade que se o seu navegador estiver comprometido, não o uso desse navegador é seguro , não importa qual mecanismo de autenticação você use.Os autores de malware podem (e já fazem) esperar que você se autentique por conta própria usando sua técnica super segura e, em seguida, enviar silenciosamente o tráfego necessário para ” próprio ” sua conta, tudo sem que você veja nada de errado. Nem o SQRL nem qualquer outro sistema de autenticação pode proteger o usuário de um navegador comprometido, assim como as fechaduras de porta não podem protegê-lo de um incêndio doméstico. Comprar fechaduras à prova de fogo não é uma solução.

Onde está a seguir

Se você está procurando uma garantia absoluta de proteção contra falsificação de identidade e, em seguida, olhe para o token Fido U2F. Este padrão brilha onde SQRL fica aquém e oferece imunidade garantida a ataques MITM (por exemplo, phishing). Ele faz isso autenticando não apenas o usuário, mas também o canal, para você “Temos a garantia de que (a) sua conta não pode ser autenticada sem o token, e também (b) seu token só pode ser usado para autenticar uma conexão com a máquina à qual está anexado. Consulte esta resposta para obter mais informações.

Comentários

• Sobre o primeiro ponto : pelo que eu entendi, isso foi pensado e uma opção é deixar o site no qual você está sendo autenticado ser responsável pelo redirecionamento. Portanto, após o login, você é redirecionado para a página do banco real ‘ s, não para o invasor. Sobre o segundo ponto, o mesmo acontece hoje com usuários de ferramentas como o LastPass. A menos que você configure algum mecanismo de proteção (PIN, por exemplo), todas as suas senhas também são roubadas. Por que ‘ o mesmo não pode ser verdadeiro para SQRL? Além disso, pelo que entendi pelas especificações, o usuário pode fazer backup de sua identidade até mesmo no papel (como um código QR).
• E sobre o terceiro ponto: o mesmo acontece com a maioria dos usuários que não ‘ t use um gerenciador de senhas, simplesmente usando um único nome de usuário / senha em vários sites. Ou, com usuários de gerenciadores de senha, cuja ” identidade ” está espalhada em vários sites, mas armazenada em um único local (LastPass ‘ servidores, banco de dados 1Password e assim por diante). Portanto, ‘ não é realmente uma falha de SQRL. Resumindo, quanto mais leio sobre SQRL, mais vejo os benefícios disso em comparação com as alternativas atuais. Digamos que você diga sobre Steve Gibson, mas SQRL realmente parece uma boa alternativa para mim.
• ” A cautela já bateu na cabeça de usuários em relação à segurança de senha não necessariamente se traduzem em novas técnicas de autenticação como esta. . . ” Este é um ponto excelente, e a batalha já foi perdida para o marketing. Os códigos QR são vistos como uma maneira fácil de fazer as coisas, não como um vetor de ataque potencial. Os pares de nome de usuário / senha, pelo menos, foram usados PRIMEIRO como um mecanismo de autenticação, não uma ferramenta de marketing.
• @jpkrohling: Com relação aos gerenciadores de senha, acho que a maioria dos usuários de tal software NÃO armazena sua senha mestra em seus dispositivos móveis, justamente porque sabem o quanto isso é perigoso. Tenho uma cópia física da minha senha mestra em um local seguro, mas nenhuma cópia eletrônica. Os ataques que concederiam acesso à minha senha mestra são diferentes daqueles que comprometem a senha de um site e são muito menos prováveis. (Principalmente porque atacar meu banco de dados de senhas envolveria me atacar pessoalmente, ao invés de um grande site comprometido.)
• @jpkrohling Nem o LastPass nem o KeePass armazenam uma senha mestra em qualquer lugar. Ele ‘ é usado para desbloquear o banco de dados de senha, mas não ‘ é armazenado. Isso é fundamentalmente diferente de ter uma única chave que é, ela mesma, usada em todos os lugares.

SQRL certamente não é isento de falhas, mas “é certamente superior à maioria das soluções de autenticação primária amplamente utilizadas na web hoje em termos de segurança e (e isso é importante) usabilidade. Permita-me explicar.

Equívocos

Primeiro, deixe-me esclarecer alguns dos equívocos presentes em algumas das outras respostas a esta pergunta. Muitas dessas respostas estão desatualizadas e foram escritas antes das alterações na documentação SQRL que abordam os problemas apresentados neles, enquanto outros parecem colocar ênfase indevida em falhas no SQRL que também estão presentes em muitas outras soluções de autenticação existentes amplamente utilizadas, ignorando seus benefícios. Então, vamos esclarecer alguns equívocos aqui, nós?

Mito: SQRL requer a leitura de códigos QR para funcionar

Isso simplesmente não é verdade. Os códigos QR são uma conveniência o que torna o SQRL mais fácil de usar em computadores nos quais o usuário não configurou o software cliente SQRL. O site da SQRL afirma o seguinte:

Três maneiras de ir…smartphone opcional:

Embora a inspiração original para o desenvolvimento deste sistema tenha sido um smartphone digitalizando um código QR na página de login de um site, uma pequena adição a esse modelo permite dois modos de operação mais significativos: Simplesmente tornar a imagem do código QR também um link clicável para o mesmo URL que está codificado no código QR. Isso resulta em três maneiras de fazer login:

• Digitalize o código com um smartphone: Usando o modelo descrito acima, o smartphone de um usuário verifica o código QR que aparece na página de login de um site e o usuário está logado nesse site.
• TAP O CÓDIGO em um smartphone: Para fazer login em um site NO smartphone, quando o código SQRL visual também é um link no estilo URL (usando sqrl: // como esquema), O aplicativo SQRL instalado no smartphone receberá esse link e fará o login do usuário com segurança no site no telefone.
• Clique no código em uma tela de desktop ou laptop : Para usar o sistema SQRL em qualquer sistema desktop ou laptop, um aplicativo SQRL de desktop seria instalado e se registraria para receber links sqrl: //. (Isso é semelhante à maneira como um programa de e-mail se registra para receber links mailto:). Isso permite que a mesma solução seja usada pelos usuários em seus desktops que eles estão usando em seus smartphones. Quando qualquer site oferece um código SQRL, o usuário apenas clica no código com o cursor do mouse e o aplicativo SQRL instalado localmente aparecerá, solicitará sua senha SQRL, confirmará o domínio e, em seguida, faça login.

Mito: a chave mestra SQRL é armazenada completamente descriptografada e desprotegida em seu telefone

Não sei por que algumas pessoas fizeram isso suposição, pois parece óbvio para mim que este não seria o caso. A chave mestra SQRL é protegida da mesma forma que você protegeria um banco de dados de senhas: com uma senha mestra forte. Roubar o telefone de um usuário não daria a você acesso automático à identidade online, a menos que você também tivesse a senha mestra. Mais detalhes sobre o gerenciamento de chaves são explicados na página em SQRL Client- Side Key Management no site do SQRL.

Mito: Se sua chave mestra for roubada, você não pode alterar suas credenciais de login

Isso também é falso. SQRL fornece uma maneira integrada de permitir que o titular da conta genuíno atualize suas credenciais de login no caso de uma chave comprometida. Este recurso é conhecido como Bloqueio de identidade:

“Bloqueio de identidade” impede a mudança de identidade & permite a recuperação: Isso é também significativo o suficiente para merecer sua própria página de descrição detalhada: “ O protocolo de bloqueio de identidade ” (página 4 no bloco de links na parte inferior desta página). a identidade do usuário foi estabelecida com um servidor web, o SQRL c cliente é incapaz de alterar essa identidade. Isso significa que se o pior aconteceu e uma senha muito fraca e fácil de adivinhar foi usada ou o telefone ou desktop de um usuário foi hackeado para obter sua chave mestra de identidade e senha, nenhum terceiro malicioso pode alterar a identidade online do usuário para bloqueá-lo em suas próprias contas online. E, além disso, ao carregar uma “Chave de desbloqueio de identidade” normalmente offline, o verdadeiro dono de sua identidade pode se aposentar e substituir sua identidade online perdida ou roubada para essencialmente retirá-la de qualquer invasor, tornando sua identidade anterior inútil.

Plausível: SQRL é mais vulnerável a phishing do que soluções de autenticação existentes

Ok, então isso é realmente parcialmente verdadeiro. Ao usar SQRL digitalizando um código QR, há muito pouca proteção contra phishing. A menos que o usuário tenha o cuidado de garantir que o site mostrado na barra de URL do navegador seja o mesmo exibido pelo aplicativo SQRL Client, ele pode estar autorizando uma sessão de login para o invasor. Isso ainda é melhor do que senhas, onde eles estariam dando ao phisher acesso permanente à sua conta (e qualquer outra conta que ele tenha em outro lugar que compartilhe a mesma senha) até que mudem sua senha, mas não tão bom quanto outras soluções que se integram com o navegador do usuário, como chaves U2F , WebAuthn, certificados de cliente e (sob certas condições) gerenciadores de senha.

No entanto, quando você “está usando um cliente SQRL no mesmo dispositivo com o qual está fazendo login, o SQRL tem algumas proteções contra phishing em vigor. Essas proteções são explicadas no site do SQRL, na seção Como o SQRL pode impedir ataques de phishing .Também existe a possibilidade de integrar SQRL com navegadores (possivelmente por meio de plug-ins) para fornecer proteção muito mais forte contra ataques de phishing; no mesmo nível de soluções como WebAuthn e certificados de cliente.

Em geral, classifiquei o SQRL em quase no mesmo nível que os gerenciadores de senha para proteção contra phishing. Ele tem o potencial de fornecer proteção forte contra phishing quando instalado no mesmo dispositivo em que o usuário está fazendo login, mas fornece proteção mínima quando instalado em um dispositivo diferente.

Comparação com alternativas

Agora vamos comparar o SQRL com as soluções de autenticação amplamente utilizadas.

Senhas

O SQRL é muito superior às senhas em muitos aspectos. Além de ser mais conveniente usar uma vez definida , já que os usuários não precisam se preocupar em lembrar ou redigitar várias senhas diferentes para cada site, mas também protege contra reutilização de senhas, senhas fracas, keylogging e, até certo ponto, phishing.

Desvantagens O SQRL comparou com as senhas porque é mais difícil de implementar para operadores de sites, não é tão usado, requer mais tempo para configurar inicialmente, requer algum esforço para ser transferido para um novo dispositivo e fornece um único ponto de falha para todas as contas do usuário se a chave mestra for roubada (embora este último ponto Este também é o caso das senhas se um usuário usa a mesma senha em todos os sites).

Gerenciadores de senhas

Em muitos aspectos, SQRL é muito semelhante aos gerenciadores de senhas. Ambos fornecem uma âncora de confiança única e centralizada que serve como uma espécie de proxy de autenticação entre usuários e serviços individuais. Existem algumas maneiras de o SQRL ser superior aos gerenciadores de senhas.

A principal vantagem que eu acho que o SQRL tem sobre os gerenciadores de senhas é que é mais fácil e mais seguro de usar em computadores não confiáveis ou apenas parcialmente confiáveis. Por exemplo, digamos que um usuário deseja fazer login em um site usando um computador em uma biblioteca pública. Com um gerenciador de senhas, ele teria que acessar a senha desse site em seu telefone e digitá-la manualmente no computador ou fazer o download do seu gerenciador de senhas e banco de dados de senhas no computador da biblioteca, desbloqueie o banco de dados usando sua senha mestra e faça login. O primeiro cenário é inconveniente para o usuário e expõe a senha de texto simples do usuário para aquele site ao computador não confiável (e para qualquer malware no computador não confiável, incluindo keyloggers). O segundo cenário é ainda pior, pois é inconveniente e expõe todo o banco de dados de senhas descriptografadas do usuário e a senha mestra para o computador não confiável. Com o SQRL, o usuário teria apenas que escanear um código QR na tela do computador não confiável, o que é muito mais conveniente para o usuário, e apenas expõe uma única sessão de login (sem credenciais reutilizáveis como uma senha) para o computador não confiável .

Outra vantagem do SQRL sobre os gerenciadores de senhas é que é mais fácil de se recuperar do pior cenário: o banco de dados de senhas / chave mestra do usuário sendo roubado. Com um gerenciador de senhas, você não só precisa alterar sua senha em todos os sites, você também terá que se preocupar com o invasor alterando suas senhas (possivelmente bloqueando sua conta). O invasor também tem a vantagem de possuir uma lista de todos os sites que você possui , tornando a exploração do roubo de um banco de dados de senha muito mais fácil. Com SQRL, ter sua chave mestra roubada ainda é uma situação terrível, mas o invasor não tem uma lista de sites em que você tem uma conta (tendo que adivinhar ), e não pode alterar sua senha para bloqueá-lo de sua conta. Depois de carregar sua chave de desbloqueio de identidade, também é um pouco mais conveniente alterar suas credenciais de login em cada site, já que o cliente SQRL tem a capacidade de fazer isso para você automaticamente para cada site que você visitar após o login. (Não há necessidade de ir por meio de qualquer formulário de “alteração de senha”.)

Finalmente, acho que o SQRL tem uma pequena, mas importante vantagem sobre os gerenciadores de senhas no que diz respeito ao objetivo de substituir totalmente as senhas, que os sites têm a opção de impor uso de SQRL em vez de senhas tradicionais. Contanto que os usuários ainda tenham a opção de segurança insatisfatória, reutilizando a mesma senha em todos os sites, isso ainda acontecerá. Se o SQRL começar a ganhar ampla adoção, os sites podem realmente começar a abandonar o uso de senhas. Isso não pode ser feito com gerenciadores de senhas, pois eles dependem do uso de senhas para funcionar.

Em termos de desvantagens, na verdade não consigo pensar em uma situação em que SQRL seria necessariamente pior do que gerenciadores de senhas em termos de segurança. A principal desvantagem do SQRL é que ele requer suporte dos operadores de sites, enquanto os gerenciadores de senhas não requerem suporte especial dos serviços existentes. Isso significa que você pode começar a usar gerenciadores de senha agora, mas o SQRL terá que esperar até que os sites o implementem antes de poder ser usado. Esta é uma barreira significativa para a adoção.

Certificados de cliente

A principal vantagem que o SQRL tem sobre os certificados de cliente é a conveniência. Os certificados de cliente são atualmente complicados de configurar, difíceis de transferir entre computadores e têm problemas de privacidade quando o mesmo certificado é usado em sites diferentes. Embora, teoricamente, pudéssemos construir um sistema usando certificados de cliente que resolveria esses problemas, também haveria o problema de integração deficiente com UIs de sites e servidores da web, que são problemas mais difíceis de resolver. Não vou entrar em muitos detalhes aqui, pois já existe um excelente artigo sobre questões de usabilidade de certificados de cliente em browserauth.net.

Em termos de segurança, os certificados de cliente têm a desvantagem de exigir o envolvimento de uma CA. Isso é (potencialmente) caro e requer confiança na CA de terceiros. Além disso, se você optar por ignorar os CAs e, em vez disso, autoassinar seus certificados, terá que lidar com o problema da revogação do certificado. Os certificados de cliente também têm os mesmos problemas de segurança e conveniência que os gerenciadores de senha quando os usuários desejam fazer login em um computador não confiável; eles têm que transferir seu certificado para o computador não confiável, o que é inconveniente e potencialmente expõe sua identidade mestre a malware nesse computador.

Em suma, até que alguém apareça com uma solução melhor e amigável usando certificados de cliente que resolvem (pelo menos a maioria) esses problemas, não acredito que certificados de cliente sejam um sério concorrente para SQRL (ou, nesse caso, para senhas).

Autenticação de 2 fatores

Apenas pensei em mencionar o seguinte: SQRL e autenticação de 2 fatores não são mutuamente exclusivas. SQRL é uma substituição para o primeiro fator em 2FA: senhas. Outras medidas adicionais, como códigos OTP ou chaves FIDO U2F, ainda podem ser usadas com SQRL.

WebAuthn

Agora aqui está onde as coisas ficam interessantes. WebAuthn é um novo (bem, mais recente que SQRL) padrão W3C projetado para fornecer uma API padrão que os sites podem usar para autenticar usuários com chaves públicas na web. Assim como SQRL, ele suporta usando o telefone do usuário para autenticar uma sessão de login em um dispositivo externo , além de alguns outros métodos de autenticação (como chaves de segurança de segundo fator) .

É aqui que o SQRL finalmente encontra seu par, pelo menos de uma perspectiva de segurança. O WebAuthn não apenas fornece todas as mesmas proteções contra reutilização de senha, senhas fracas e keylogging que o SQRL, mas também fornece proteção ainda mais forte contra phishing, integrando-se ao navegador do usuário mesmo ao autorizar um login sessão para um PC em que o usuário não configurou anteriormente o software cliente do autenticador. Isso é possível porque, nessa situação, o WebAuthn se comunica com o navegador do usuário diretamente usando protocolos de comunicação bidirecionais como Blutooth ou NFC, em vez de se comunicar com o site que o usuário está usando por meio de um código QR unilateral.

Do ponto de vista da usabilidade, as coisas são um pouco mais complicadas. Pelo menos na superfície, o WebAuthn vence novamente. Por ser um padrão W3C que já tem implementações em vários navegadores , em teoria os usuários podem começar a usar o WebAuthn imediatamente sem a necessidade de instalar nenhum software de terceiros. Na prática, porém, a maioria das implementações do WebAuthn existentes se concentram em seu uso como uma forma de autenticação de segundo fator ou como uma forma de reautenticar um usuário que fez login anteriormente no mesmo dispositivo por meio de um método de login diferente (geralmente uma senha). Como um fator de autenticação principal, o WebAuthn ainda carece de implementações viáveis.

Outras considerações menores incluem o fato de que o SQRL tem uma construção método t-in para girar as chaves das contas no caso de uma chave mestra roubada, enquanto o WebAuthn depende de sites para implementar seu próprio sistema de revogação de chaves e o fato de que WebAuthn requer determinado hardware opcional (como Bluetooth ou NFC) para para se autenticar em uma máquina remota, enquanto o SQRL pode funcionar em qualquer máquina com uma tela funcional.

No geral, acho que é muito provável que o WebAuthn acabe tornando o SQRL obsoleto. SQRL pode ter um pouco de espaço para respirar por enquanto, mas WebAuthn tem um apoio muito mais forte de fornecedores de navegadores, operadores de sites e outras organizações terceirizadas (como o W3C). Assim que o WebAuthn obtiver algumas implementações que permitem seu uso como um fator de autenticação principal, espero que comece a dominar a web muito rapidamente.

Advertências

SQRL ainda está em desenvolvimento ativo, portanto, o material apresentado nesta resposta está sujeito a alterações. Conforme o desenvolvimento continua, espero que algumas das vulnerabilidades e incertezas nesta resposta sejam abordadas. A maior parte da discussão está acontecendo no grupo de notícias SQRL em grc.com.

SQRL é uma solução conveniente para o problema do nome de usuário / paradoxo da senha. (ou seja, a compensação de conveniência / segurança) sem usar um terceiro . Ele fornece uma alternativa simples para o modelo de autenticação mais popular (nome de usuário & Senha), sem virtualmente comprometer a segurança. É praticamente tão seguro quanto qualquer um dos modelos de autenticação comuns usados hoje, contanto que você ainda esteja preocupado com a segurança . Se você estiver usando SQRL, isso não significa que você não pode seguir as melhores práticas de segurança, como combinando isso com autenticação multifator para contas importantes.

É importante não perder o ponto do SQRL. O próprio SQRL não fornece necessariamente melhor ou pior segurança. Se o computador / telefone for comprometido ou o usuário for enganado sendo phishing, então este é um ataque de canal lateral em vez de uma falha direta do próprio SQRL. Todo método de autenticação convencional tem este problema de ataques de canal lateral O teclado único inquebrável também é vulnerável a ataques de canal lateral como o comprometimento do próprio pad ou segurança ou implementações inadequadas.

Se você ouviu a proposta original da ideia em Steve Gibson “s podcast , seguido pelo Q & A “s, muitas das questões levantadas neste thread da pilha foram respondidas. Além disso, o próprio Steve disse que essa idéia muito “simples” e “engenhosa” (palavras dele) precisaria ser “examinada” e “martelada” por especialistas em segurança, pois só o tempo dirá se essa é uma solução segura.

Em conclusão, a maioria dos argumentos contra o SQRL está fora do domínio do próprio SQRL e, em vez disso, são problemas com humanos praticando segurança insuficiente. SQRL não introduz uma nova classificação de problemas que nossos métodos de autenticação tradicionais já não apresentam.

SQRL é excelente se usado apropriadamente por pessoas que estão preocupadas com a segurança. Você deve entender que sempre há uma compensação entre conveniência e segurança , e esta solução é provavelmente a melhor equilíbrio dos dois que já vi.

Comentários

• Obrigado Ansichart. Mas as ‘ soluções de autenticação existentes não podem simplesmente manter recursos de segurança iguais ou superiores ao SQRL e usar a automação para aumentar a conveniência do usuário? Qual propriedade fundamental da conveniência do usuário de SQRL ‘ s não se deve à automação? Eu pergunto porque se um usuário tem duas caixas pretas que fazem a mesma coisa; um rotulado como ” Maduro ” e o outro rotulado ” SQRL ” e eles podem ser projetados / automatizados e têm a mesma interface / botões na parte externa da caixa – que valor agregado o SQRL fornece?
• Ele resolve o problema do paradoxo da senha sem ter que usar um terceiro.
• Entendo. Portanto, se alguém não ‘ quiser o risco de terceiros de logon único e não ‘ gerar / armazenar suas senhas com um gerenciador de senhas, SQRL pode aumentar. Mas se SQRL for uma caixa preta móvel que pede uma senha para desbloquear a chave mestra usada para regenerar / armazenar SQRLIDs e, em seguida, realizar o link de canal de retorno do cliente ‘ s cookie / QR session_id com servidor ‘ s SQRLID gravado para login – como isso é uma caixa preta móvel diferente de um gerenciador de senha móvel com login automático através do mesmo canal posterior; ou um plug-in de certificado de cliente móvel de duas partes com login & de geração automática através do mesmo canal de apoio?
• Fiz algumas edições importantes em minha postagem original após algumas segundas considerações e uma leitura mais detalhada do que outros têm dito, pois posso ter exagerado. Suponho que ter o telefone celular como a chave central muda o problema e tornaria mais importante ter uma segurança mais forte em seu telefone. Steve Gibson também menciona isso na Q & Um podcast.

SQRL não fornece melhorias inovadoras. Os códigos QR são um formato de código de barras óptico útil para distribuição de conteúdo curto – nada mais.

Qualquer situação de “login automático” que o SQRL esteja tentando resolver poderia simplesmente usar um certificado de cliente armazenado no celular.

Hipoteticamente, um código de barras QR em uma página HTTPS poderia retornar uma versão assinada ou criptografada do certificado do cliente (ou uma credencial semelhante) conforme conhecido anteriormente pelo servidor, mas por quê? Para expiração de credencial? O site poderia simplesmente rejeitar uma credencial expirada diretamente.

Portanto, o maior problema de segurança que tenho com isso protocolo é: Reinventando a roda quadrada .

Update

Lendo novas respostas e comentários, gostaria de salientar como é fácil fazer algo semelhante ao SQRL através automação simples de tecnologia existente madura :

1. O site pede a qualquer CAPTCHAs ou verificação “sou um humano” semelhante. Assim que o usuário tiver cumprido (POSTAR), o site retorna um erro HTTP 403.7 - Client Certificate Required ou vanilla 403.
2. As páginas 403 personalizadas são fáceis de configurar e podem ser muito bonitas e fáceis de usar. Pode até inicializar a funcionalidade exigida abaixo de uma maneira semelhante aos prompts “necessários do Adobe Reader” em muitos sites.
3. A página 403 personalizada inclui algumas marcações às quais um plugin de navegador personalizado reage. Vamos chamar este plugin personalizado de “compatível com S403L” no espírito de “conformidade com SQRL”.
4. O plugin S403L gera um certificado de cliente padrão, que é protegido no cache de certificado de navegador criptografado usual (ou um terceiro cache de terceiros se a criptografia de armazenamento de chaves do seu navegador for uma falha). O plug-in cria um CSR padrão para o certificado do cliente e envia o CSR para o URL especificado na marcação 403. (por exemplo, <s403l ref="https://www.example.com/S403L" />)
5. O servidor compatível com S403L usa o session_id do usuário (recuperado de cookies ou string de consulta) para criar continuidade com a Etapa 1 e então retorna o CSR assinado pelo servidor. A autenticação geral do servidor aceitará qualquer certificado de cliente que foi assinado pelo servidor (e, portanto, atendeu aos critérios de registro exigidos na Etapa 1).
6. O plugin S403L armazena aquele certificado de cliente assinado no cache do navegador. em seguida, o navegador padrão sem assistência de plug-in pode fazer o “login automático” no servidor no modo SSL / TLS padrão até que o certificado expire.

A natureza “móvel” e “visual” de SQRL é uma espécie de desorientação, pois não fornece autenticação de dois fatores separada e agora você precisa de dois computadores para navegar na Internet em vez de um. A menos que você aponte a webcam USB de sua área de trabalho para seu próprio monitor.

As compensações entre senhas e certificados são bem definidas na comunidade de segurança: senhas cabem em um cérebro humano; certificados não cabem um cérebro humano ( geralmente ), mas pode ter entropia louca e bons recursos de gerenciamento de PKI (expiração , revogação, extensões de política, etc.). SQRL não se encaixa perfeitamente em nenhum acampamento; e se ele está se voltando para o campo menos humano e mais computador, como parece – são anos de desenvolvimento e análise de segurança para repetir os recursos existentes do X.509.

Comentários

• > poderia simplesmente usar um certificado de cliente armazenado no celular.— exceto que essa tecnologia existe há anos tanto em dispositivos móveis quanto em desktops e ‘ não é tão difundida como se desejaria. E, ao contrário do certificado do cliente, o SQRL não ‘ exige que você prove sua identidade real para criar uma ” Identidade do SQRL “. Se desejar, você pode criar quantas identidades quiser. Isso significa que a vantagem em comparação com os certificados do cliente é que você tem anonimato do lado ‘ do protocolo de autenticação.
• @jpkrohling É um equívoco comum que os certificados do cliente exigem divulgação de identidade para uso. Esse é um requisito das autoridades de assinatura comercial para usar suas cadeias de confiança globalmente intercambiáveis. Na prática, um certificado de cliente pode ser simplesmente um CSR anônimo criado pelo cliente e assinado por um servidor específico, após atender a quaisquer critérios desejados (CAPTCHAs, conta anterior, etc). Os certificados também podem ter uma expiração embutida. Type 40-L Códigos de barras QR podem despachar / armazenar o certificado de cliente X.509 de 1 KB, se desejado.
• Ok, é verdade, que erro. Nessa perspectiva, o cliente (aplicativo móvel, por exemplo), pode estar gerando um certificado de cliente para cada site que o usuário está cadastrando. Isso parece mais caro do que hash de algumas informações, mas pode ser uma solução interessante. Em qualquer caso, ainda não ‘ concordo com suas afirmações de que SQRL é pior do que inútil.
• Talvez eu tenha sido duro com esse texto e irei removê-lo. Mas eu não ‘ não vejo o SQRL como outra coisa senão uma maneira mais sexy de distribuir credenciais de cliente negociadas; e um que não ‘ não resolveu alguns dos problemas sutis tratados por esquemas de autenticação maduros. Um gerenciador de senhas é entediante (eu não ‘ não me incomodo com a integração do navegador porque sou ‘ sou paranóico), mas sei que apenas eu e um compartilhe cada senha única em meu armazenamento de chaves criptografado. Não ‘ não preciso me preocupar com novos esquemas hash / auth, apenas a qualidade do PRNG / TRNG que meu gerenciador de senhas usa para gerar senhas.
• @LateralFractal quem se importa se ‘ é novo ou não? O SQRL permite autenticação amigável, onde a primeira parte não expõe seu segredo à segunda parte ou a terceiros que possam ter comprometido a segurança ‘ da segunda parte. É ‘ uma tentativa de resolver um problema do mundo real que, até agora, ninguém mais foi capaz de resolver.

Eu gostaria de responder à primeira pergunta: “um dos problemas em que posso pensar é se o leitor de QR está comprometido, exibir www.google.com em vez de www.nsa-super-secret-place.gov/123 “:

A chave mestra é usada como semente no HMAC junto com o endereço do site (FQDN). Portanto, embora o código QR possa codificar URL completamente diferente, o protocolo NÃO revelará o código de autenticação que normalmente seria enviado para www.google.com (no exemplo).

Em segundo lugar, muitos dos contribuidores esquecem os principais objetivos ao desenvolver essa ideia:

1. anonimato por não usar terceiros
2. facilidade de uso
3. não há necessidade de digitar credenciais secretas em computadores não confiáveis

Eu acredito que os protocolos abordam isso por completo!

No entanto, existem compromissos que na verdade vêm do primeiro obectivo. Se nenhum terceiro estiver envolvido na autenticação, como alguém pode revogar seus detalhes de autenticação? Além disso, a segurança da chave mestra é uma preocupação óbvia. Eu imagino que isso seja bem protegido por futuros dispositivos móveis em um chip como o HSM. Até então, a chave é apenas um dispositivo móvel de pin de arquivo, protegido por uma senha, embora o PBDKF2 garanta que seja muito lento para realmente fazer força bruta.

Comentários

• Mais uma vez, o que ‘ há de novo nessa ideia? Parece-me uma variação primitiva do extinto Windows CardSpace.
• Sim, você está certo sobre o CardSpace. Depois, há o U-Prove, também propriedade da Microsoft. A questão é como você usaria o CardSpace ou o U-Prove em um computador que você não confia (cibercafé ou computador de um amigo). Isso é o que Steve adicionou.
• Ah, ok, isso ‘ é o que eu estava perdendo. Ainda concordo com @TerryChia que este é um não iniciador sem um mecanismo de revogação para as chaves do usuário.
• @Xander Há um mecanismo de revogação para as chaves do usuário. grc.com/sqrl/idlock.htm