- Links mágicos que enviam um link de login por e-mail podem reduzir phishing de senha e o risco de vazamento por reutilização de senhas, mas, quando viram a única opção, transferem o atrito do login para o usuário
- Usuários que usam vários computadores ou separam dispositivos de trabalho e pessoais acabam com o fluxo facilmente interrompido, porque o dispositivo que recebe o e-mail e o navegador em que querem fazer login são diferentes
- Por causa de atrasos de SMTP e do processo de encaminhar o link, o login pode demorar de 2 segundos a vários minutos, e a usabilidade no mobile também pode quebrar em navegadores in-app e apps de leitor de RSS
- O método de digitar diretamente um OTP recebido por e-mail ou SMS também é incômodo, mas pode ser melhor do que links mágicos quando é difícil mover o link entre o cliente de e-mail e o navegador
- Mesmo que links mágicos sejam o padrão, vale oferecer junto alternativas robustas como passkeys para usuários mais técnicos e preocupados com privacidade
Situações em que links mágicos ficam inconvenientes
- “Magic Links” já significou PDAs futuristas no passado, mas hoje o termo é usado por empresas como a Auth0 para se referir a links de login incluídos em e-mails
- A 404 Media, em “We Don’t Want Your Password”, defende links mágicos, argumentando que links por e-mail são mais difíceis de sofrer phishing do que senhas, não levam a vazamentos de senha e também reduzem o risco de reutilização de senhas expostas
- Embora pareçam simples em uma rotina centrada em um único notebook e um dispositivo móvel, para usuários que usam vários dispositivos e navegadores a complexidade é repassada integralmente
- Casos problemáticos:
- Vários dispositivos: usuários que não mantêm seu e-mail pessoal no PC de jogos ou no notebook de trabalho têm dificuldade para abrir imediatamente o link de login
- Velocidade: por causa de atrasos de SMTP e do processo de levar o link ao navegador correto, isso pode demorar de 2 segundos a vários minutos
- Mobile: o uso de navegadores in-app quebra, tornando incômodo lidar com links locais em apps de leitor de RSS
- Segurança: um fluxo que incentiva abrir o e-mail pessoal em um dispositivo de trabalho, ou o contrário, não traz vantagem de segurança
Alternativas e melhorias mínimas
- O modelo passwordless de inserir diretamente um OTP recebido por e-mail ou SMS também é incômodo, mas pode ser mais prático do que links mágicos em situações em que não é fácil mover o link do cliente de e-mail para o navegador de login
- O Stratechery oferece, via Passport, clique em link ou inserção de OTP; embora ainda tenha a limitação de repassar o incômodo ao usuário sem implementar passkeys, considera melhor o contexto do usuário do que usar apenas links mágicos
- Mesmo insistindo em links mágicos/trágicos como padrão, é melhor oferecer junto alternativas robustas como passkeys
- Magic Links Have Rough Edges, but Passkeys Can Smooth Them Over, de Ricky Mondello, é um texto de referência sobre como passkeys podem aliviar esse problema
1 comentários
Opiniões do Hacker News
Problemas enfrentados ao criar um app com magic links: como o usuário pode precisar fazer login em um dispositivo no qual acessar o e-mail é inconveniente, é preciso incluir um código de login alternativo junto com o magic link
Também é preciso lidar com casos em que o cliente de e-mail abre o link automaticamente para gerar uma captura de tela de pré-visualização, e considerar clientes de e-mail que abrem o link em um navegador embutido no app em vez do navegador preferido pelo usuário
Por exemplo, mesmo que um usuário de iOS prefira o Firefox Mobile, o app de e-mail pode forçar a abertura em um navegador embutido baseado no Safari
Acho que uma abordagem que leva a uma página para inserir um código de uso único evitaria muitos desses problemas
Recentemente passei por um problema em que uma nova conta de e-mail era confirmada automaticamente e, quando o usuário clicava, o magic link já estava inválido, porque a Microsoft havia feito login primeiro por meio daquele link durante a verificação
Depois que o McDonald's trocou e-mail/senha por magic link, foi realmente difícil fazer o link funcionar no app do McD; em geral, ele só abria o site do McD
Quando como McD, em cerca de 98% das vezes, se não der para pedir pelo app eu não como, então isso foi bem irritante, e acabei migrando para “Sign in With Apple” (SIWA)
Não encontrei uma forma de adicionar SIWA à minha conta McD existente, então precisei usar o SIWA que oculta meu e-mail real do McD; uma nova conta foi criada e perdi os pontos de recompensa da conta antiga, mas pelo menos consegui voltar a usar o app do McD
O app tem uma promoção toda sexta-feira de “Free Medium Fries on Friday” em pedidos acima de 1 dólar, então toda sexta no almoço eu costumo fazer um sanduíche em casa e pegar um cookie e batata frita grátis no McD para acompanhar
Então recebi o magic link no computador da empresa e criei um QR code, mas o sistema de quarentena de e-mail havia alterado o link inteiro, então precisei extrair o original
E não parou por aí: a URL de redirecionamento de volta para o Slack estava quebrada por causa da codificação de URL, então precisei corrigi-la manualmente antes de criar o QR code
Bastaria incluir um QR code ou um código no e-mail original do magic link
No momento em que você passa a inserir um código, essa vantagem desaparece completamente; o atacante só precisa criar um site falso que peça o código
O magic link deve fazer login no dispositivo em que foi clicado, não no dispositivo que solicitou a sessão de login
Qualquer outro método pode até ser um pouco menos incômodo, mas é um problema de segurança e deve ser tratado como tal
Usei magic links por alguns anos, também porque, na fase de MVP, queria evitar o peso de segurança de armazenar senhas dos usuários. O maior problema é que alguns usuários, cerca de 0,1%, simplesmente não recebem o e-mail
Já tentei IP próprio, MailGun, PostMark e até uma abordagem de novas tentativas sequenciais com várias ferramentas de e-mail transacional, mas ainda há pessoas que nunca conseguem fazer login
Além disso, as pessoas clicam em um magic link de 6 meses atrás e ficam frustradas dizendo que “não funciona”, então decidimos mostrar uma página que explica a situação e reenvia o link, no estilo Docusign, em vez de uma mensagem de erro
As pessoas também frequentemente digitam o endereço de e-mail errado e, quando não recebem o código, culpam o sistema
Mesmo assim, sinto que há muito menos tickets de suporte do que com e-mail+senha, então ainda prefiro magic links
Nunca usei magic links, mas alguns meses atrás adicionei Google Sign in ao SaaS e ele passou a representar mais de 90% dos novos cadastros
Mesmo com uma base de usuários formada por desenvolvedores, com bom entendimento técnico e alta sensibilidade a privacidade, isso acontece; agora não acho que outros métodos sejam prioridade. Claro, e-mail/senha ainda é mantido
Nome de usuário+senha usado com um gerenciador de senhas, ou passkeys, talvez sejam praticamente as únicas formas de trocar credenciais com criptografia de ponta a ponta sobre HTTPS oferecendo uma boa experiência de usuário para o público em geral
O gerenciador de senhas garante que as credenciais sejam usadas apenas no domínio correto
Eu era um cliente fiel da Mercury, mas, mesmo depois de passar por uma senha segura, um gerenciador de senhas e um TOTP válido, eles me obrigavam a usar um magic link como terceiro fator de autenticação sempre que o endereço IP mudava, a ponto de eu considerar levar a conta bancária da empresa para outro lugar
Eu até entenderia se fosse um login de um local ou ISP que eu não usava nos últimos cinco anos, mas não faz sentido quando a única coisa diferente em relação ao login de ontem é o último octeto do endereço DHCP
Como leio e-mail via navegador e por SSH em outro computador, copiar e colar um link de login com centenas de caracteres é um verdadeiro suplício
No Emacs, ele aparece quebrado em várias linhas, e ainda preciso remover manualmente os
\nas quebras de linhaQuando se adiciona atrito a cada login, a impressão de todas as interações seguintes no app piora, e dá vontade de não usar
Se for um dispositivo já usado antes, não deveria aparecer a exigência de verificação de dispositivo. Para verificar isso, armazenamos um cookie persistente, e também não exigimos quando é o mesmo IP. Fico me perguntando se talvez os cookies estejam sendo apagados periodicamente
Adicionamos esse recurso depois que atacantes criaram sites-clone de http://mercury.com e até veicularam anúncios no Google
Quando o cliente digitava a senha e o TOTP no site de phishing, o phisher usava essas credenciais para entrar, criar cartões virtuais e comprar criptomoedas, ouro etc.; em seguida, redirecionava o usuário para a Mercury real, esperando que ele achasse que tinha sido um erro temporário
Esse link de verificação de dispositivo que enviamos aprova o IP/dispositivo que abriu o link, e isso praticamente bloqueou os phishers por completo
O WebAuthn é imune a esse tipo de ataque de phishing, então não exigimos verificação de dispositivo quando WebAuthn é usado
Se possível, recomendo fortemente TouchID/FaceID ou WebAuthn por dispositivo. É mais prático e mais seguro, e dá para adicionar aqui: https://app.mercury.com/settings/security
Dito isso, estamos discutindo este texto internamente e também reconhecemos que, à medida que o IPv6 se disseminar mais, os IPs vão mudar com muito mais frequência. Vamos pensar se devemos flexibilizar a restrição de correspondência pelo mesmo IP
Achei uma reação muito boa ao texto sobre 404 da semana passada. Gosto do 404, mas, pelos mesmos motivos que o autor mencionou, magic links são irritantes
O texto[1] que Ricky Mondello escreveu na semana passada vale a leitura, porque explica bem como passkeys podem ser usadas junto com magic links, como ficou implícito no fim do artigo
[1]: https://rmondello.com/2025/01/02/magic-links-and-passkeys/
Ao tentar entrar na loja, ela pedia o código de 2FA enviado por e-mail; a mensagem não chegava por vários minutos, eu pedia um novo código e ele também não chegava, e, quando eu desistia e ia fazer outra coisa, os dois códigos chegavam 30 minutos depois
Na verdade, e-mail é pouco confiável mesmo nas melhores condições. Pode cair no spam, o filtro antispam da empresa pode bloquear links, ou a caixa de entrada pode estar cheia
Pessoalmente, meu e-mail só fica no iPhone; no notebook da empresa ou no PC gamer, preciso entrar no icloud.com para conferir, o que é trabalhoso
Eu gostaria que me deixassem digitar uma senha, escanear um QR code como em dispositivos embarcados ou, no mínimo, me dessem alguma outra opção
Magic links permitem acessar as passkeys, e passkeys são basicamente uma versão reforçada de “lembrar este computador”
Ainda estou acostumado com a época em que o pessoal da Apple quase não aparecia publicamente
Não sei se estou entendendo algo errado, mas passkeys não parecem ser, de fato, uma alternativa aos magic links
Todas as implementações de passkeys que vi até agora sugeriam criar uma passkey depois de já estar logado por outro método
Não investiguei a fundo, mas, em termos de experiência do usuário, passkeys parecem mais uma alternativa ao botão “lembrar este computador” do que uma alternativa geral a senhas
De uma forma ou de outra, o serviço precisa saber que este novo dispositivo foi aprovado
Dependendo do provedor, existe sincronização de passkeys, mas isso não resolve como fazer a autenticação inicial
O insight central dos magic links é que um sistema de segurança não pode ser mais forte que seu mecanismo de recuperação
Não virá um mundo em que passkeys sejam tratadas como o único meio de autenticação; sempre haverá mecanismos de recuperação, e a maioria será recuperação automática por e-mail
Sendo assim, magic links são honestos no sentido de simplificar sem fingir que há uma camada mais segura por cima
Ao transformar o mecanismo de recuperação no principal meio de interação do fluxo de autenticação, você acaba sendo mais franco sobre o nível real de segurança do sistema de autenticação
Edição: filmgirlcw deixou um link para um texto melhor explicando como os dois métodos se complementam na prática: https://news.ycombinator.com/item?id=42628226
Magic links também têm vantagens, mas não sei se tornar o e-mail um vetor de ataque mais poderoso é uma delas
Para quem usa gerenciadores de senhas, magic links são claramente um ponto de atrito, e passkeys podem reduzir isso de forma significativa
Os problemas de experiência do usuário das passkeys também podem melhorar, e, quando a exportação se tornar possível, a sincronização entre sistemas ficará muito melhor
Um dos motivos pelos quais uso o 1Password como meu sistema principal de senhas e passkeys é justamente o uso de passkeys entre dispositivos; a empresa também usa 1Password, então posso manter login em contas pessoais e corporativas e autenticar, quando necessário, em dispositivos pessoais ou de trabalho
Dito isso, se o problema definido pela 404 é não querer assumir a responsabilidade por armazenar senhas ou controles de autenticação, acho que, para alguns usuários, passkeys são melhores que magic links
Ainda assim, como Ricky, acho que não deve ser uma coisa ou outra, mas as duas
[1]: https://rmondello.com/2025/01/02/magic-links-and-passkeys/
Usar passkeys não significa necessariamente que precise haver um método alternativo de login, mas nenhum serviço ainda migrou para ser exclusivamente baseado em passkeys
Usuários de sistemas operacionais antigos ou de Linux talvez ainda não consigam criar e armazenar passkeys, e muitos usuários não usam gerenciadores de credenciais multiplataforma
Por exemplo, se você criou uma passkey com iCloud Passwords, hoje não há como fazer login no Linux
Acho que, em mais alguns anos, começaremos a ver fluxos em que o serviço faz o usuário criar uma passkey desde o início e nem coleta senha alguma
Espero que a especificação de portabilidade de passkeys seja implementada e que Gnome/KDE também implementem suporte a passkeys
Se usar o OTP do celular ou copiar um link do celular ao visitar um site no PC de trabalho é doloroso, fico me perguntando o quanto seria mais fácil e melhor fazer o computador de trabalho se integrar à passkey pessoal de algum lugar como um notebook
Não uso serviços que só oferecem magic links para autenticação. É extremamente hostil ao usuário e, do ponto de vista de segurança, é claramente pior do que senhas usadas junto com um gerenciador de senhas
O pior de tudo é que, na minha configuração pessoal, isso simplesmente não funciona
Por segurança e proteção da conta, não acesso minha conta de e-mail nos dispositivos que uso para fazer login
Abro exceção só para a Anthropic, porque o Claude é o melhor LLM, mas toda vez que preciso fazer login de novo é um sofrimento enorme, e já enviei reclamações várias vezes
Toda vez que vejo um magic link, sempre penso: “não era para a gente não clicar em links de e-mail, para começo de conversa?”
Quando penso em links de e-mail, penso também em phishing
Detesto magic links
O ponto é não clicar em links suspeitos. Se você sabe que um magic link foi enviado, ele não é um link suspeito
Mesmo assim, detesto magic links por causa do atraso
A abordagem da Apple para privacidade de e-mail parece interessante. A Apple sempre carrega todas as imagens; não sei se há desvantagens
A melhor implementação que já vi é uma em que é preciso clicar no link no dispositivo que recebeu o e-mail, mas a sessão não é transferida para esse dispositivo; o login é concluído no dispositivo em que o processo de login foi iniciado originalmente
Uma solução melhor é permitir o login apenas no dispositivo em que o link foi aberto e, para uso entre dispositivos, também fornecer um código OTP que possa ser lido no dispositivo receptor e digitado facilmente no dispositivo original
Ou então fornecer apenas o código OTP, sem link
Não há nada pior do que estar trabalhando em um navegador e, ao abrir o e-mail, a autenticação acontecer no navegador padrão — ou, pior, em outro dispositivo —, obrigando você a encaminhar o link para lá e abri-lo de novo
Também pode haver casos em que você não quer acessar determinado e-mail em um dispositivo específico, então não é um cenário tão estranho assim
O método em que o site envia um OTP como
crazy-pink-horse-3837para você copiar e colar é um meio-termo aceitável se for difícil demais implementar um link que autentique a solicitação originalMas o problema da implementação era que o magic link enviado vinha envolvido por um rastreador de cliques, e esse domínio era bloqueado por ferramentas como o pihole
Por isso, não dava para chegar à URL real de autenticação e concluir o processo de login
Navegadores dentro de apps deveriam desaparecer. Especialmente os navegadores dentro de apps que não oferecem a opção “abrir no navegador normal”; se for um leitor de RSS, então essa opção deveria ser obrigatória
Todos os gerentes de produto que obrigam usuários a usar navegadores dentro do app deveriam ser mandados para a cadeia
Uma opção muito melhor é usar códigos OTP enviados por e-mail e passkeys com Conditional Mediation UI
Se o usuário fizer login em um dispositivo que já tem uma passkey, a CM UI permite selecionar imediatamente e entrar na hora
Se for um dispositivo sem passkey, dá para criar uma experiência em que ele digita o código do e-mail e, após o sucesso, configura imediatamente uma passkey para poder entrar direto nas próximas vezes
Assim, em dispositivos existentes você obtém a segurança das passkeys e, em dispositivos novos, uma configuração sem senha e recuperação de conta
De quebra, também evita o aprisionamento a fornecedor, em que o provedor de nuvem detém todas as passkeys