Autenticação de dois fatores
Tudo que você leu em referia-se à identificação com base no que sabe o solicitante. Ele sabe seu endereço de e-mail, sabe como acessá-lo (ou seja, conhece sua senha de e-mail) e sabe as respostas às perguntas secretas.
O “conhecimento” é considerado um fator de autenticação; outros dois fatores comuns são o que você possui, como um dispositivo físico, e quem você é, como impressões digitais ou retina do olho.
Na maioria dos casos, a realização da identificação biométrica é raramente viável, especialmente quando falamos sobre a segurança de aplicativos da web, portanto, na autenticação de dois fatores (two factor authentication, 2FA) normalmente utiliza-se o segundo atributo — “o que você possui”. Uma das opções populares para esse segundo fator é um token físico, como :
Um token físico é frequentemente usado para autenticação em VPN corporativas e serviços financeiros. Para autenticação no serviço, é necessário usar tanto a senha quanto o código do token (que muitas vezes muda) combinado com um PIN. Teoricamente, para a identificação, um invasor deve conhecer a senha, ter o token e também saber o PIN do token. Em um cenário de redefinição de senha, a própria senha é evidentemente desconhecida, no entanto, a posse do token pode ser usada para confirmar a titularidade da conta. Claro, como em qualquer implementação de proteção, , mas definitivamente aumenta a barreira de entrada.
Um dos principais problemas dessa abordagem é o custo e a logística de implementação; estamos falando sobre a transferência de dispositivos físicos para cada cliente e sobre o treinamento deles para o novo processo. Além disso, os usuários precisam ter o dispositivo consigo, o que nem sempre ocorre com um token físico. Outra opção é implementar o segundo fator de autenticação via SMS, que em um cenário 2FA pode servir como confirmação de que a pessoa que está realizando o processo de redefinição possui o telefone celular do proprietário da conta. É assim que o Google faz:
Também é necessário habilitar , mas isso significa que, na próxima vez que você redefinir sua senha, seu celular pode se tornar um segundo fator de autenticação. Deixe-me demonstrar isso com meu iPhone por razões que logo ficarão claras:
Após a identificação do endereço de e-mail da conta do Google, é determinado que a 2FA foi ativada e podemos redefinir a conta com uma verificação que é enviada via SMS para o celular do proprietário da conta:
Agora precisamos escolher o início do processo de redefinição:
Essa ação leva ao envio de um e-mail para o endereço registrado:
Esse e-mail contém a URL de redefinição:
Ao acessar a URL de redefinição, um SMS é enviado e o site pede para inseri-lo:
Aqui está o SMS:
Após inseri-lo no navegador, voltamos à área da redefinição clássica de senha:
Provavelmente, isso parece um pouco prolixo, e de fato é, mas o formulário confirma que a pessoa que está redefinindo tem acesso ao endereço de e-mail e ao celular do proprietário da conta. No entanto, isso pode ser até nove vezes mais seguro do que redefinir a senha apenas pelo e-mail. No entanto, existem problemas…
O problema está relacionado aos smartphones. O dispositivo mostrado abaixo pode autenticar apenas um fator de autenticação — consegue receber SMS, mas não e-mails:
No entanto, este dispositivo pode receber SMS e receber e-mails sobre redefinição de senha:
O problema é que consideramos o e-mail como o primeiro fator de autenticação e o SMS (ou até mesmo um aplicativo gerador de tokens) como o segundo, mas hoje eles estão combinados em um único dispositivo. Isso significa que, se alguém acessar seu smartphone, toda essa conveniência se resume a voltarmos a um canal único; esse segundo fator 'algo que você tem' significa que você também tem o primeiro fator. E tudo isso está protegido por um PIN de quatro dígitos… se o telefone tiver um PIN. e ele foi bloqueado.
Sim, a função 2FA implementada pelo Google definitivamente oferece proteção adicional, mas não é protegida 'contra tolos', e definitivamente não depende de dois canais totalmente autônomos.
Redefinição pelo nome de usuário versus redefinição pelo endereço de e-mail
Deve-se permitir a redefinição de senha apenas pelo e-mail? Ou o usuário deve ter a opção de redefinir também pelo nome? O problema de redefinir usando o nome do usuário é que não há como notificar o usuário sobre um nome de usuário incorreto, sem revelar que outra pessoa pode ter uma conta com esse nome. Na seção anterior, a redefinição pelo e-mail garantiu que o legítimo proprietário desse e-mail sempre receberia um feedback sem a divulgação pública de sua existência no sistema. Com apenas o nome de usuário, isso não é possível.
Portanto, a resposta é simples: apenas e-mail. Se você tentar redefinir apenas com o nome de usuário, surgirão casos em que o usuário ficará confuso sobre o que aconteceu, ou você estará revelando a existência de contas. Sim, é apenas um nome de usuário, não um endereço de e-mail, e sim, qualquer pessoa pode escolher qualquer nome de usuário (disponível), mas ainda assim existe uma grande probabilidade de que você esteja indiretamente revelando os proprietários das contas devido à tendência dos usuários de reutilizar nomes.
Então, o que acontece quando alguém esquece seu nome de usuário? Se considerarmos que o nome de usuário não é imediatamente um endereço de e-mail (o que acontece com frequência), o processo é semelhante ao da redefinição de senha—digitamos o endereço de e-mail e então enviamos uma mensagem para esse endereço, sem revelar sua existência. A única diferença é que, desta vez, a mensagem contém apenas o nome de usuário e não a URL de redefinição da senha. Ou isso, ou na mensagem de e-mail será informado que não há conta para esse endereço.
Verificação de identidade e precisão dos endereços de e-mail
Um aspecto crucial da redefinição de senhas, e, provavelmente, o mais crucial aspecto é a verificação da identidade da pessoa que está tentando realizar a redefinição. É realmente o legítimo proprietário da conta, ou alguém está tentando invadi-la ou causar incômodo ao proprietário?
É claro que o e-mail é o canal mais conveniente e o mais amplamente utilizado para verificação de identidade. Ele não está imune a manuseios inadequados (“por descuido”) e há muitos casos em que a simples possibilidade de receber e-mails no endereço do proprietário da conta não é suficiente, quando uma alta confiabilidade na identificação é necessária (daí a utilização da autenticação em dois fatores), no entanto, quase sempre, é o ponto de partida do processo de redefinição.
Se o e-mail tiver um papel na garantia de confiança, o primeiro passo é assegurar que o endereço de e-mail está, de fato, correto. Se alguém cometeu um erro em um caractere, então, é evidente que a redefinição não começará. O processo de verificação do e-mail no momento do registro é uma maneira confiável de validar o endereço. Todos nós já vimos isso na prática: você se registra, um e-mail é enviado com uma URL única que deve ser clicada, o que confirma que você realmente é o proprietário dessa conta de e-mail. A impossibilidade de entrar no sistema até a conclusão desse processo garante uma motivação para confirmar o endereço.
Assim como em muitos outros aspectos da segurança, esse modelo reduz a usabilidade em troca de garantir um nível mais alto de segurança em relação à confiabilidade da identidade do usuário. Isso pode ser aceitável para um site que o usuário valoriza e que irá, de bom grado, adicionar mais uma etapa ao processo (serviços pagos, banco, etc.), mas tais coisas podem afastar o usuário se ele perceber a conta como 'descartável' e a utilizar, por exemplo, apenas como um meio de comentar uma postagem.
Identificação de quem iniciou o processo de redefinição
É evidente que há razões para o uso malicioso da função de redefinição, e os atacantes podem explorá-la de várias maneiras diferentes. Um truque simples que podemos usar para ajudar a confirmar a origem do pedido (esse truque geralmente funciona) é adicionar ao e-mail de redefinição o endereço IP do solicitante. Isso fornece ao destinatário alguma informação para identificar a origem do pedido.
Aqui está um exemplo da função de redefinição que estou atualmente integrando ao ASafaWeb:
O link "find out more" ("Saiba mais") direciona o usuário para o site , que informa detalhes como a localização e a organização do solicitante do reset:
É claro que qualquer um que deseje ocultar sua identidade tem várias maneiras de mascarar seu verdadeiro IP, no entanto, essa é uma maneira conveniente de adicionar uma identificação parcial do solicitante, e em maioria dos casos, isso lhe dará uma ideia suficiente de quem está fazendo a solicitação de redefinição de senha.
Notificação de mudanças por e-mail
Este post é permeado por um tema — comunicação; informe o proprietário da conta o máximo possível sobre o que está acontecendo em cada etapa do processo, sem revelar nada que possa ser usado de maneira maliciosa. O mesmo se aplica à situação em que a senha realmente foi alterada — informe o proprietário!
As razões para a alteração da senha podem surgir de duas fontes:
- Mudança de senha após o login, porque o usuário deseja uma nova senha
- Redefinição de senha sem login, porque o usuário a esqueceu
Embora este post seja principalmente sobre redefinições, a notificação no primeiro caso diminui o risco de que alguém altere a senha sem o conhecimento do legítimo proprietário. Como isso pode acontecer? Um cenário bastante comum é a obtenção da senha do legítimo proprietário (senha reutilizada, vazada de outra fonte; senha obtida por keylogging; senha fácil de adivinhar etc.), após o qual o invasor decide alterá-la, bloqueando assim o verdadeiro proprietário. Sem a notificação por e-mail, o proprietário legítimo não saberá da alteração de senha.
Claro, no caso de uma redefinição de senha, o proprietário já deve ter iniciado o processo por conta própria (ou contornado os métodos de verificação de identidade mencionados acima), portanto a mudança não deve ser uma surpresa para ele, no entanto, a confirmação por e-mail será um feedback positivo e uma verificação adicional. Além disso, isso assegura a unidade com o cenário descrito acima.
Ah, e caso isso ainda não tenha ficado claro — não envie a nova senha por e-mail! Isso pode fazer alguém rir, mas :
Logs, logs, logs e mais um pouco de logs
A funcionalidade de redefinição de senha é atraente para invasores: o atacante deseja acessar a conta de outra pessoa ou simplesmente causar inconvenientes ao proprietário da conta/sistema. Muitas das práticas mencionadas acima ajudam a reduzir a probabilidade de abusos, mas não os previnem, e certamente não impedirão as pessoas de tentar usar a funcionalidade de maneira não prevista.
Para identificar comportamentos maliciosos, uma prática absolutamente inestimável é o registro em log, e eu me refiro a um registro em log muito detalhado. Registre tentativas de login malsucedidas, redefinições de senha, alterações de senha (ou seja, quando o usuário já está logado) e praticamente tudo que possa ajudá-lo a entender o que está acontecendo; isso será muito útil no futuro. Registre até mesmo partes individuais do processo, por exemplo, uma boa funcionalidade de redefinição deve incluir a iniciação da redefinição pelo site (registre o pedido e tentativas de login para redefinição com nome de usuário ou e-mail incorretos), registre o acesso ao site pelo URL de redefinição (incluindo tentativas de usar um token inválido), e depois registre o sucesso ou falha em responder à pergunta secreta. Quando eu falo sobre registro em log, não me refiro apenas ao registro do acesso à página, mas à coleta de o máximo possível de informações,
desde que não sejam confidenciais . Pessoal,por favor, não registrem senhas nos logs! Nos logs, é necessário registrar a identidade do usuário autenticado (ele estará autenticado se alterar a senha existente ou tentar redefinir a senha de outra pessoa após o login), quaisquer nomes de usuário ou endereços de e-mail testados, além de quaisquer tokens de redefinição que ele tente usar. Mas também vale a pena registrar aspectos como endereços IP e, se possível, até mesmo os cabeçalhos das solicitações. Isso permite que você recrie não apenas o que o usuário (ou invasor) está tentando fazer, mas também quem ele é. Delegar a responsabilidade a outros executores
Delegação de responsabilidade a outros executores
Se você acha que tudo isso representa uma enorme carga de trabalho, não está sozinho. Na verdade, construir um sistema confiável para gerenciar contas não é uma tarefa simples. Não é que seja tecnicamente difícil, mas existem muitas particularidades. Não se resume apenas à redefinição de senhas; há todo um processo de registro, armazenamento seguro de senhas, tratamento de múltiplas tentativas de login incorretas, etc. , mas além disso, ainda é necessário fazer muito mais.
Hoje, existem muitos fornecedores terceirizados que se dispõem a lidar com todas essas dificuldades e a abstrair tudo isso em um serviço gerenciado. Entre esses serviços estão OpenID, OAuth e até mesmo o Facebook. Algumas pessoas (OpenID realmente se mostrou muito bem-sucedido no Stack Overflow), entretanto, outros .
Sem dúvida, um serviço como o OpenID resolve muitos problemas para os desenvolvedores, porém, também é inegável que ele traz novos desafios. Eles têm algum papel? Sim, mas está claro que não vemos uma adoção em massa dos serviços de provedores de autenticação. Bancos, companhias aéreas e até lojas — todos eles implementam seus próprios mecanismos de autenticação, e é evidente que há razões bastante relevantes para isso.
Redefinição maliciosa
Um aspecto importante de cada um dos exemplos mencionados acima é que a antiga senha só é considerada inútil após a verificação da identidade do proprietário da conta. Isso é crucial, pois se a conta pudesse ser redefinida até sem verificação de identidade, isso abriria espaço para várias ações maliciosas.
Aqui está um exemplo: alguém participa de um leilão online, e perto do final do processo de lances, ele bloqueia os concorrentes iniciando o processo de redefinição, eliminando-os assim da disputa. É evidente que, se uma função de redefinição mal projetada puder ser explorada, isso pode levar a resultados negativos sérios. Vale a pena notar que o bloqueio de contas por meio de tentativas de login incorretas é uma situação semelhante, mas isso já é assunto para outro post.
Como mencionei antes, se permitirmos que usuários anônimos redefinam a senha de qualquer conta apenas conhecendo seu endereço de e-mail, isso cria uma situação perfeita para um ataque DoS. Esta pode não ser a forma que estamos acostumados a discutir, mas não existe maneira mais rápida de bloquear o acesso a uma conta do que uma função de redefinição de senha mal planejada. , que estamos acostumados a discutir, mas não existe maneira mais rápida de bloquear o acesso a uma conta do que uma função de redefinição de senha mal planejada.
O elo mais fraco
Em termos de proteção de uma conta, tudo que foi dito acima é excelente, no entanto, você sempre deve lembrar do ecossistema ao redor da conta que está protegendo. Permita-me dar um exemplo:
ASafaWeb é hospedado em um serviço incrível oferecido pela AppHarbor. O processo de redefinição da conta de hospedagem acontece assim:
Etapa 1:
Etapa 2:
Etapa 3:
Etapa 4:
Depois de ler todas as informações anteriores, já é fácil entender quais aspectos, em um mundo ideal, nós implementaríamos um pouco diferente. No entanto, aqui quero dizer que se eu publicar um site como o ASafaWeb no serviço da AppHarbor, e então criar ótimas perguntas e respostas secretas, adicionar um segundo fator de autenticação e fazer tudo de acordo com as regras, isso não elimina o fato de que o elo mais fraco de todo o processo pode quebrar tudo isso. Se alguém autenticar com sucesso na AppHarbor usando minhas informações, poderá alterar a senha de qualquer conta do ASafaWeb para aquela que desejar!
O ponto é que a resistência da implementação de segurança deve ser considerada de maneira holística: é necessário simular as ameaças em cada ponto de entrada do sistema, mesmo que se trate de um processo superficial, como a entrada no sistema da AppHarbor. Isso deve me dar uma boa ideia de quanto esforço preciso dedicar ao processo de redefinição da senha do ASafaWeb.
Conectando tudo
Este post contém uma grande quantidade de informações, então quero concentrá-las em um esquema visual simples:
Lembre-se de que é importante fazer o registro detalhado de cada um desses pontos. E isso é tudo, é simples!
Resultados
Meu post parece abrangente, no entanto, existem muitos materiais adicionais que eu poderia incluir nele, mas decidiu não se envolver nisso por questões de brevidade: o papel do endereço de e-mail de recuperação, a situação em que você perde acesso ao e-mail vinculado à conta (por exemplo, você foi demitido do trabalho) e assim por diante. Como mencionei anteriormente, a função de redefinição não é tão complicada, apenas existem muitos pontos de vista sobre ela.
Mesmo que a redefinição não seja tão difícil, muitas vezes ela é implementada erroneamente. Acima, vimos alguns exemplos de quando a implementação pode levou a problemas, e há muitos mais precedentes em que uma redefinição incorreta realmente causou problemas. Recentemente foi descoberto que . Este é um resultado negativo sério!
Portanto, tenha cuidado com suas funções de redefinição, em diferentes pontos, e ao projetar a função, não tire seu chapéu preto, pois existe uma grande probabilidade de que alguém mais o usará!
Em nome da publicidade
VDSina oferece servidores de baixo custo com pagamento diário, cada servidor conectado a um canal de Internet de 500 Megabits e protegido gratuitamente contra ataques DDoS!
Fonte: habr.com
