Não e absolutamente não.O contexto do artigo é fazer login em uma credencial do Google com uma chave de acesso. Os ‘3 grandes’ e também vários outros oferecem garantia e recuperação de chaves, mas os sites usam chaves de acesso diretamente – se você usar um senha com a Best Buy, eles não verificarão com o Google, por exemplo (a menos que você use ‘logins sociais’ de curso). Nesse contexto, limpar sua conta do Google significa apenas que, se o seu telefone morrer, as coisas podem ficar perigosas. Eles são basicamente um yubikey com uma opção de recuperação - um pouco menos seguros porque a chave privada existe em depósito que resolve 50% do problema com yubikeys (o preço e o suporte do aplicativo são o restante dor).Cada sistema que parece ser capaz de armazenar chaves de acesso parece exigir que você confie nos três grandes (Apple, Google, Microsoft) para não excluir sua conta sem aviso prévio. No meu caso, se a Apple excluir minha conta iCloud e as chaves, perco o acesso a tudo que está protegido por uma chave de acesso. Compare isso com o que acontece agora, se eu destruir meu Yubikey principal: vou ao meu banco, mostro dois para eles formas de identificação, use minha chave física para recuperar o Yubikey de backup do cofre e siga em frente vida.
Até e a menos que haja consequências graves e duradouras para as empresas que fornecem serviços de infraestrutura que agem unilateralmente, não usarei isso de forma alguma. KeyPass/BitWarden pode gerar senhas arbitrariamente fortes, você pode comprar quantas chaves Webauthn desejar de vários fornecedores. Com as chaves de acesso, você está a uma exclusão (automatizada e inegociável) de ser bloqueado permanentemente de toda a sua vida online.
Se você quer dar esse poder a uma empresa, fique à vontade. Vou esperar até que seja tratado como se as empresas de água ou energia cortassem o serviço sem motivo aparente: multas pesadas e dolorosas.
Não tenho certeza se entendi como um fluxo de trabalho que exigeSe você estiver copiando e colando senhas (ou digitando-as na memória, o que traz outros problemas em grande escala), você estará vulnerável ao phishing. Portanto, as chaves de acesso seriam uma grande melhoria de segurança para você.
pegando seu telefone,
acessando um aplicativo,
tirar uma foto da sua tela e
tocando no que fazer com essas informações......é uma operação "mais fácil" do que inserir uma senha da memória, preencher automaticamente com um gerenciador de senhas ou copiar e colar com um gerenciador de senhas.
Pode haver outros benefícios, mas de forma alguma é tão fácil.
Para minha conta do Google, registrei novamente minhas YubiKeys que estava usando como 2FA para serem chaves de acesso. Com 2FA, a autenticação era senha do Google + chave de hardware FIDO U2F. Com as chaves de acesso, é a chave de hardware FIDO2 + o PIN FIDO2 da chave.
Nenhuma das “três grandes” empresas de tecnologia será a guardiã de suas chaves de acesso. As chaves de acesso são mantidas em um dispositivo. Se você não quiser sincronizar sua chave de acesso por meio de algum tipo de serviço, coloque a mesma chave de acesso em vários dispositivos. Você só tem um dispositivo E agora ele acabou? Esse é o mesmo problema dos gerenciadores de senhas sem sincronização. No final, você terá que se autenticar novamente com serviços diferentes, como faria em qualquer caso semelhante de bloqueio. A maioria das pessoas sincronizará suas chaves de acesso da mesma forma que fazem com suas senhas. E não, se o Google encerrar sua conta, eles não poderão desativar as chaves de acesso que você já possui em seus dispositivos. Você perderá o serviço de sincronização, mas poderá começar a usar outro.
As chaves de acesso não podem ser roubadas, não podem ser esquecidas, não podem ser obtidas através de vazamento de dados e são inerentemente únicas e seguras. Essas são melhorias realmente grandes. Eles também são mais fáceis de usar porque, uma vez instalados no dispositivo, a autenticação é simples.
Estou usando um Yubikey para isso, não Android ou iOS. Isso significa que não estou em dívida com o Google/Apple para poder gerenciar minha chave, nem preciso me preocupar com o comprometimento de minha conta e, portanto, o vazamento da chave de acesso.
Em comparação com o login da Conta do Google, também uso este Yubikey para acessar minha conta da Microsoft há algum tempo.
A Microsoft funciona em todos os principais navegadores de desktop (exceto Safari no MacOS da última vez que verifiquei). O Google parece precisar do Chrome.
A Microsoft tem uma opção abaixo do campo de nome de usuário para fazer login de uma maneira diferente, então você seleciona Windows Hello ou Chave de segurança, coloca a chave em uma porta USB, insere o PIN e pressiona o botão na parte superior. Em seguida, ele perguntará qual conta (se você tiver várias contas salvas) e você estará conectado diretamente. Você nem precisa se lembrar do seu nome de usuário/endereço de e-mail.
O Google exige que você insira seu nome de usuário/e-mail e, em seguida, solicita que a chave seja inserida. Em seguida, você precisa inserir o PIN e ele fará o login.
Do ponto de vista da usabilidade, a Microsoft é melhor porque você não precisa se lembrar do seu e-mail. Para o público de Ars, isso provavelmente é negativo. Mas se você apoia avós de 70 anos, quanto menos coisas eles precisarem lembrar, melhor. Não confirmei, mas uma desvantagem do sistema MS é que o Yubikey suporta apenas um número específico de credenciais armazenadas, enquanto pelo que pude ver em minha pesquisa, o método do Google basicamente faz com que o Yubikey gere uma chave privada especificamente para aquele site com base em uma chave privada interna, seu PIN e algumas informações fornecidas pelo site e pelo navegador, sempre que for necessário executar o autenticação. Ambos parecem usar uma chave privada interna específica para o Yubikey, seu PIN, algumas informações sobre o domínio fornecido pelo navegador e informações específicas informações fornecidas pelo site que você está visitando para realizar o handshake, o que impede que os ataques MITM sejam bem-sucedidos, pois eles não podem falsificar tudo isso dados.
Não tenho certeza do que está faltando no Firefox para a implementação do Google versus a da Microsoft, por que ele não suporta o novo sistema de senha. Ou é apenas o Google que não solicita a chave de acesso porque o Firefox não implementou a parte Bluetooth, que tem o efeito colateral de não suportar tokens Yubikeys/hardware porque o Firefox não está sendo solicitado pelo login do Google site.
--
Se você perder a chave de acesso e não tiver uma chave de acesso de backup, a alternativa de segurança será fazer login da mesma forma que você estava fazendo login antes da chave de acesso. Geralmente senha + OTP. Embora isso signifique que o site suporta um sistema de autenticação menos seguro, uma vantagem é que você não está usando a senha regularmente, então é menos provável que ela seja vazada ou interceptada por um phishing/MITM ataque.
--
Do ponto de vista da segurança, você pode ver as chaves de acesso como uma carteira de senhas com suporte limitado do site. Se estiver usando um Yubikey, a carteira é um dispositivo de hardware no seu bolso, protegido por um PIN. Se estiver usando a chave de acesso Android/iOS, a carteira é sincronizada em um sistema em nuvem e protegida pela senha da sua conta + biometria. Se você perder o dispositivo, será semelhante a perder o arquivo de senha.
Uma vez que todos os problemas sejam resolvidos, isso terá o potencial de mudar muitas coisas no cenário da segurança, já que indivíduos não preocupados com a segurança irão não resistir mais aos requisitos de senha segura ou ter que descobrir como usar corretamente uma carteira de senha e como acessá-la/sincronizá-la em vários dispositivos. Ao se tornarem basicamente uma carteira de senhas, as chaves de acesso geram senhas realmente seguras e aleatórias para cada site em que são usadas e são criadas tendo em mente a resistência ao phishing.
Como isso pode ser rejeitado? É 100% verdade.
Isso é Quem, não o que na primeira página. Nenhum amor pelo Google na primeira página, de tal forma que o apoio deles virou a multidão contra um padrão da indústria.
É bobagem.
Novamente, leitores, não prestem atenção a esses comentaristas.
Usar uma senha não deve ser a resposta para algo que pretende substituir as senhas.
Isso é meio ridículo. De que outra forma você se autenticaria em um serviço existente para atualizar seu mecanismo de autenticação? Além do já discutido método QR e Bluetooth. E embora a superfície de ataque no lado do servidor não seja necessariamente reduzida pela ativação, em vez da exigência de login com senha, significativamente reduz a superfície de ataque do lado do cliente, pois você está estritamente envolvido em uma troca de chaves, habilitada pela autenticação no nível do sistema operacional. E isso é uma vitória para todos.
Se você chegou ao ponto de não poder confiar em nenhum dos recursos de segurança do seu sistema operacional, é melhor jogar fora seus dispositivos de computação e ir morar em uma ilha tropical ou algo assim. No algum ponto algum nível de confiança deve ser dado a algum software.
Há muita confusão aqui, acho que porque toda uma pilha de tecnologia foi despejada sobre nós e apresentada como um fato consumado. Deixe-me, como um ignorante, tentar desconstruí-lo por analogia com o que eu entendo: pares de chaves SSH. Convido outras pessoas a descobrirem o que eu erro.1. Chaves de autenticação públicas/privadas. Isso funciona quase da mesma forma que o SSH. O site conhece apenas sua chave pública e você assina mensagens para provar que possui a chave privada.
2. Proteção antiphishing. As chaves são específicas de um site, portanto, um site de phishing recebe uma chave diferente. SSH tem chaves de host para isso, presumo que o keypass tenha algo a ver com chaves de host TLS. Seu navegador usa isso para selecionar qual chave usar? Ou apenas pelo nome DNS?
3. Meios de desbloquear as chaves para provar que o usuário certo as está usando. SSH tem senhas, presumo que é aí que entra a coisa biométrica/Bluetooth? O SSH também pode desbloquear chaves com cartões inteligentes, então presumo que a biometria seja um pouco como outro modo de desbloqueio.
4. Sincronizando chaves entre dispositivos. Presumivelmente, é aqui que entram os ‘ecossistemas’ de nuvem, como a sincronização de senhas do iCloud e do Chrome? Para SSH não há suporte, mas você pode criar o seu próprio com rsync ou algo assim?
O que eu errei?
Se o que foi dito acima estiver correto, eu poderia imaginar construir uma pilha aberta que basicamente faça o mesmo que o SSH, usando uma pilha de arquivos em ~/.ssh e rsync para mover entre dispositivos. Essa é a abordagem da “bicicleta”, onde todas as partes móveis ficam expostas e é fácil entender o que está acontecendo.
Não é apenas despejado nas pessoas - esta é uma atualização do FIDO2, que é a segunda versão do padrão. U2F era FIDO1; este é o CTAP 2.2 ([editar: corrigido do meu WAG de 2.4 que estava errado, obrigado, ainda incorreto!]), parte do FIDO2/WebAuthn. Isso realmente não é nada complicado... eles afrouxaram os requisitos do autenticador para que a chave privada possa ser (deve ser...) copiada com segurança e adicionaram alguns recursos Javascript para facilitar a vida. Logins sem senha? Sempre foi possível com FIDO2. Essa é a parte interessante: FIDO1 só poderia ser MFA. Adicionando uma chave privada ao seu navegador armazenada no TPM ou elemento seguro? Sempre foi possível, e foi implementado anteriormente no Chrome, Firefox e Safari. A novidade é que ele pode ser sincronizado e acessado por meio da linguagem BT/QR. Anteriormente, elas eram chamadas (e sinalizadas em sites) como "chaves específicas da plataforma", em oposição às chaves portáteis, que eram dispositivos de hardware. Agora são as chaves de acesso.
Como o objetivo do sistema de senha parece ser livrar-se das senhas, deixe-me listar alguns dos benefícios das senhas:
- eles são simples o suficiente para serem entendidos por qualquer pessoa mentalmente capaz de operar um dispositivo eletrônico
- eles são fáceis de lembrar se você fizer algum esforço e usá-los regularmente
- eles funcionam em todos os sistemas operacionais prontos para uso
- eles não exigem acesso à Internet (alguns sistemas estão offline por um bom motivo)
- eles não exigem a cooperação de terceiros
- eles não exigem a presença de um smartphone ou outro gadget
- eles não requerem Bluetooth, WiFi, câmeras ou baterias
- eles podem - em caso de emergência - ser armazenados sem a necessidade de eletricidade
- eles podem ser facilmente transmitidos para outra pessoa sem o uso de qualquer dispositivo
- se você não é deficiente e não usa smartphone, a autenticação com senha leva apenas alguns segundos
Seus pontos 1, 2 e 10 estão simplesmente errados – pergunte a qualquer pessoa que trabalhe no suporte técnico com que frequência eles precisam redefinir a senha porque alguém esqueceu a senha, deixou a tecla Caps Lock ativada (ou posicionou a mão incorretamente no teclado) ou mexeu nela o suficiente para ficar bloqueada fora. Sim, sim, eu sei que você pessoalmente sempre acerta tudo com perfeição, mas acredite em mim, qualquer pessoa que recebe ligações para o suporte técnico tem uma visão… menos otimista… da humanidade. Acrescentarei também que suporto muitos usuários cegos e entrada de senha massivamente é uma droga para eles porque muitos sites têm requisitos de complexidade que são difíceis para usuários de leitores de tela e se você não é um digitador proficiente, dizer isso em voz alta não é ótimo. Esse é um nicho, mas muitas pessoas que constroem sistemas de autenticação também são legalmente obrigadas a oferecer um bom suporte, e é uma das razões pelas quais estou interessado em a tecnologia desde “Deseja fazer login com sua senha?” “Sim” é pelo menos uma ordem de magnitude mais rápida e fácil do que qualquer forma de senha + MFA para muitos daqueles Usuários.
O ponto 3 é verdadeiro para WebAuthn MFA, mas sempre com chaves de acesso – algo como um Yubikey funciona em qualquer lugar onde você tenha USB/NFC, mas você pode precisam definir um PIN ou usar suas chaves de série biométricas para implementadores de senha como Google.com, que exigem mais do que um simples tocar.
Os pontos 5, 6, 7 e 8 também se aplicam a todas as formas de WebAuthn – tanto MFA quanto chaves de acesso. O ponto 4 é verdadeiro, exceto na primeira vez que você registra um dispositivo ao sincronizar uma chave existente. Depois de sincronizar suas chaves pela primeira vez, você não precisará de uma conexão de rede. Se não quiser sincronizar, você também pode comprar algumas chaves biométricas Yubikey, que funcionam totalmente offline em qualquer lugar com USB ou NFC.
Isso deixa o número 9, que é uma prática ruim e deve ser evitada sempre que possível. Os sistemas modernos têm coisas como autenticação baseada em funções, onde as pessoas nunca compartilham senhas, mas várias pessoas podem assumir uma determinada função, ou coisas como legado ou delegado contas onde você nunca compartilha senhas, mas dá a uma ou, melhor ainda, a várias pessoas necessárias em combinação a capacidade de fazer algo como redefinir sua senha ou obter o controle de seus arquivos.
Só porque algo é novo e você ainda não aprendeu como funciona, não significa que seja ruim ou deva ser evitado. As chaves de acesso são uma grande mudança para a maioria de nós – exceto .gov, já que o PIV/CAC remonta ao século anterior, mesmo que em poucos outros lugares adotaram – mas eles têm uma série de melhorias de usabilidade além dos benefícios de segurança, e há um caminho claro para construir algumas das partes que faltam (por exemplo, eu realmente quero sincronizar uma chave de acesso da Apple / Google com um Yubikey para que eu possa colocá-lo no meu cofre apenas em caso).
Obviamente deve estar disponível não apenas durante a sincronização, mas também durante a autenticação, já que é utilizado para isso. E também deve estar disponível durante o registro inicial.E é isso que estou tentando explicar: seria fácil autenticar com um dispositivo existente e usar isso dispositivo para adicionar outra chave pública, que é gerada em outro dispositivo novo e enviada para o dispositivo antigo por algum significa. Por exemplo, eu poderia criar um novo par de chaves de chave secreta/chave pública em minha máquina desktop, enviar a chave pública para meu laptop, fazer login com meu laptop e adicionar a chave pública de desktop. Eu faço coisas semelhantes com SSH o tempo todo.
Não há nenhum obstáculo técnico aqui. Se isso não for possível com chaves de acesso, é por escolha própria.
A chave privada não está acessível. Por que não pesquisar em vez de repetir uma falsidade indefinidamente?
E agora estou mais confuso do que antes de começar - encaminhei o artigo para minha metade/melhor metade de CS para explicar as coisas, mas isso pode não ser suficiente.
As senhas são facilmente digeridas. 2FA é fácil de explicar. As chaves de acesso fazem sentido, mas quando penso que posso consegui-las, leio o próximo parágrafo e fico mais perdido.
Deus ajude meus irmãos e pais.
Obrigado por dizer isso. As respostas de Dan e outros (por exemplo, @Wbdcomentário promovido citando o meu) é baseado em uma leitura errada fundamental do comentário.Você percebe que tanto o 1Password quanto o Bitwarden estão trabalhando no suporte de senha, certo?Não quero confiar no meu provedor de sistema operacional (Apple, no meu caso, para dispositivos móveis e desktop) com chaves de acesso e a resposta é repetidamente "Mas você JÁ CONFIE NO GOoGLe COM SUA SENHA." Sim, tudo bem, eu insiro uma senha longa e aleatória do BitWarden/KeePass, conecto meu Yubikey e pressiono o botão. Em nenhum momento ele depende do meu provedor de sistema operacional.
E claro, agora existe a opção de não usar senhas e usar uma senha como antes, mas todo o trem da propaganda tecnológica está a caminho de "NÃO MAIS SENHAS PARA TODOS" e se eu disser, "mas espere, se eu for bloqueado em todas as outras contas porque meu provedor de sistema operacional decide que não gosta de mim, o que acontece" eu sou chamado de troll e mal informado. Também há tantos casos extremos em que consigo pensar em que isso não funciona e, em vez de dizer: "sim, aqueles são preocupações válidas no futuro somente com chave de acesso que desejamos", há esta crítica sustentada a qualquer questionando.
1Password chegou ao ponto de dizer que as chaves de acesso são “o futuro da autenticação”: https://www.future.1password.com/passkeys/
