- Com o aumento do uso de MFA, o Microsoft Authenticator pode bloquear usuários ao sobrescrever contas existentes por causa de uma nova conta TOTP adicionada por QR code
- O ponto central do conflito está no design que usa apenas o label para diferenciar contas, em vez de usar issuer e label juntos, como fazem Google Authenticator, Okta e outros
- Como a sobrescrita não fica evidente de imediato, o usuário pode só enfrentar impossibilidade de acesso semanas ou meses depois, ao tentar acessar a conta existente
- As alternativas são usar outro app autenticador ou inserir manualmente a Secret Key, mas isso é pouco prático para usuários comuns em ambientes corporativos
- A Microsoft afirmou que é um comportamento intencional e que fornece uma mensagem de aviso; depois, citou a ausência de issuer por parte de alguns emissores, deixando apenas a possibilidade de melhorias futuras
Como o escaneamento de QR sobrescreve contas MFA existentes
- Ao adicionar uma nova conta por escaneamento de QR, o Microsoft Authenticator pode sobrescrever uma conta existente com o mesmo nome de usuário
- Como endereços de e-mail são muito usados como nome de usuário, é comum que contas MFA de vários serviços compartilhem o mesmo label
- O Google Authenticator e a maioria dos outros apps autenticadores usam também o nome do issuer, como um banco ou uma montadora, para evitar conflitos
- O Microsoft Authenticator não usa o issuer em conjunto e identifica a conta apenas pelo nome de usuário
- Após a sobrescrita, podem surgir problemas de autenticação tanto na conta recém-criada quanto na conta existente que foi sobrescrita
Bloqueio cuja causa é difícil de perceber
- Quando ocorre o bloqueio, o usuário pode confundir a causa com um problema da empresa que forneceu a autenticação, e não do Microsoft Authenticator
- Como resultado, helpdesks corporativos acabam gastando tempo para resolver uma situação que não foi causada por eles
- É difícil verificar facilmente qual conta foi sobrescrita
- O fato de a conta existente ter desaparecido pode não ficar evidente até o momento em que o usuário tentar usá-la novamente
- Esse momento pode chegar semanas ou meses depois
Alternativas e reclamações antigas
- A alternativa mais simples é usar outro app autenticador em vez do Microsoft Authenticator
- Também é possível evitar o problema inserindo manualmente a Secret Key, em vez de escanear o QR code
- O problema parece não ocorrer em contas de autenticação pertencentes a contas Microsoft
- A CSO Online encontrou reclamações sobre esse problema que remontam a 2020, e o problema em si parece existir desde junho de 2016, quando o Microsoft Authenticator foi lançado
- Em 2020, um usuário mencionou uma alternativa de inserir manualmente a Secret Key do Identity Provider, mas considerou que lidar com strings aleatórias dessa forma não ajudaria o usuário final médio em um ambiente corporativo
Sobrescrita reproduzida em campo
- O consultor de TI australiano Brett Randall viu participantes de uma sessão de treinamento de fornecedor escanearem QR codes de MFA com o Microsoft Authenticator e sobrescreverem chaves TOTP de outros aplicativos
- Segundo Randall, um QR code de MFA cria uma string com vários valores, e outros apps combinam label e issuer para formar o ID exclusivo dessa chave
- Em vez desse comportamento padrão, o Microsoft Authenticator usa apenas o label, que normalmente é um endereço de e-mail
- A última chave TOTP que usa o mesmo endereço de e-mail pode ser sobrescrita pela nova chave
- Randall afirmou que foi quase impossível fazer a Microsoft reconhecer esse problema e tomar providências
Reação de especialistas em segurança e TI
- A CSO Online pediu que vários especialistas em segurança e TI reproduzissem o problema, e todos conseguiram
- Gary Longsine, fractional CTO da IllumineX, vê isso como uma falha de design e disse que não recomendaria o Microsoft Authenticator
- Tim Erlin, VP de produto da Wallarm, disse que ocorre um conflito ao adicionar um segundo item com o mesmo endereço de e-mail e que, depois da sobrescrita, não é possível saber qual conta foi sobrescrita
- Erlin comentou que o problema pode ser menos conhecido do que realmente é porque os usuários talvez não saibam a causa
- David Meltzer, chief product officer da Netography, reproduziu o problema e o considerou um bug claro, relativamente simples para a Microsoft corrigir
- Kimberly Samra, porta-voz do Google, respondeu que o Google Authenticator não sobrescreve códigos e que isso é uma decisão explícita
Posição da Microsoft e mensagem de aviso
- A Microsoft confirmou o problema, mas afirmou que não é um bug, e sim um comportamento intencional
- Na primeira posição por escrito, a empresa explicou que, quando o usuário escaneia um QR code, recebe uma mensagem de confirmação antes de uma ação que pode sobrescrever as configurações da conta
- O texto real do aviso é: “This action will overwrite existing security information for your account. To prevent being locked out of your account, continue only if you initiated this action from a trusted source.”
- A mensagem orienta o usuário a prosseguir se ele próprio iniciou a ação e se a origem é confiável
- Quando o usuário começa o escaneamento de QR em um serviço legítimo, como banco ou hotel, as duas condições geralmente são atendidas
- Ao seguir a instrução, a sobrescrita da conta pode ocorrer
- A janela de aviso não oferece uma forma de evitar a sobrescrita além de desistir da tentativa de autenticação
Disputa de responsabilidade em torno da ausência de issuer
- Depois, em uma segunda declaração mais longa, a Microsoft explicou que alguns sites ou fornecedores não incluem o issuer — isto é, o nome do site ou do Identity Provider — no label
- Se houver uma conta existente com o mesmo label, o app pode tentar sobrescrevê-la com a conta TOTP recém-escaneada
- A Microsoft afirmou que, nessa situação, o usuário sempre recebe uma mensagem de confirmação de sobrescrita e pode escolher se deseja continuar
- A frase “continuamos melhorando o produto e levaremos isso em consideração para melhorias futuras” foi a única parte que sugeriu a possibilidade de a Microsoft corrigir o problema
Comparação com outros apps autenticadores
- Randall vê duas formas de impedir que usuários finais sobrescrevam acidentalmente chaves de outros apps
- Auditar o otpauth de todos os aplicativos e convencer cada empresa a corrigir suas implementações incorretas
- A Microsoft fazer uma única correção para que a mesma preocupação não exista no futuro
- Randall disse que testou o mesmo comportamento de conflito em 14 outros apps autenticadores, mas nenhum se comportou como o Microsoft Authenticator
- Os apps testados incluíram Google Authenticator, Okta Verify, Duo Mobile, LastPass Authenticator, 2FA Authenticator, Twilio Authy, Salesforce Authenticator, OneAuth, ForgeRock Authenticator, Authenticator 7, Authenticator App, Auth0 Guardian, OTP Auth e Authenticator 2FA Sentinel
1 comentários
Opiniões do Hacker News
É um pequeno exemplo que realmente ilustra o grande problema da segurança sem usabilidade
Basta pensar nas coisas absurdas que passamos em nome da “segurança”: troca obrigatória e periódica de senha, regras insanas de senha, requisitos não documentados que você precisa descobrir por tentativa e erro, mensagens de erro complexas cheias de jargão de segurança, “perguntas secretas” cujas respostas você não lembra, e por aí vai
Só que a segurança desses próprios sistemas é toda furada, como uma peneira. Vazamentos de dados e exposição de informações aparecem nas notícias quase todos os dias, e muitas vezes fico me perguntando como continuam passando impunes
Durante meses, toda vez que eu fazia login, precisava usar “encontrar minha conta” e, a cada vez, redefinia o nome de usuário de volta para meu endereço de e-mail. Era natural, já que por quase 10 anos essas tinham sido minhas credenciais de login
A restrição de que não era possível usar
@ou.no nome de usuário nunca era aplicada até a hora do login, e só depois de meses acabei descobrindo que precisava trocar para outro valorA conta original era do ING Direct, depois virou Capital One 360 e então foi totalmente integrada ao restante da bagunça do Capital One; acho que esse problema do nome de usuário também tem a ver com isso
Site: “Escolha uma senha complexa com pelo menos 8 caracteres, incluindo caracteres especiais e números”
Abro o gerenciador de senhas e fico satisfeito ao gerar uma senha aleatória de 128 caracteres
Na visita seguinte, o site: “Digite o 31º, o 98º e o 102º caractere da sua senha”
Era um site britânico de financiamento imobiliário
Pensando agora, para fazer isso eles precisam estar armazenando a senha em texto puro ou, no mínimo, criptografada de forma reversível, em vez de hash, para poder descriptografá-la a qualquer momento
Tento de novo pensando que talvez fosse a senha criada por uma versão antiga do algoritmo, e também falha. No fim clico em redefinir senha, recebo o e-mail, clico no link e coloco como nova senha a senha gerada pelo algoritmo; então aparece “esse caractere especial não pode ser usado”
Quando, seguindo minhas regras, troco aquele caractere especial pelo próximo caractere, desta vez aparece “não é possível redefinir usando a senha atual”
Pelo que lembro, havia coisas como “palavras proibidas”, “não reutilizar as últimas 24 senhas”, “exclusão de alguns caracteres especiais”, “5 perguntas de segurança” e vários outros requisitos de senha
Ninguém sabe se as respostas das perguntas de segurança diferenciam maiúsculas de minúsculas
Havia até um texto dizendo que era preciso certificar que as informações de criação da conta eram verdadeiras e que você era a pessoa em questão, e que fornecer informações falsas ou enganosas poderia resultar em multa, prisão ou ambos
Usar quatro ou mais palavras de dicionário dá uma excelente segurança de senha, e a mesma abordagem pode ser usada para respostas de perguntas de segurança. Também existem muitos gerenciadores de senhas gratuitos e pagos, que resolvem o problema de ter de lembrar todos os valores secretos. Eles também são bons para fazer backup de segredos de autenticação em duas etapas
Se uma “mensagem de erro complexa” é um erro que se espera que o usuário corrija por conta própria, seria melhor retornar um erro genérico com um ID único e mandar a pessoa entrar em contato com o suporte. Uma bomba de jargões é irritante, mas parece mais uma incapacidade humana comum de explicar erros do que um problema específico de segurança
A maioria das organizações, mesmo quando o negócio como um todo é bem-sucedido, estraga muitas coisas ao mesmo tempo, e segurança é uma delas. Em uma organização grande o bastante, acho difícil evitar que pessoas incompetentes façam coisas incompetentes
Isso não faz sentido em vários níveis. Quer dizer que o Microsoft Authenticator armazena os itens apenas com base no rótulo? Ele nem cria alguma chave interna?
E depois afirma que o problema é o site colocar o emissor no campo issuer, onde deveria estar, em vez de no rótulo?
Fico me perguntando se alguém na Microsoft realmente usa o próprio Authenticator. A menos que eu esteja deixando passar algo, no momento em que você usa um e-mail em um site, não consegue adicioná-lo em outro, então parece que ele seria inutilizável em quase todos os aplicativos
Mas a versão para iOS tem barra de busca. Não faço ideia do porquê
Dentro do enorme repositório Piper, provavelmente já deve existir uma biblioteca de busca local que poderia ser enfiada em uma única lista de alterações, embora ela não seja um modelo de linguagem grande
E acho que muita gente simplesmente não usa
No entanto, encontrei um problema de UI que pode fazer o usuário ver um código errado. Os códigos das primeiras contas visíveis na tela são atualizados a cada 30 segundos, mas os códigos que estão fora da tela não são atualizados
Ao rolar para trazer um código que estava fora da tela, aparece um código antigo e, em um caso, ele estava 4 ciclos atrás do código correto
Curiosamente, recebi da Microsoft um e-mail que parecia phishing, mas aparentemente não era
O conteúdo dizia “Ação necessária: habilite a autenticação multifator no seu tenant até 15 de outubro de 2024”, e afirmava que eu o estava recebendo por ser “administrador global”, mas só havia um UUID, sem nome da organização
O aviso dizia que, a partir de 15 de outubro de 2024, MFA seria exigida para login no portal do Azure, no centro de administração do Microsoft Entra e no centro de administração do Intune, e que eu deveria habilitar MFA até lá. Se não conseguisse, deveria solicitar o adiamento da data de aplicação
O problema é que não administro nenhuma organização na Microsoft. Só tenho algo como uma conta pessoal Office365 Family, e a conta já está com autenticação em duas etapas configurada
O e-mail não tinha meu nome nem o suposto nome da organização, só um ID, então não faço a menor ideia do que significa. Ainda assim, o e-mail realmente veio da Microsoft
Depois de criar contas do Gmail, perdi algumas ao trocar de país e de computador. Ao tentar fazer login, o Google dizia que a senha estava correta, mas que o dispositivo e o IP eram desconhecidos
Não me lembro exatamente por que a recuperação pelo endereço de recuperação não funcionou, mas falhou mesmo eu ainda tendo acesso ao endereço de e-mail de recuperação. Talvez eu tivesse que informar ao Google qual era o endereço de recuperação, e eu posso ter usado um sufixo
+aleatório nesse endereçoAntigamente eu usava o Google Authenticator na conta do Gmail, mas desativei por medo de acrescentar mais um ponto de falha em uma situação em que o Google não oferece praticamente nenhuma saída
A senha tem mais de cerca de 96 bits de entropia; gero 256 bits a partir de
/dev/urandom, transformo em um inteiro de precisão múltipla e, comdivmod, escolho um caractere de cada conjunto — números, minúsculas, maiúsculas e símbolos —, depois escolho o restante de todo o alfabeto e, com a entropia restante, rodo um embaralhamento Fisher-Yates para que o primeiro caractere nem sempre seja um númeroÉ uma senha por site, armazenada em um gerenciador de senhas baseado em gpg que fiz por conta própria no início dos anos 2000
A autenticação multifator ajuda em alguns comprometimentos ativos em andamento, mas não ajuda contra dumps de hashes de senhas resultantes de vazamentos de bancos de dados. É realmente angustiante não conseguir recuperar pelo endereço de e-mail de recuperação mesmo sabendo a senha
Se eu não fiz login em lugar nenhum por alguns meses e tenho a senha correta, no mínimo deveriam enviar um link ou código de verificação para o endereço de recuperação, em vez de exigir que eu diga qual é esse endereço. Não precisam revelar para onde estão enviando, mas transformar o endereço de recuperação em mais uma senha que preciso memorizar é muito irritante
Já não confio ao Google nada além dos dados que já entreguei e dos que sou obrigado a entregar
Como tenho uma mudança internacional prevista, preciso acelerar a transferência da minha vida de e-mail para uma conta paga que estou testando, o Proton Mail, antes que surja um problema sério
Na época em que o Gmail parecia inocente, quando a administração pública começou a migrar para o online, comecei a fornecer o Gmail como contato para impostos, saúde, órgãos públicos e afins. Isso funcionou bem e, ao longo de várias mudanças internacionais, o Gmail se tornou uma ferramenta administrativa importante
Tenho contas inativas espalhadas por aí, mas nelas ainda podem restar assuntos importantes que talvez eu precise algum dia. Por exemplo, autorizações de viagem para a Austrália válidas por alguns anos
Mesmo depois de a vigilância em massa acelerar, o Gmail ainda parecia relativamente inofensivo, e quase não havia segredos reais ou intimidade profunda ali além do fato de eu lidar com determinadas instituições
Mas agora que a administração online se tornou praticamente obrigatória e os outros meios foram reduzidos ao mínimo, o Gmail está central demais de um jeito desconfortável. Por causa das coisas preocupantes que bots automatizados fazem com usuários inocentes, sem misericórdia nem possibilidade de recurso, não tive escolha a não ser começar a migração
Está tão disseminado que não tenho tempo suficiente para procurar tudo, e contas esquecidas exigem escavar memórias vagas, o que parece tortura. Mesmo assim, preciso fazer isso
Não quero que minhas filhas gêmeas fiquem à mercê dos bots do Google quando chegarem à idade em que precisarão de e-mail para assuntos oficiais
toProvavelmente eu poderia falar com o administrador para redefinir, mas é bem desagradável manter a conta praticamente refém até que eu entregue informações pessoais
Eu vinha usando o da Microsoft por causa da conta de trabalho. Afinal, ele está profundamente integrado ao Office365, então não havia motivo para não usar
Nunca vi uma caixa de diálogo dessas, e as contas que adicionei não tiveram problemas. Como é conta de trabalho, em 99% dos casos compartilho meu e-mail corporativo como nome da conta
Então isso quer dizer que tive sorte porque os sites que usei forneciam rótulos suficientemente únicos? Sinto que não entendi completamente qual é exatamente o problema
No fim o tempo passa, e isso não é algo que põe comida na mesa da minha família; é só uma chateação de ter que fuçar para descobrir o que fazer para conseguir fazer login. Então decidi usar o da MS, que era obrigatório no emprego anterior
Já perdi tempo demais mexendo nessas coisas em vez de fazer algo significativo ao usar contas online
A verificação de identidade online como um todo é gravemente pouco confiável e cheia de grandes buracos e riscos ainda maiores, e estamos construindo a vida inteira em cima disso
Durante décadas houve danos sérios por causa das fragilidades das senhas, mas ainda usamos senhas e tentamos remendar com curativos ou uma demão de tinta
Quase toda semana algum sistema online vaza enormes quantidades de dados pessoais fáceis de explorar, e mesmo assim ficamos sentados como o meme do cachorro tomando café no meio da sala em chamas, dizendo “está tudo bem, está tudo bem”
Dizem que, se usarmos uma senha diferente de pelo menos 8 caracteres para cada sistema, estaremos seguros, e seguimos acreditando que vai ficar tudo bem
Se essa é a expectativa, os produtos da Microsoft colocariam o emissor no rótulo por conta própria, então não haveria problema
O problema surge ao usar outro provedor que usa o mesmo e-mail como identificador, mas coloca o emissor no campo issuer, que existe justamente para armazenar o emissor. É como se isso fosse uma coisa estranhíssima de se fazer
O Safari também tinha um bug parecido, que sobrescrevia passkeys sem nenhum aviso e fazia você ficar completamente bloqueado fora da conta. Depois foi corrigido, mas por causa disso perdi acesso ao GitHub
https://bugs.webkit.org/show_bug.cgi?id=270553
O Safari ainda tem um bug em que não consegue distinguir sites hospedados em subdomínios diferentes, exceto por exceções hardcoded, e sobrescreve a senha de um subdomínio com a de outro. Passo por isso todo mês
Mas eu não sabia que essa estupidez ia ainda mais fundo
É exatamente por isso que a autenticação multifator por SMS é popular entre os usuários, mesmo tendo vulnerabilidades de segurança
Em geral, ela é boa o suficiente, desde que você não seja alvo de um ataque de SIM swap. A maioria das pessoas não será alvo, mas a chance de ter problemas por perder uma chave de autenticação multifator é bem maior
É por isso também que métodos mais seguros, como YubiKey, não conseguiram se espalhar entre o público geral. São trabalhosos e confusos
Agora simplesmente confio em senhas geradas aleatoriamente
Quando você precisar fazer login em algum lugar, tira o cartão da carteira e encosta no celular ou no notebook
Para uma empresa com clientes pagantes, isso teria que ser barato o bastante para que faça mais sentido enviar fisicamente um cartão pelo correio quando o cliente não tiver um, em vez de oferecer suporte a métodos alternativos de autenticação
Talvez a maioria dos serviços nem precise de uma segunda camada de autenticação. Se alguém roubar sua carteira, será que essa pessoa vai realmente se importar com sua conta do Reddit?
Fiz um teste e não houve conflito entre várias contas usando o mesmo nome de conta/e-mail
Cada item também mostra corretamente o ícone do emissor, e o emissor está registrado em cada item
Uso o MS Authenticator há anos e nunca passei por esse tipo de problema; naturalmente, sempre uso o mesmo e-mail como nome da conta ou nome de usuário
Estou apenas registrando o resultado do teste. Não acho que isso vá mudar a opinião de ninguém sobre o Authenticator ou a Microsoft, mas enfim
Isso também aconteceu comigo quando atualizei o MS Authenticator depois de ficar um tempo sem atualizar
Todos os dados foram apagados, e fiquei bloqueado fora de todas as contas. O MS Authenticator não é um produto feito com cuidado
Algo parecido aconteceu cerca de 1 ano atrás, quando o app Google Authenticator foi atualizado automaticamente para uma nova versão
Durante o processo de atualização, perdi todas as contas, e com certeza aprendi algumas lições