Info+News+Tech

Conversei com desenvolvedores em todo o mundo para descobrir quais são os pontos problemáticos de autenticação mais urgentes em 2020. Os resultados chegaram.

A autenticação online tornou-se incrivelmente complexa nos últimos 20 anos. O que começou como um simples problema de senha nos anos 70, agora é um bufê opulento de diferentes opções de autenticação junto com considerações regulatórias e de segurança muito reais. Certamente não faltam maneiras de se inscrever ou entrar em algo!

Mas quais são os pontos problemáticos mais urgentes para desenvolvedores e usuários finais? Qual é a aparência de uma ótima autenticação? Como é a autenticação terrível?

Para responder a essas perguntas, entrevistei dez membros ativos de nossa comunidade de desenvolvimento perguntando quais eles acham que são os pontos fracos de autenticação mais urgentes de 2020. Cada pessoa com quem conversei tem uma experiência diferente na indústria da web, mas cada uma tem um interesse ativo na autenticação. O resultado é uma coleção de opiniões e pontos problemáticos de autenticação vistos de diferentes perspectivas. Então, vamos mergulhar.

Em primeiro lugar, a força do sentimento me surpreendeu. Sei que minha pergunta pede que você considere quais são os pontos de dor, então obviamente você está procurando por eles, mas o que eu não esperava era a quantidade de dor que está sendo sentida lá fora. Eu esperava respostas como: “Bem, você sabe, OAuth é um pouco complicado ‘, mas o que eu realmente recebi foram vários pontos problemáticos de cada desenvolvedor cobrindo uma ampla variedade de conceitos. Parece-me que pode haver mais problemas de autenticação do que eu esperava:

“É caro e perigoso para mim construir minha própria autenticação.” Martin Omander, advogado desenvolvedor do Google.

É realmente difícil para mim ter certeza absoluta de que minha autenticação é segura, sem vulnerabilidades. Sempre tento seguir as melhores práticas para ter certeza de que tudo está seguro, mas não posso evitar aquela vozinha na minha cabeça dizendo “você cometeu um erro”, “sua autenticação não é totalmente segura”. Ale Sánchez, Engenheiro de Software da Rebellion Pay.

O problema que vejo com mais frequência é que os desenvolvedores de software não colocam a autenticação em todos os lugares que ela precisa estar. Por exemplo, você tem um aplicativo que chama uma API e não há autenticação (isso acontece às vezes). Agora imagine que a API chama outra API e não há autenticação lá, isso acontece MUITO. Assumimos confiança entre APIs, containers e outros serviços que não chegam fora de nossa rede, o que é um grande erro. Cada serviço e aplicativo deve ser sua própria ilha e implementar confiança zero, garantindo que haja autenticação e autorização antes de conceder acesso a qualquer coisa.

Tanya ‘SheHacksPurple’ Janca, profissional de segurança e blogueira em SheHacksPurple.dev

Isso é mais profundo do que pensei que seria no primeiro dia e são apenas três citações da minha pesquisa. Os desenvolvedores trabalham para resolver problemas, mas não recebemos dinheiro perigoso nem temos acesso a aconselhamento se passarmos um ano preocupados com hackers.

Então, com isso, chegamos ao ponto principal: a segurança é um desafio em constante evolução, é difícil tornar a autenticação segura e prever todas as maneiras como ela pode ser vulnerável. Isso torna caro para desenvolver, caro para manter e alto risco para alguém assumir a responsabilidade quando o impacto de um bug pode ser tão grande.

Usando a autenticação de outra pessoa

Claro, você pode evitar rolar sua própria autenticação usando um serviço.

OAuth 2.0 é o padrão de autorização aberto usado para isso. Embora OAuth seja na verdade uma estrutura para autorização, é sinônimo de autenticação. Isso ocorre principalmente porque os logins sociais usados ​​em sites são implementados usando OAuth (e geralmente o OpenID Connect também). ‘Login com Facebook / Google / Twitter / Github’ é a norma para milhões de usuários. Alguns sites, por exemplo dev.to , não oferecem nada além de fazer login no Twitter ou Github. Nós nos tornamos dependentes dessas redes sociais que gerenciam nossa identidade para nós e, embora isso seja uma grande vitória (deixe outra pessoa descobrir o que é difícil!), Existem desvantagens também:

Ser capaz de usar um provedor OAuth, junto com a proliferação de um bom software de gerenciamento de senha, é uma grande vitória para desenvolvedores e usuários. Acredito que a autenticação se tornará exponencialmente mais fácil à medida que serviços que simplificam o processo de autenticação se tornem disponíveis. Uma desvantagem do OAuth é que gastamos menos tempo desenvolvendo nossa própria autenticação, mas gastamos mais tempo entendendo e implementando soluções de terceiros. O maior ponto problemático da autenticação em 2020 é a última parte: OAuth. Embora extremamente conveniente, é um processo que pode ser melhorado.
Aimeri – Desenvolvedor Full Stack, NC EUA.

Então, de fato, trocamos um problema por outro? Estamos realmente mais à frente? A documentação do OAuth não é para os fracos. Além disso, para oferecer soluções de login múltiplo, precisamos consultar a documentação de cada provedor. Por exemplo, aqui estão todas as 1830 palavras do guia ‘Noções básicas de autenticação’ do Github .
Em alguns casos você está preso entre uma pedra e um lugar duro como Yubraj, um desenvolvedor FullStack em Etribes descreve, quando o cliente exige SSO, mas sem o uso de um terceiro:

É difícil implementar o login único se você não usar o serviço de autenticação de trinta partes, tive que passar pela documentação do labirinto de um dos serviços de autenticação do meu cliente, foi horrível de testar. Eu tive muita confusão inicialmente entendendo OpenId vs OAuth.
Ponto de dificuldade da autenticação número 2: os terceiros que realizam a autenticação para nós são complicados para se integrar, pois cada um faz as coisas de maneira um pouco diferente dentro da estrutura OAuth 2.0. O tempo é gasto pensando em como se integrar ao Facebook, Twitter, Github etc., enquanto a necessidade de fornecer login sem marca para usuários que não têm contas de terceiros ainda existe, caso contrário, você força os usuários a criar contas Github (por exemplo ) antes de criarem uma conta no seu site.

Um excesso de escolha

Existem alguns provedores conhecidos que se oferecem para lidar com integrações de provedores de identidade para você. Falei com Yann em Montreal , um engenheiro de software da PivoHub . Ele descreve um problema específico com Auth0, em que os usuários que chegam ao seu site fazem login uma vez com o Facebook, mas depois voltam e
fazem login com o Twitter (ou outro) e o resultado são duas contas diferentes, mesmo que
o endereço de e-mail do usuário permaneça constante:

Se você usar vários provedores de identidade e o usuário usar dois provedores diferentes com o mesmo e-mail, serão criadas 2 contas, o que é um problema. Para resolver isso, você deve escrever algum código personalizado, o que é muito chato. Eles devem ter uma configuração para isso.
Isso me levou a pensar, espere, a escolha é uma coisa boa? Para os usuários finais, as várias maneiras de se inscrever em um site são realmente uma boa experiência para o usuário?

A Okta orgulhosamente exibe uma longa lista de provedores de identidade que vêm pré-integrados:

Isso parece uma boa experiência do usuário para você? Suponho que não seja realista esperar que um site queira usar tudo isso de uma vez, mas mesmo três opções podem ser problemáticas. A anedota de Yann mostra que os usuários esquecem qual conta social eles usaram para se inscrever e acabam se inscrevendo duas vezes. Isso é doloroso para o desenvolvedor e para o usuário.

Voltando à perspectiva do desenvolvedor, Martin (defensor do desenvolvedor no Google) diz que é difícil atender a todas as maneiras como um usuário pode querer fazer login:

É difícil fornecer autenticação que agrade a todos os seus usuários porque eles têm preferências muito diferentes. Alguns preferem usar sua conta do Google ou Facebook em todos os sites. Outros preferem criar uma nova conta de nome de usuário + senha para cada site que visitam, para aumentar a segurança. Muitos usuários de telefones preferem algo que exija menos digitação, talvez com base em seu número de telefone.

E isso nos leva ao terceiro ponto problemático da autenticação: há muitas opções.

Tente atender a todas as necessidades dos usuários e você acabará com uma lista de opções de autenticação tão longa quanto o seu braço. Isso, por sua vez, causa paralisia de escolha e problemas no back-end quando um usuário tenta se inscrever ou se inscrever várias vezes usando diferentes provedores de identidade.

Fornece poucas opções e nem todos os usuários podem acessar seu site. Vemos isso no caso de sites que oferecem exclusivamente login social e nenhuma alternativa baseada em e-mail.

Além disso, muitas opções de autenticação causam paralisia de escolha para o usuário e, posteriormente, se após uma longa sessão, ele se autenticar novamente usando uma rede social diferente, terá problemas.

Comecei a conversar com Diego, um funcionário do Facebook. Suas opiniões são próprias e não do Facebook. Eu fiz a pergunta: os logins sociais são amigos do desenvolvedor? Eles tornam a vida mais simples? Eles fazem o oposto? Diego respondeu:

Depende. Eles estão tornando mais difícil raciocinar em torno das contas? sim. Eles estão dificultando o armazenamento de uma senha não criptografada que será inserida em um vazamento falso que causa histeria em massa? sim.
O problema de Diego é com a alternativa ao login social, ou seja, configurações de nome de usuário e senha em cada site . Então, sim, o login social é complicado de implementar, mas pelo menos significa que você não precisa armazenar senhas com hash em seu banco de dados, o que é definitivamente uma vantagem.

Se você decidir começar a armazenar senhas, os regulamentos tornam o armazenamento de dados de identificação pessoal arriscado, conforme explicado por Martin Omander, do Google:

Armazenar PII (dados de identificação pessoal, como nome ou endereço de e-mail) é arriscado e cada vez mais regulamentado. PII em seu banco de dados é basicamente um risco. A maneira mais fácil de cumprir os regulamentos de privacidade é não armazenar nenhuma PII. Como posso fazer isso, mas ainda fornecer autenticação segura?
Os pontos de Martin e Diego andam de mãos dadas. Como reconciliar a lacuna entre esses dois pilares de autenticação, nenhum dos quais é ‘perfeito’?

Martin novamente:

Eu ouço usuários de vez em quando sobre métodos de login. Eles dizem uma de duas coisas: 1. Não quero ter que inventar outra combinação de nome de usuário / senha. 2. Não quero o login federado porque não quero que ninguém veja os sites que visito. Eu prefiro o bom e velho nome de usuário / senha.
Essas conversas me levam a pensar que o ponto quatro do problema é que não há uma resposta óbvia para qual método de autenticação é o melhor. Sempre há algum nível de debate necessário. Não existe um método de autenticação ‘de fato’ que reconcilie esses problemas.

Os requisitos para autenticação parecem bastante simples em essência:

A autenticação deve ser segura.
Deve ser muito fácil para um desenvolvedor implementar autenticação segura.
A autenticação deve ser conveniente para o usuário final.
Nikola, Diretor de Engenharia da Teltech , resume perfeitamente:

Imho, ainda parece que, embora estejamos em 2020, há muito barulho para fazer a autenticação funcionar. Seria ótimo se você pudesse chamar apenas uma função e woila 🤗

Artigo escrito por Richard, do Hackernoon

Deixe uma resposta

Info.CEVIU