Autenticação de dois fatores
Tudo o que você leu na primeira parte se refere à identificação com base no que o solicitante sabe . Ele sabe seu endereço de e-mail, sabe como acessá-lo (ou seja, sabe sua senha de e-mail) e sabe as respostas às perguntas de segurança.
“Conhecimento” conta como um fator de autenticação; dois outros fatores comuns são o que você tem , como um dispositivo físico, e quem você é , como impressões digitais ou retina.
Na maioria dos casos, realizar a identificação biológica é dificilmente viável, especialmente quando falamos sobre a segurança de aplicativos da web, então a autenticação de dois fatores (2FA) geralmente usa o segundo atributo - "o que você tem". Uma variação popular desse segundo fator é um token físico, como RSA SecurID :
O token físico é frequentemente usado para autenticação em VPN corporativa e serviços financeiros. Para autenticação no serviço, você precisa usar a senha e o código do token (que muda com frequência) em combinação com o PIN. Em teoria, para a identificação, o invasor deve saber a senha, ter um token e também saber o PIN do token. Em um cenário de redefinição de senha, a própria senha é obviamente desconhecida, mas a posse de um token pode ser usada para confirmar a propriedade de uma conta. Claro, como acontece com qualquer implementação de segurança, isso não fornece "infalível" , mas definitivamente levanta a barreira de entrada.
Um dos principais problemas dessa abordagem é o custo e a logística de implementação; estamos falando sobre entregar dispositivos físicos para cada cliente e ensinar-lhes um novo processo. Além disso, os usuários precisam ter um dispositivo com eles, o que nem sempre é o caso com um token físico. Outra opção é implementar o segundo fator de autenticação por SMS, que no caso do 2FA pode servir como confirmação de que a pessoa que realiza o processo de reset possui o celular do dono da conta. É assim que o Google faz:
Você também precisa habilitar a verificação em duas etapas , mas isso significa que, da próxima vez que você redefinir sua senha, seu celular poderá se tornar o segundo fator de autenticação. Deixe-me demonstrar isso com meu iPhone por razões que logo ficarão claras:
Depois de identificar o endereço de e-mail da conta, o Google determina que 2FA foi habilitado e podemos redefinir a conta usando a verificação, que é enviada via SMS para o telefone celular do titular da conta:
Agora precisamos selecionar o início do processo de reinicialização:
Esta ação resulta no envio de um e-mail para o endereço registrado:
Este e-mail contém o URL de redefinição:
Ao acessar o URL de redefinição, um SMS é enviado e o site solicita:
Este é o SMS:
Depois de inseri-lo no navegador, voltamos ao território da redefinição de senha clássica:
Provavelmente parece um pouco prolixo, e é, mas o formulário confirma que a pessoa que está realizando a redefinição tem acesso ao endereço de e-mail e ao telefone celular do titular da conta. Mas pode ser nove vezes mais seguro do que redefinir sua senha apenas por e-mail. No entanto, existem problemas ...
O problema é com smartphones. O dispositivo mostrado abaixo só pode autenticar um fator de autenticação - pode receber SMS, mas não e-mail:
No entanto, este dispositivo pode receber SMS e e-mails de redefinição de senha:
O problema é que consideramos o e-mail como o primeiro fator de autenticação e o SMS (ou mesmo um aplicativo gerador de tokens) como o segundo, mas hoje eles estão combinados em um único dispositivo. Claro, isso significa que, se alguém acessar seu smartphone, toda essa comodidade se resumirá ao fato de estarmos de volta ao mesmo canal; este segundo fator, “o que você tem” significa que você também tem o primeiro fator. E tudo isso protegido por um PIN de quatro dígitos ... se o telefone tiver algum PIN e estiver bloqueado.
Sim, o recurso 2FA do Google certamente oferece proteção adicional, mas não é infalível e certamente não depende de dois canais completamente autônomos.
Redefinir por nome de usuário vs redefinir por e-mail
Devo permitir a redefinição apenas para o endereço de e-mail? Ou o usuário também deve ser capaz de redefinir por nome? O problema com a redefinição por nome de usuário é que não há como notificar o usuário de um nome de usuário incorreto sem revelar que outra pessoa pode ter uma conta com esse nome de usuário. Na seção anterior, a redefinição por e-mail garantiu que o legítimo proprietário desse e-mail sempre receberia feedback, sem divulgar publicamente sua existência no sistema. Isso não pode ser feito usando apenas o nome de usuário.
Portanto, a resposta é curta: apenas e-mail. Se você tentar redefinir usando apenas o nome de usuário, haverá momentos em que o usuário se perguntará o que aconteceu.ou você vai divulgar 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 há uma grande probabilidade de você divulgar indiretamente os proprietários da conta devido à tendência dos usuários de reutilizar nome.
Então, o que acontece quando alguém esquece seu nome de usuário? Se aceitarmos que o nome de usuário não é imediatamente um endereço de e-mail (e isso acontece com frequência), o processo é semelhante a como uma redefinição de senha começa - inserimos um endereço de e-mail e 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 o URL de redefinição de senha. Ou isso ou o e-mail dirá que não há conta para este endereço.
Verificação da identidade e precisão dos endereços de e-mail
Um aspecto-chave da redefinição de senha, e talvez até o aspecto mais importante, é verificar a identidade da pessoa que está tentando redefinir. Este é realmente o proprietário legítimo da conta, ou alguém está tentando hackear ou incomodar o proprietário?
Obviamente, o e-mail é a maneira mais conveniente e comum de verificar sua identidade. Não é protegido contra manuseio incorreto ("do tolo"), e há muitos casos em que a simples capacidade de receber cartas para o endereço do proprietário da conta não é suficiente se um alto grau de confiança na identificação for necessário (razão pela qual 2FA é usado), mas é quase sempre o ponto de partida processo de reinicialização.
Se o e-mail for importante para fornecer confiança, a primeira etapa é verificar se o endereço de e-mail está realmente correto. Se alguém cometeu um erro com o símbolo, então, obviamente, o reset não iniciará. O processo de verificação de e-mail no momento do registro é uma forma confiável de verificar se o endereço está correto. Todos nós já vimos isso na prática: você se inscreve, eles lhe enviam um e-mail com um URL exclusivo para clicar, o que confirma que você é realmente o proprietário dessa conta de e-mail. A falta de login antes de concluir este processo garante que haja motivação para verificar o endereço.
Como acontece com muitos outros aspectos de segurança, esse modelo reduz a usabilidade em troca de fornecer um maior grau de segurança em relação à identidade do usuário. Isso pode ser aceitável para um site, registro no qual o usuário valoriza muito e terá o prazer de adicionar outra etapa do processo (serviços pagos, bancos, etc.), mas tais coisas podem alienar o usuário se ele perceber a conta como "descartável" e usar , por exemplo, apenas como meio de comentar uma postagem.
Identificar quem iniciou o processo de reinicialização
Há motivos claros para o uso malicioso da função de redefinição e os invasores podem usá-la de muitas maneiras diferentes. Um truque simples que podemos usar para ajudar a verificar a origem da solicitação (esse truque geralmente funciona) é adicionar a redefinição do endereço IP do solicitante ao e-mail. Isso fornece ao destinatário algumas informações para identificar a origem da solicitação.
Aqui está um exemplo da função de redefinição que estou incorporando atualmente no ASafaWeb:
O link "saiba mais" leva o usuário ao ip-adress.com , fornecendo informações como a localização e a organização da pessoa que está solicitando o reset:
Obviamente, qualquer pessoa que queira ocultar sua identidade tem muitas maneiras de ofuscar seu endereço IP real; no entanto, essa é uma maneira conveniente de adicionar a identidade parcial do solicitante e, na maioria dos casos, isso lhe dará uma boa ideia de quem executará uma solicitação de redefinição de senha.
Alterar notificação por e-mail
Esta postagem está imbuída de um tópico - comunicação; comunicar o máximo possível ao titular da conta sobre o que está acontecendo em cada etapa do processo, sem revelar nada que possa ser usado com intenção maliciosa. O mesmo se aplica quando a senha realmente mudou - notifique o proprietário disso!
Existem duas fontes de razões para alterar uma senha:
- Altere a senha após o login porque o usuário deseja uma nova senha
- Redefinir uma senha sem fazer login porque o usuário a esqueceu
Embora esta postagem seja principalmente sobre redefinição, a notificação no primeiro caso reduz o risco de alguém alterar a senha sem o conhecimento do legítimo proprietário. Como isso pode acontecer? Um cenário muito comum é obter a senha do proprietário legítimo (uma senha reutilizada que vazou de outra fonte; uma senha obtida por keylogging; uma senha facilmente adivinhada, etc.), após o qual o invasor decide alterá-la, bloqueando assim o proprietário. Sem a notificação por email, o proprietário atual não saberá da alteração da senha.
Claro, no caso de uma redefinição de senha, o proprietário já teve que iniciar o processo (ou ignorar as ferramentas de verificação de identificação descritas acima), portanto, a mudança não devevenha como uma surpresa para ele, no entanto, um e-mail de confirmação será um feedback positivo e uma verificação adicional. Além disso, ele fornece consistência com o cenário acima.
Ah, e caso ainda não seja óbvio - não poste sua nova senha! Isso pode fazer alguns rir, mas acontece :
Logs, logs, logs e mais alguns logs
A função de redefinição de senha é atraente para invasores: o invasor deseja obter acesso à conta de outra pessoa ou simplesmente incomodar o proprietário da conta / sistema. Muitas das práticas descritas acima podem reduzir a probabilidade de abuso, mas não o evitam e certamente não impedirão que as pessoas tentem usar o recurso de maneiras indesejadas.
O log é uma prática absolutamente inestimável para reconhecer o comportamento malicioso, e quero dizer um log muito detalhado . Registre tentativas malsucedidas de fazer login, redefinir senhas, alterar senhas (ou seja, quando o usuário já estiver conectado) e quase tudo que possa ajudá-lo a entender o que está acontecendo; será muito útil no futuro. Registre até mesmo partes separadas nos registrosprocesso, por exemplo, uma boa função de redefinição deve incluir iniciar uma redefinição através do site (capturar a solicitação e tentativas de login para redefinir com um nome de usuário ou e-mail incorreto), registrar a visita ao site pela URL de redefinição (incluindo tentativas de usar o incorreto token) e, em seguida, registre o sucesso ou a falha da resposta à pergunta de segurança.
Quando falo em registro, não quero dizer apenas registrar o fato de carregar uma página, mas também coletar o máximo de informações possível, caso não sejam confidenciais . Pessoal, por favor não registrem senhas! Nos logs, você precisa registrar a identidade do usuário autorizado (ele será autorizado se mudarsenha existente ou tentativa de redefinir a senha de outra pessoa após o login), quaisquer nomes de usuário ou endereços de e-mail tentados, mais quaisquer tokens redefinidos que tente usar. Mas também vale a pena registrar aspectos como endereços IP e, se possível, até mesmo cabeçalhos de solicitação. Isso permite que você recrie não apenas o que o usuário (ou invasor) está tentando fazer, mas também quem ele é.
Delegação de responsabilidade para outros artistas
Se você acha que isso é uma enorme quantidade de trabalho, então você não está sozinho. Na verdade, construir um sistema robusto de gerenciamento de contas não é uma tarefa fácil. Não é que seja tecnicamente pesado, apenas tem muitos recursos. Não se trata apenas de redefinir, há todo um processo de registro, armazenamento seguro de senhas, tratamento de várias tentativas de login incorretas, etc., etc. Embora eu esteja promovendo a ideia de usar a funcionalidade pronta para uso, como o provedor de associação ASP.NET , ainda há muito a ser feito.
Hoje, há muitos fornecedores terceirizados que, de bom grado, eliminam o problema e resumem tudo em um único serviço gerenciado. Esses serviços incluem OpenID, OAuth e até Facebook. Algumas pessoasNão há limite para acreditar neste modelo (o OpenID realmente teve muito sucesso no Stack Overflow), mas outros o vêem literalmente como um pesadelo .
Sem dúvida, um serviço como o OpenID resolve muitos problemas do desenvolvedor, mas sem dúvida está adicionando novos. Eles têm um papel a cumprir? Sim, mas obviamente não estamos vendo um uso massivo de provedores de serviços de autenticação. Bancos, companhias aéreas e até lojas implementam seus próprios mecanismos de autenticação e, obviamente, há boas razões para isso.
Descarga maliciosa
Um aspecto importante de cada um dos exemplos acima é que a senha antiga é considerada inútil apenas depois que a identidade do proprietário da conta foi verificada . Isso é importante porque, se a conta pudesse ser redefinida antes da verificação de identidade, todos os tipos de atividades maliciosas seriam abertos.
Aqui está um exemplo: alguém está dando um lance em um site de leilão e, no final do processo de licitação, bloqueia os concorrentes iniciando um processo de reinicialização, removendo-os assim da licitação. Obviamente, se uma função de reinicialização mal projetada puder ser mal utilizada, isso pode levar a resultados negativos graves. É importante notar que bloquear contas por meio de tentativas incorretas de login é uma situação semelhante, mas este é um assunto para outra postagem.
Como eu disse acima, dar a usuários anônimos a capacidade de redefinir a senha de qualquer conta simplesmente por saber seu endereço de e-mail é uma situação pronta para um ataque de negação de serviço. Pode não ser o mesmo DoS, sobre a qual estamos acostumados, mas não há maneira mais rápida de bloquear o acesso à sua conta do que com uma função de redefinição de senha mal planejada.
Elo mais fraco
Do ponto de vista da proteção de uma conta, tudo o que foi escrito acima é ótimo, mas você sempre precisa se lembrar do ecossistema que cerca a conta que você está protegendo. Deixe-me dar um exemplo:
ASafaWeb é hospedado por um serviço incrível fornecido pela AppHarbor. O processo de redefinição de uma conta de hospedagem é o seguinte:
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 implementaríamos de forma um pouco diferente. O que quero dizer aqui, no entanto, é que se eu publicar um site como o ASafaWeb no AppHarbor e, em seguida, apresentar ótimas perguntas e respostas de segurança, adicionar um segundo fator de autenticação e fazer o resto de acordo com as regras, isso não muda o fato de que o elo mais fraco em todo o processo é capaz de quebrar tudo. Se alguém se autenticar com sucesso no AppHarbor usando minhas informações, então eles podem substituir a senha de qualquer conta ASafaWeb pela que precisam!
A questão é que a robustez da implementação da proteção deve ser considerada de forma holística: é necessário simular ameaças a cada ponto de entrada do sistema, mesmo que seja um processo superficial, por exemplo, entrar no sistema AppHarbor. Isso deve me dar uma boa ideia de quanto esforço preciso fazer no processo de redefinição de senha do ASafaWeb.
Juntando tudo
Este post contém muitas informações, então quero concentrá-lo em um esboço visual simples:
Lembre-se de registrar o mais detalhado possível para cada um desses itens. É isso, é simples!
Resultado
Minha postagem parece ser abrangente, mas há muito material adicional que eu poderia incluir nela, mas decidi deixar de lado por uma questão de brevidade: a função do endereço de e-mail de resgate, a situação em que você perde acesso ao e-mail associado à conta (por exemplo, você pediu demissão) e assim por diante. Como eu disse antes, a função de reset não é tão difícil, apenas existem muitos pontos de vista sobre ela.
Mesmo que a reinicialização não seja tão difícil, muitas vezes é mal aplicada. Vimos alguns exemplos acima em que a implementação pode levar a problemas e há muitos outros casos de uso em que a redefinição incorreta realmente causou problemas. Foi recentemente revelado quea redefinição de senha foi usada para roubar $ 87.000 em bitcoins . Este é um resultado muito negativo!
Portanto, tome cuidado com suas funções de reset, simule ameaças em diferentes pontos e, ao projetar uma função, não tire o chapéu preto, pois é muito provável que outra pessoa o use!
Publicidade
A VDSina oferece servidores de baixo custo para aluguel com pagamento diário, cada servidor está conectado a um canal de Internet de 500 Megabits e está protegido contra ataques DDoS gratuitamente!
