{"id":97639,"date":"2020-10-20T02:42:56","date_gmt":"2020-10-20T00:42:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/vsyo-chto-vy-hoteli-znat-o-bezopasnom-sbrose-parolej-chast-2"},"modified":"2020-10-20T02:42:56","modified_gmt":"2020-10-20T00:42:56","slug":"vsyo-chto-vy-hoteli-znat-o-bezopasnom-sbrose-parolej-chast-2","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/vsyo-chto-vy-hoteli-znat-o-bezopasnom-sbrose-parolej-chast-2","title":{"rendered":"Tudo o que voc\u00ea queria saber sobre redefini\u00e7\u00e3o segura de senhas. Parte 2","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Autentica\u00e7\u00e3o de dois fatores<\/h2>\n

\nTudo que voc\u00ea leu em primeira parte<\/a><\/noindex> referia-se \u00e0 identifica\u00e7\u00e3o com base no que sabe o solicitante<\/em><\/strong>. Ele sabe seu endere\u00e7o de e-mail, sabe como acess\u00e1-lo (ou seja, conhece sua senha de e-mail) e sabe as respostas \u00e0s perguntas secretas. <\/p>\n

O \u201cconhecimento\u201d \u00e9 considerado um fator de autentica\u00e7\u00e3o; outros dois fatores comuns s\u00e3o o que voc\u00ea possui<\/em><\/strong>, como um dispositivo f\u00edsico, e quem voc\u00ea \u00e9<\/em><\/strong>, como impress\u00f5es digitais ou retina do olho.<\/p>\n

\"Tudo
\n<\/a><\/noindex>
\nNa maioria dos casos, a realiza\u00e7\u00e3o da identifica\u00e7\u00e3o biom\u00e9trica \u00e9 raramente vi\u00e1vel, especialmente quando falamos sobre a seguran\u00e7a de aplicativos da web, portanto, na autentica\u00e7\u00e3o de dois fatores (two factor authentication, 2FA) normalmente utiliza-se o segundo atributo \u2014 \u201co que voc\u00ea possui\u201d. Uma das op\u00e7\u00f5es populares para esse segundo fator \u00e9 um token f\u00edsico, como RSA SecurID<\/a><\/noindex>:<\/p>\n

\"Tudo
\nUm token f\u00edsico \u00e9 frequentemente usado para autentica\u00e7\u00e3o em VPN corporativas e servi\u00e7os financeiros. Para autentica\u00e7\u00e3o no servi\u00e7o, \u00e9 necess\u00e1rio usar tanto a senha quanto o c\u00f3digo do token (que muitas vezes muda) combinado com um PIN. Teoricamente, para a identifica\u00e7\u00e3o, um invasor deve conhecer a senha, ter o token e tamb\u00e9m saber o PIN do token. Em um cen\u00e1rio de redefini\u00e7\u00e3o de senha, a pr\u00f3pria senha \u00e9 evidentemente desconhecida, no entanto, a posse do token pode ser usada para confirmar a titularidade da conta. Claro, como em qualquer implementa\u00e7\u00e3o de prote\u00e7\u00e3o, isso n\u00e3o oferece \u201cprote\u00e7\u00e3o contra idiotas\u201d<\/a><\/noindex>, mas definitivamente aumenta a barreira de entrada.<\/p>\n

Um dos principais problemas dessa abordagem \u00e9 o custo e a log\u00edstica de implementa\u00e7\u00e3o; estamos falando sobre a transfer\u00eancia de dispositivos f\u00edsicos para cada cliente e sobre o treinamento deles para o novo processo. Al\u00e9m disso, os usu\u00e1rios precisam ter o dispositivo consigo, o que nem sempre ocorre com um token f\u00edsico. Outra op\u00e7\u00e3o \u00e9 implementar o segundo fator de autentica\u00e7\u00e3o via SMS, que em um cen\u00e1rio 2FA pode servir como confirma\u00e7\u00e3o de que a pessoa que est\u00e1 realizando o processo de redefini\u00e7\u00e3o possui o telefone celular do propriet\u00e1rio da conta. \u00c9 assim que o Google faz:<\/p>\n

\"Tudo
\nTamb\u00e9m \u00e9 necess\u00e1rio habilitar a verifica\u00e7\u00e3o em duas etapas<\/a><\/noindex>, mas isso significa que, na pr\u00f3xima vez que voc\u00ea redefinir sua senha, seu celular pode se tornar um segundo fator de autentica\u00e7\u00e3o. Deixe-me demonstrar isso com meu iPhone por raz\u00f5es que logo ficar\u00e3o claras:<\/p>\n

\"Tudo
\nAp\u00f3s a identifica\u00e7\u00e3o do endere\u00e7o de e-mail da conta do Google, \u00e9 determinado que a 2FA foi ativada e podemos redefinir a conta com uma verifica\u00e7\u00e3o que \u00e9 enviada via SMS para o celular do propriet\u00e1rio da conta:<\/p>\n

\"Tudo
\nAgora precisamos escolher o in\u00edcio do processo de redefini\u00e7\u00e3o:<\/p>\n

\"Tudo
\nEssa a\u00e7\u00e3o leva ao envio de um e-mail para o endere\u00e7o registrado:<\/p>\n

\"Tudo
\nEsse e-mail cont\u00e9m a URL de redefini\u00e7\u00e3o:<\/p>\n

\"Tudo
\nAo acessar a URL de redefini\u00e7\u00e3o, um SMS \u00e9 enviado e o site pede para inseri-lo:<\/p>\n

\"Tudo
\nAqui est\u00e1 o SMS:<\/p>\n

\"Tudo
\nAp\u00f3s inseri-lo no navegador, voltamos \u00e0 \u00e1rea da redefini\u00e7\u00e3o cl\u00e1ssica de senha:<\/p>\n

\"Tudo
\nProvavelmente, isso parece um pouco prolixo, e de fato \u00e9, mas o formul\u00e1rio confirma que a pessoa que est\u00e1 redefinindo tem acesso ao endere\u00e7o de e-mail e ao celular do propriet\u00e1rio da conta. No entanto, isso pode ser at\u00e9 nove vezes mais seguro do que redefinir a senha apenas pelo e-mail. No entanto, existem problemas\u2026<\/p>\n

O problema est\u00e1 relacionado aos smartphones. O dispositivo mostrado abaixo pode autenticar apenas um fator de autentica\u00e7\u00e3o \u2014 consegue receber SMS, mas n\u00e3o e-mails:<\/p>\n

\"Tudo
\nNo entanto, este dispositivo pode receber SMS e<\/em> receber e-mails sobre redefini\u00e7\u00e3o de senha:<\/p>\n

\"Tudo
\nO problema \u00e9 que consideramos o e-mail como o primeiro fator de autentica\u00e7\u00e3o e o SMS (ou at\u00e9 mesmo um aplicativo gerador de tokens) como o segundo, mas hoje eles est\u00e3o combinados em um \u00fanico dispositivo. Isso significa que, se algu\u00e9m acessar seu smartphone, toda essa conveni\u00eancia se resume a voltarmos a um canal \u00fanico; esse segundo fator 'algo que voc\u00ea tem' significa que voc\u00ea tamb\u00e9m tem o primeiro fator. E tudo isso est\u00e1 protegido por um PIN de quatro d\u00edgitos\u2026 se o telefone tiver um PIN. e<\/em> ele foi bloqueado.<\/p>\n

Sim, a fun\u00e7\u00e3o 2FA implementada pelo Google definitivamente oferece prote\u00e7\u00e3o adicional, mas n\u00e3o \u00e9 protegida 'contra tolos', e definitivamente n\u00e3o depende de dois canais totalmente aut\u00f4nomos.<\/p>\n

Redefini\u00e7\u00e3o pelo nome de usu\u00e1rio versus redefini\u00e7\u00e3o pelo endere\u00e7o de e-mail<\/h2>\n

\nDeve-se permitir a redefini\u00e7\u00e3o de senha apenas pelo e-mail? Ou o usu\u00e1rio deve ter a op\u00e7\u00e3o de redefinir tamb\u00e9m pelo nome? O problema de redefinir usando o nome do usu\u00e1rio \u00e9 que n\u00e3o h\u00e1 como notificar o usu\u00e1rio sobre um nome de usu\u00e1rio incorreto, sem revelar<\/em> que outra pessoa pode ter uma conta com esse nome. Na se\u00e7\u00e3o anterior, a redefini\u00e7\u00e3o pelo e-mail garantiu que o leg\u00edtimo propriet\u00e1rio desse e-mail sempre receberia um feedback sem a divulga\u00e7\u00e3o p\u00fablica de sua exist\u00eancia no sistema. Com apenas o nome de usu\u00e1rio, isso n\u00e3o \u00e9 poss\u00edvel.<\/p>\n

Portanto, a resposta \u00e9 simples: apenas e-mail. Se voc\u00ea tentar redefinir apenas com o nome de usu\u00e1rio, surgir\u00e3o casos em que o usu\u00e1rio ficar\u00e1 confuso sobre o que aconteceu, ou<\/em> voc\u00ea estar\u00e1 revelando a exist\u00eancia de contas. Sim, \u00e9 apenas um nome de usu\u00e1rio, n\u00e3o um endere\u00e7o de e-mail, e sim, qualquer pessoa pode escolher qualquer nome de usu\u00e1rio (dispon\u00edvel), mas ainda assim existe uma grande probabilidade de que voc\u00ea esteja indiretamente revelando os propriet\u00e1rios das contas devido \u00e0 tend\u00eancia dos usu\u00e1rios de reutilizar nomes.<\/p>\n

Ent\u00e3o, o que acontece quando algu\u00e9m esquece seu nome de usu\u00e1rio? Se considerarmos que o nome de usu\u00e1rio n\u00e3o \u00e9 imediatamente um endere\u00e7o de e-mail (o que acontece com frequ\u00eancia), o processo \u00e9 semelhante ao da redefini\u00e7\u00e3o de senha\u2014digitamos o endere\u00e7o de e-mail e ent\u00e3o enviamos uma mensagem para esse endere\u00e7o, sem revelar sua exist\u00eancia. A \u00fanica diferen\u00e7a \u00e9 que, desta vez, a mensagem cont\u00e9m apenas o nome de usu\u00e1rio e n\u00e3o a URL de redefini\u00e7\u00e3o da senha. Ou isso, ou na mensagem de e-mail ser\u00e1 informado que n\u00e3o h\u00e1 conta para esse endere\u00e7o.<\/p>\n

Verifica\u00e7\u00e3o de identidade e precis\u00e3o dos endere\u00e7os de e-mail<\/h2>\n

\nUm aspecto crucial da redefini\u00e7\u00e3o de senhas, e, provavelmente, o mais<\/em> crucial aspecto \u00e9 a verifica\u00e7\u00e3o da identidade da pessoa que est\u00e1 tentando realizar a redefini\u00e7\u00e3o. \u00c9 realmente o leg\u00edtimo propriet\u00e1rio da conta, ou algu\u00e9m est\u00e1 tentando invadi-la ou causar inc\u00f4modo ao propriet\u00e1rio?<\/p>\n

\u00c9 claro que o e-mail \u00e9 o canal mais conveniente e o mais amplamente utilizado para verifica\u00e7\u00e3o de identidade. Ele n\u00e3o est\u00e1 imune a manuseios inadequados (\u201cpor descuido\u201d) e h\u00e1 muitos casos em que a simples possibilidade de receber e-mails no endere\u00e7o do propriet\u00e1rio da conta n\u00e3o \u00e9 suficiente, quando uma alta confiabilidade na identifica\u00e7\u00e3o \u00e9 necess\u00e1ria (da\u00ed a utiliza\u00e7\u00e3o da autentica\u00e7\u00e3o em dois fatores), no entanto, quase sempre, \u00e9 o ponto de partida do processo de redefini\u00e7\u00e3o.<\/p>\n

Se o e-mail tiver um papel na garantia de confian\u00e7a, o primeiro passo \u00e9 assegurar que o endere\u00e7o de e-mail est\u00e1, de fato, correto. Se algu\u00e9m cometeu um erro em um caractere, ent\u00e3o, \u00e9 evidente que a redefini\u00e7\u00e3o n\u00e3o come\u00e7ar\u00e1. O processo de verifica\u00e7\u00e3o do e-mail no momento do registro \u00e9 uma maneira confi\u00e1vel de validar o endere\u00e7o. Todos n\u00f3s j\u00e1 vimos isso na pr\u00e1tica: voc\u00ea se registra, um e-mail \u00e9 enviado com uma URL \u00fanica que deve ser clicada, o que confirma que voc\u00ea realmente \u00e9 o propriet\u00e1rio dessa conta de e-mail. A impossibilidade de entrar no sistema at\u00e9 a conclus\u00e3o desse processo garante uma motiva\u00e7\u00e3o para confirmar o endere\u00e7o.<\/p>\n

Assim como em muitos outros aspectos da seguran\u00e7a, esse modelo reduz a usabilidade em troca de garantir um n\u00edvel mais alto de seguran\u00e7a em rela\u00e7\u00e3o \u00e0 confiabilidade da identidade do usu\u00e1rio. Isso pode ser aceit\u00e1vel para um site que o usu\u00e1rio valoriza e que ir\u00e1, de bom grado, adicionar mais uma etapa ao processo (servi\u00e7os pagos, banco, etc.), mas tais coisas podem afastar o usu\u00e1rio se ele perceber a conta como 'descart\u00e1vel' e a utilizar, por exemplo, apenas como um meio de comentar uma postagem.<\/p>\n

Identifica\u00e7\u00e3o de quem iniciou o processo de redefini\u00e7\u00e3o<\/h2>\n

\n\u00c9 evidente que h\u00e1 raz\u00f5es para o uso malicioso da fun\u00e7\u00e3o de redefini\u00e7\u00e3o, e os atacantes podem explor\u00e1-la de v\u00e1rias maneiras diferentes. Um truque simples que podemos usar para ajudar a confirmar a origem do pedido (esse truque geralmente<\/em> funciona) \u00e9 adicionar ao e-mail de redefini\u00e7\u00e3o o endere\u00e7o IP do solicitante. Isso fornece ao destinat\u00e1rio alguma<\/em> informa\u00e7\u00e3o para identificar a origem do pedido.<\/p>\n

Aqui est\u00e1 um exemplo da fun\u00e7\u00e3o de redefini\u00e7\u00e3o que estou atualmente integrando ao ASafaWeb:<\/p>\n

\"Tudo
\nO link \"find out more\" (\"Saiba mais\") direciona o usu\u00e1rio para o site ip-adress.com<\/a><\/noindex>, que informa detalhes como a localiza\u00e7\u00e3o e a organiza\u00e7\u00e3o do solicitante do reset:<\/p>\n

\"Tudo
\n\u00c9 claro que qualquer um que deseje ocultar sua identidade tem v\u00e1rias maneiras de mascarar seu verdadeiro IP, no entanto, essa \u00e9 uma maneira conveniente de adicionar uma identifica\u00e7\u00e3o parcial do solicitante, e em maioria<\/em> dos casos, isso lhe dar\u00e1 uma ideia suficiente de quem est\u00e1 fazendo a solicita\u00e7\u00e3o de redefini\u00e7\u00e3o de senha.<\/p>\n

Notifica\u00e7\u00e3o de mudan\u00e7as por e-mail<\/h2>\n

\nEste post \u00e9 permeado por um tema \u2014 comunica\u00e7\u00e3o; informe o propriet\u00e1rio da conta o m\u00e1ximo poss\u00edvel sobre o que est\u00e1 acontecendo em cada etapa do processo, sem revelar nada que possa ser usado de maneira maliciosa. O mesmo se aplica \u00e0 situa\u00e7\u00e3o em que a senha realmente foi alterada \u2014 informe o propriet\u00e1rio!<\/em><\/strong><\/p>\n

As raz\u00f5es para a altera\u00e7\u00e3o da senha podem surgir de duas fontes:<\/p>\n

    \n
  1. Mudan\u00e7a de senha ap\u00f3s o login, porque o usu\u00e1rio deseja uma nova senha<\/li>\n
  2. Redefini\u00e7\u00e3o de senha sem login, porque o usu\u00e1rio a esqueceu<\/li>\n<\/ol>\n

    \nEmbora este post seja principalmente sobre redefini\u00e7\u00f5es, a notifica\u00e7\u00e3o no primeiro caso diminui o risco de que algu\u00e9m altere a senha sem o conhecimento do leg\u00edtimo propriet\u00e1rio. Como isso pode acontecer? Um cen\u00e1rio bastante comum \u00e9 a obten\u00e7\u00e3o da senha do leg\u00edtimo propriet\u00e1rio (senha reutilizada, vazada de outra fonte; senha obtida por keylogging; senha f\u00e1cil de adivinhar etc.), ap\u00f3s o qual o invasor decide alter\u00e1-la, bloqueando assim o verdadeiro propriet\u00e1rio. Sem a notifica\u00e7\u00e3o por e-mail, o propriet\u00e1rio leg\u00edtimo n\u00e3o saber\u00e1 da altera\u00e7\u00e3o de senha.<\/p>\n

    Claro, no caso de uma redefini\u00e7\u00e3o de senha, o propriet\u00e1rio j\u00e1 deve ter iniciado o processo por conta pr\u00f3pria (ou contornado os m\u00e9todos de verifica\u00e7\u00e3o de identidade mencionados acima), portanto a mudan\u00e7a n\u00e3o deve<\/em> ser uma surpresa para ele, no entanto, a confirma\u00e7\u00e3o por e-mail ser\u00e1 um feedback positivo e uma verifica\u00e7\u00e3o adicional. Al\u00e9m disso, isso assegura a unidade com o cen\u00e1rio descrito acima.<\/p>\n

    Ah, e caso isso ainda n\u00e3o tenha ficado claro \u2014 n\u00e3o envie a nova senha por e-mail!<\/em><\/strong> Isso pode fazer algu\u00e9m rir, mas isso acontece<\/a><\/noindex>:<\/p>\n

    \"Tudo<\/p>\n

    Logs, logs, logs e mais um pouco de logs<\/h2>\n

    \nA funcionalidade de redefini\u00e7\u00e3o de senha \u00e9 atraente para invasores: o atacante deseja acessar a conta de outra pessoa ou simplesmente causar inconvenientes ao propriet\u00e1rio da conta\/sistema. Muitas das pr\u00e1ticas mencionadas acima ajudam a reduzir a probabilidade de abusos, mas n\u00e3o os previnem, e certamente n\u00e3o impedir\u00e3o as pessoas de tentar usar a funcionalidade de maneira n\u00e3o prevista.<\/p>\n

    Para identificar comportamentos maliciosos, uma pr\u00e1tica absolutamente inestim\u00e1vel \u00e9 o registro em log, e eu me refiro a um registro em log muito detalhado<\/em><\/strong>. Registre tentativas de login malsucedidas, redefini\u00e7\u00f5es de senha, altera\u00e7\u00f5es de senha (ou seja, quando o usu\u00e1rio j\u00e1 est\u00e1 logado) e praticamente tudo que possa ajud\u00e1-lo a entender o que est\u00e1 acontecendo; isso ser\u00e1 muito \u00fatil no futuro. Registre at\u00e9 mesmo partes individuais do processo, por exemplo, uma boa funcionalidade de redefini\u00e7\u00e3o deve incluir a inicia\u00e7\u00e3o da redefini\u00e7\u00e3o pelo site (registre o pedido e tentativas de login para redefini\u00e7\u00e3o com nome de usu\u00e1rio ou e-mail incorretos), registre o acesso ao site pelo URL de redefini\u00e7\u00e3o (incluindo tentativas de usar um token inv\u00e1lido), e depois registre o sucesso ou falha em responder \u00e0 pergunta secreta.<\/em> Quando eu falo sobre registro em log, n\u00e3o me refiro apenas ao registro do acesso \u00e0 p\u00e1gina, mas \u00e0 coleta de o m\u00e1ximo poss\u00edvel de informa\u00e7\u00f5es,<\/p>\n

    desde que n\u00e3o sejam confidenciais . Pessoal,<\/em><\/strong>por favor, n\u00e3o registrem senhas nos logs! Nos logs, \u00e9 necess\u00e1rio registrar a identidade do usu\u00e1rio autenticado (ele estar\u00e1 autenticado se<\/em><\/strong> alterar a senha existente ou tentar redefinir<\/em> a senha de outra pessoa ap\u00f3s o login), quaisquer nomes de usu\u00e1rio ou endere\u00e7os de e-mail testados, al\u00e9m de quaisquer tokens de redefini\u00e7\u00e3o que ele tente usar. Mas tamb\u00e9m vale a pena registrar aspectos como endere\u00e7os IP e, se poss\u00edvel, at\u00e9 mesmo os cabe\u00e7alhos das solicita\u00e7\u00f5es. Isso permite que voc\u00ea recrie n\u00e3o apenas<\/em> o que o usu\u00e1rio (ou invasor) est\u00e1 tentando fazer, mas tamb\u00e9m<\/em> quem ele \u00e9.<\/em> Delegar a responsabilidade a outros executores<\/p>\n

    Delega\u00e7\u00e3o de responsabilidade a outros executores<\/h2>\n

    \nSe voc\u00ea acha que tudo isso representa uma enorme carga de trabalho, n\u00e3o est\u00e1 sozinho. Na verdade, construir um sistema confi\u00e1vel para gerenciar contas n\u00e3o \u00e9 uma tarefa simples. N\u00e3o \u00e9 que seja tecnicamente dif\u00edcil, mas existem muitas particularidades. N\u00e3o se resume apenas \u00e0 redefini\u00e7\u00e3o de senhas; h\u00e1 todo um processo de registro, armazenamento seguro de senhas, tratamento de m\u00faltiplas tentativas de login incorretas, etc. Eu defendo a ideia de utilizar funcionalidades prontas como o provedor de membros ASP.NET<\/a><\/noindex>, mas al\u00e9m disso, ainda \u00e9 necess\u00e1rio fazer muito mais.<\/p>\n

    Hoje, existem muitos fornecedores terceirizados que se disp\u00f5em a lidar com todas essas dificuldades e a abstrair tudo isso em um servi\u00e7o gerenciado. Entre esses servi\u00e7os est\u00e3o OpenID, OAuth e at\u00e9 mesmo o Facebook. Algumas pessoas acreditam cegamente nesse modelo<\/a><\/noindex> (OpenID realmente se mostrou muito bem-sucedido no Stack Overflow), entretanto, outros literalmente o consideram um pesadelo<\/a><\/noindex>.<\/p>\n

    Sem d\u00favida, um servi\u00e7o como o OpenID resolve muitos problemas para os desenvolvedores, por\u00e9m, tamb\u00e9m \u00e9 ineg\u00e1vel que ele traz novos desafios. Eles t\u00eam algum papel? Sim, mas est\u00e1 claro que n\u00e3o vemos uma ado\u00e7\u00e3o em massa dos servi\u00e7os de provedores de autentica\u00e7\u00e3o. Bancos, companhias a\u00e9reas e at\u00e9 lojas \u2014 todos eles implementam seus pr\u00f3prios mecanismos de autentica\u00e7\u00e3o, e \u00e9 evidente que h\u00e1 raz\u00f5es bastante relevantes para isso.<\/p>\n

    Redefini\u00e7\u00e3o maliciosa<\/h2>\n

    \nUm aspecto importante de cada um dos exemplos mencionados acima \u00e9 que a antiga senha s\u00f3 \u00e9 considerada in\u00fatil ap\u00f3s a verifica\u00e7\u00e3o da identidade do propriet\u00e1rio da conta<\/em><\/strong>. Isso \u00e9 crucial, pois se a conta pudesse ser redefinida at\u00e9<\/em> sem verifica\u00e7\u00e3o de identidade, isso abriria espa\u00e7o para v\u00e1rias a\u00e7\u00f5es maliciosas.<\/p>\n

    Aqui est\u00e1 um exemplo: algu\u00e9m participa de um leil\u00e3o online, e perto do final do processo de lances, ele bloqueia os concorrentes iniciando o processo de redefini\u00e7\u00e3o, eliminando-os assim da disputa. \u00c9 evidente que, se uma fun\u00e7\u00e3o de redefini\u00e7\u00e3o mal projetada puder ser explorada, isso pode levar a resultados negativos s\u00e9rios. Vale a pena notar que o bloqueio de contas por meio de tentativas de login incorretas \u00e9 uma situa\u00e7\u00e3o semelhante, mas isso j\u00e1 \u00e9 assunto para outro post.<\/p>\n

    Como mencionei antes, se permitirmos que usu\u00e1rios an\u00f4nimos redefinam a senha de qualquer conta apenas conhecendo seu endere\u00e7o de e-mail, isso cria uma situa\u00e7\u00e3o perfeita para um ataque DoS. Esta pode n\u00e3o ser a forma que estamos acostumados a discutir, mas n\u00e3o existe maneira mais r\u00e1pida de bloquear o acesso a uma conta do que uma fun\u00e7\u00e3o de redefini\u00e7\u00e3o de senha mal planejada. DoS<\/a><\/noindex>, que estamos acostumados a discutir, mas n\u00e3o existe maneira mais r\u00e1pida de bloquear o acesso a uma conta do que uma fun\u00e7\u00e3o de redefini\u00e7\u00e3o de senha mal planejada.<\/p>\n

    O elo mais fraco<\/h2>\n

    \nEm termos de prote\u00e7\u00e3o de uma conta, tudo que foi dito acima \u00e9 excelente, no entanto, voc\u00ea sempre deve lembrar do ecossistema ao redor da conta que est\u00e1 protegendo. Permita-me dar um exemplo:<\/p>\n

    ASafaWeb \u00e9 hospedado em um servi\u00e7o incr\u00edvel oferecido pela AppHarbor. O processo de redefini\u00e7\u00e3o da conta de hospedagem acontece assim:<\/p>\n

    Etapa 1:<\/strong><\/p>\n

    \"Tudo
    \nEtapa 2:<\/strong><\/p>\n

    \"Tudo
    \nEtapa 3:<\/strong><\/p>\n

    \"Tudo
    \nEtapa 4:<\/strong><\/p>\n

    \"Tudo
    \nDepois de ler todas as informa\u00e7\u00f5es anteriores, j\u00e1 \u00e9 f\u00e1cil entender quais aspectos, em um mundo ideal, n\u00f3s implementar\u00edamos um pouco diferente. No entanto, aqui quero dizer que se eu publicar um site como o ASafaWeb no servi\u00e7o da AppHarbor, e ent\u00e3o criar \u00f3timas perguntas e respostas secretas, adicionar um segundo fator de autentica\u00e7\u00e3o e fazer tudo de acordo com as regras, isso n\u00e3o elimina o fato de que o elo mais fraco de todo o processo pode quebrar tudo isso. Se algu\u00e9m autenticar com sucesso na AppHarbor usando minhas informa\u00e7\u00f5es, poder\u00e1 alterar a senha de qualquer conta do ASafaWeb para aquela que desejar!<\/p>\n

    O ponto \u00e9 que a resist\u00eancia da implementa\u00e7\u00e3o de seguran\u00e7a deve ser considerada de maneira hol\u00edstica: \u00e9 necess\u00e1rio simular as amea\u00e7as 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\u00e7o preciso dedicar ao processo de redefini\u00e7\u00e3o da senha do ASafaWeb.<\/p>\n

    Conectando tudo<\/h2>\n

    \nEste post cont\u00e9m uma grande quantidade de informa\u00e7\u00f5es, ent\u00e3o quero concentr\u00e1-las em um esquema visual simples:<\/p>\n

    \"Tudo
    \nLembre-se de que \u00e9 importante fazer o registro detalhado de cada um desses pontos. E isso \u00e9 tudo, \u00e9 simples!<\/p>\n

    Resultados<\/h2>\n

    \nMeu post parece abrangente, no entanto, existem muitos materiais adicionais que eu poderia<\/em> incluir nele, mas decidiu n\u00e3o se envolver nisso por quest\u00f5es de brevidade: o papel do endere\u00e7o de e-mail de recupera\u00e7\u00e3o, a situa\u00e7\u00e3o em que voc\u00ea perde acesso ao e-mail vinculado \u00e0 conta (por exemplo, voc\u00ea foi demitido do trabalho) e assim por diante. Como mencionei anteriormente, a fun\u00e7\u00e3o de redefini\u00e7\u00e3o n\u00e3o \u00e9 t\u00e3o complicada, apenas existem muitos pontos de vista sobre ela.<\/p>\n

    Mesmo que a redefini\u00e7\u00e3o n\u00e3o seja t\u00e3o dif\u00edcil, muitas vezes ela \u00e9 implementada erroneamente. Acima, vimos alguns exemplos de quando a implementa\u00e7\u00e3o pode<\/em> levou a problemas, e h\u00e1 muitos mais precedentes em que uma redefini\u00e7\u00e3o incorreta realmente<\/em> causou problemas. Recentemente foi descoberto que a redefini\u00e7\u00e3o de senha foi usada para roubar bitcoins no valor de 87 mil d\u00f3lares<\/a><\/noindex>. Este \u00e9 um resultado negativo s\u00e9rio!<\/p>\n

    Portanto, tenha cuidado com suas fun\u00e7\u00f5es de redefini\u00e7\u00e3o, modele amea\u00e7as<\/a><\/noindex> em diferentes pontos, e ao projetar a fun\u00e7\u00e3o, n\u00e3o tire seu chap\u00e9u preto, pois existe uma grande probabilidade de que algu\u00e9m mais o usar\u00e1!<\/p>\n

    <\/p>\n

    Em nome da publicidade<\/h4>\n

    \nVDSina<\/b> oferece servidores de baixo custo para loca\u00e7\u00e3o<\/a><\/noindex> com pagamento di\u00e1rio, cada servidor conectado a um canal de Internet de 500 Megabits e protegido gratuitamente contra ataques DDoS!<\/p>\n

    \"Tudo<\/a><\/noindex>
    \n
    Fonte:     habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

    \u0414\u0432\u0443\u0445\u0444\u0430\u043a\u0442\u043e\u0440\u0430\u044f \u0430\u0443\u0442\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u044f \u0412\u0441\u0451 \u043f\u0440\u043e\u0447\u0438\u0442\u0430\u043d\u043d\u043e\u0435 \u0432\u0430\u043c\u0438 \u0432 \u043f\u0435\u0440\u0432\u043e\u0439 \u0447\u0430\u0441\u0442\u0438 \u043a\u0430\u0441\u0430\u043b\u043e\u0441\u044c \u0438\u0434\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u0438 \u043d\u0430 \u043e\u0441\u043d\u043e\u0432\u0430\u043d\u0438\u0438 \u0442\u043e\u0433\u043e, \u0447\u0442\u043e \u0437\u043d\u0430\u0435\u0442 \u0437\u0430\u043f\u0440\u0430\u0448\u0438\u0432\u0430\u044e\u0449\u0438\u0439. \u041e\u043d \u0437\u043d\u0430\u0435\u0442 \u0441\u0432\u043e\u0439 \u0430\u0434\u0440\u0435\u0441 \u044d\u043b\u0435\u043a\u0442\u0440\u043e\u043d\u043d\u043e\u0439 \u043f\u043e\u0447\u0442\u044b, \u0437\u043d\u0430\u0435\u0442, \u043a\u0430\u043a \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u043a \u043d\u0435\u0439 \u0434\u043e\u0441\u0442\u0443\u043f (\u0442.\u0435. \u0437\u043d\u0430\u0435\u0442 \u0441\u0432\u043e\u0439 \u043f\u0430\u0440\u043e\u043b\u044c \u043e\u0442 \u044d\u043b\u0435\u043a\u0442\u0440\u043e\u043d\u043d\u043e\u0439 \u043f\u043e\u0447\u0442\u044b) \u0438 \u0437\u043d\u0430\u0435\u0442 \u043e\u0442\u0432\u0435\u0442\u044b \u043d\u0430 \u0441\u0435\u043a\u0440\u0435\u0442\u043d\u044b\u0435 \u0432\u043e\u043f\u0440\u043e\u0441\u044b. \u00ab\u0417\u043d\u0430\u043d\u0438\u0435\u00bb \u0441\u0447\u0438\u0442\u0430\u0435\u0442\u0441\u044f \u043e\u0434\u043d\u0438\u043c \u0444\u0430\u043a\u0442\u043e\u0440\u043e\u043c \u0430\u0443\u0442\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u0438; \u0434\u0432\u0443\u043c\u044f \u0434\u0440\u0443\u0433\u0438\u043c\u0438 \u0440\u0430\u0441\u043f\u0440\u043e\u0441\u0442\u0440\u0430\u043d\u0451\u043d\u043d\u044b\u043c\u0438 \u0444\u0430\u043a\u0442\u043e\u0440\u0430\u043c\u0438 \u044f\u0432\u043b\u044f\u044e\u0442\u0441\u044f \u0442\u043e, \u0447\u0442\u043e \u0443 \u0432\u0430\u0441 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":97640,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-97639","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Tudo o que voc\u00ea queria saber sobre redefini\u00e7\u00e3o de senhas de forma segura. Parte 2 | ProHoster","description":"Autentica\u00e7\u00e3o de dois fatores Tudo o que voc\u00ea leu na primeira parte diz respeito \u00e0 identifica\u00e7\u00e3o com base no que.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/vsyo-chto-vy-hoteli-znat-o-bezopasnom-sbrose-parolej-chast-2","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0412\u0441\u0451, \u0447\u0442\u043e \u0432\u044b \u0445\u043e\u0442\u0435\u043b\u0438 \u0437\u043d\u0430\u0442\u044c \u043e \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u043c \u0441\u0431\u0440\u043e\u0441\u0435 \u043f\u0430\u0440\u043e\u043b\u0435\u0439. \u0427\u0430\u0441\u0442\u044c 2 | ProHoster","og:description":"\u0414\u0432\u0443\u0445\u0444\u0430\u043a\u0442\u043e\u0440\u0430\u044f \u0430\u0443\u0442\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u044f \u0412\u0441\u0451 \u043f\u0440\u043e\u0447\u0438\u0442\u0430\u043d\u043d\u043e\u0435 \u0432\u0430\u043c\u0438 \u0432 \u043f\u0435\u0440\u0432\u043e\u0439 \u0447\u0430\u0441\u0442\u0438 \u043a\u0430\u0441\u0430\u043b\u043e\u0441\u044c \u0438\u0434\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u0438 \u043d\u0430 \u043e\u0441\u043d\u043e\u0432\u0430\u043d\u0438\u0438 \u0442\u043e\u0433\u043e, \u0447\u0442\u043e.","og:url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/vsyo-chto-vy-hoteli-znat-o-bezopasnom-sbrose-parolej-chast-2","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-10-20T00:42:56+00:00","article:modified_time":"2020-10-20T00:42:56+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"97639","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 10:16:25","updated":"2022-10-03 07:14:42","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/97639","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=97639"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/97639\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/97640"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=97639"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=97639"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=97639"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}