{"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\/es\/blog\/administrirovanie\/vsyo-chto-vy-hoteli-znat-o-bezopasnom-sbrose-parolej-chast-2","title":{"rendered":"Todo lo que quer\u00eda saber sobre el restablecimiento seguro de contrase\u00f1as. Parte 2","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Autenticaci\u00f3n de dos factores<\/h2>\n

\nTodo lo que usted ha le\u00eddo en parte anterior<\/a><\/noindex> relaci\u00f3n con la identificaci\u00f3n se basa en lo que sabe la persona que solicita<\/em><\/strong>. Sabe su direcci\u00f3n de correo electr\u00f3nico, sabe c\u00f3mo acceder a ella (es decir, conoce su contrase\u00f1a de correo electr\u00f3nico) y sabe las respuestas a las preguntas secretas. <\/p>\n

El \"conocimiento\" se considera un factor de autenticaci\u00f3n; los otros dos factores comunes son lo que usted tiene<\/em><\/strong>, como un dispositivo f\u00edsico, y qui\u00e9n es usted<\/em><\/strong>, como huellas dactilares o la retina del ojo.<\/p>\n

\"Todo
\n<\/a><\/noindex>
\nEn la mayor\u00eda de los casos, realizar una identificaci\u00f3n biol\u00f3gica es poco factible, especialmente cuando hablamos de la seguridad de las aplicaciones web, por lo que en la autenticaci\u00f3n de dos factores (two factor authentication, 2FA) generalmente se utiliza el segundo atributo: \"lo que usted tiene\". Una de las opciones populares para este segundo factor es un token f\u00edsico, como RSA SecurID<\/a><\/noindex>:<\/p>\n

\"Todo
\nEl token f\u00edsico se utiliza a menudo para la autenticaci\u00f3n en VPN corporativas y servicios financieros. Para autenticarse en el servicio, es necesario usar tanto la contrase\u00f1a como el c\u00f3digo en el token (que a menudo cambia) junto con un PIN. Te\u00f3ricamente, para identificarse, un atacante debe conocer la contrase\u00f1a, tener el token y tambi\u00e9n conocer el PIN del token. En el escenario de restablecimiento de contrase\u00f1a, la contrase\u00f1a en s\u00ed no es conocida, pero poseer el token puede usarse para confirmar la propiedad de la cuenta. Por supuesto, al igual que con cualquier implementaci\u00f3n de protecci\u00f3n, no proporciona \"protecci\u00f3n contra tontos\"<\/a><\/noindex>, pero definitivamente aumenta la barrera de entrada.<\/p>\n

Uno de los principales problemas de este enfoque es el costo y la log\u00edstica de la implementaci\u00f3n; estamos hablando de entregar dispositivos f\u00edsicos a cada cliente y de educarlos en el nuevo proceso. Adem\u00e1s, los usuarios deben tener el dispositivo consigo, lo que no siempre es posible en el caso de un token f\u00edsico. Otra opci\u00f3n es implementar el segundo factor de autenticaci\u00f3n mediante SMS, que en el caso de 2FA puede servir como confirmaci\u00f3n de que la persona que realiza el proceso de restablecimiento tiene el tel\u00e9fono m\u00f3vil del propietario de la cuenta. As\u00ed es como lo hace Google:<\/p>\n

\"Todo
\nTambi\u00e9n es necesario habilitar la verificaci\u00f3n en dos pasos<\/a><\/noindex>, pero esto significa que en el pr\u00f3ximo restablecimiento de contrase\u00f1a, su tel\u00e9fono m\u00f3vil puede convertirse en un segundo factor de autenticaci\u00f3n. Perm\u00edtanme demostrarlo con mi iPhone por razones que pronto ser\u00e1n claras:<\/p>\n

\"Todo
\nDespu\u00e9s de identificar la direcci\u00f3n de correo electr\u00f3nico, la cuenta de Google determina que la verificaci\u00f3n en dos pasos est\u00e1 activada y podemos restablecer la cuenta a trav\u00e9s de verificaci\u00f3n que se env\u00eda por SMS al tel\u00e9fono m\u00f3vil del propietario de la cuenta:<\/p>\n

\"Todo
\nAhora necesitamos elegir el inicio del proceso de restablecimiento:<\/p>\n

\"Todo
\nEsta acci\u00f3n genera el env\u00edo de un correo electr\u00f3nico a la direcci\u00f3n registrada:<\/p>\n

\"Todo
\nEste correo contiene la URL de restablecimiento:<\/p>\n

\"Todo
\nAl acceder a la URL de restablecimiento se env\u00eda un SMS y el sitio web pide que se ingrese:<\/p>\n

\"Todo
\nEste es el SMS:<\/p>\n

\"Todo
\nDespu\u00e9s de ingresarlo en el navegador, regresamos al territorio del restablecimiento cl\u00e1sico de contrase\u00f1a:<\/p>\n

\"Todo
\nProbablemente esto parece un poco prolijo, y as\u00ed es, pero el formulario confirma que la persona que est\u00e1 restableciendo tiene acceso a la direcci\u00f3n de correo electr\u00f3nico y al tel\u00e9fono m\u00f3vil del propietario de la cuenta. Pero esto puede ser hasta nueve veces m\u00e1s seguro que restablecer la contrase\u00f1a solo a trav\u00e9s del correo electr\u00f3nico. Sin embargo, hay problemas...<\/p>\n

El problema est\u00e1 relacionado con los tel\u00e9fonos inteligentes. El dispositivo mostrado a continuaci\u00f3n solo puede autenticar un factor de autenticaci\u00f3n: puede recibir SMS, pero no correos electr\u00f3nicos:<\/p>\n

\"Todo
\nSin embargo, este dispositivo puede recibir SMS y<\/em> recibir correos sobre el restablecimiento de contrase\u00f1a:<\/p>\n

\"Todo
\nEl problema es que consideramos el correo electr\u00f3nico como el primer factor de autenticaci\u00f3n, y el SMS (o incluso una aplicaci\u00f3n generadora de tokens) como el segundo, pero hoy en d\u00eda est\u00e1n combinados en un solo dispositivo. Por supuesto, esto significa que si alguien accede a su tel\u00e9fono inteligente, toda esta comodidad se reduce a que hemos vuelto a un solo canal; este segundo factor, 'lo que tiene', significa que tambi\u00e9n tiene el primer factor. Y todo esto est\u00e1 protegido por un PIN de cuatro d\u00edgitos... si es que el tel\u00e9fono tiene un PIN en absoluto y<\/em> estaba bloqueado.<\/p>\n

S\u00ed, la funci\u00f3n de 2FA implementada por Google proporciona definitivamente una protecci\u00f3n adicional, pero no est\u00e1 protegida 'contra los necios', y definitivamente no depende de dos canales completamente aut\u00f3nomos.<\/p>\n

Restablecimiento por nombre de usuario frente a restablecimiento por direcci\u00f3n de correo electr\u00f3nico<\/h2>\n

\n\u00bfSe debe permitir el restablecimiento solo a trav\u00e9s de la direcci\u00f3n de correo electr\u00f3nico? \u00bfO el usuario debe poder restablecerlo tambi\u00e9n por nombre? El problema de restablecer por nombre de usuario es que no hay forma de notificar al usuario sobre un nombre de usuario incorrecto, sin revelar<\/em> que otra persona puede tener una cuenta con ese nombre. En la secci\u00f3n anterior, el restablecimiento por correo electr\u00f3nico garantizaba que el propietario leg\u00edtimo de dicha direcci\u00f3n de correo siempre recibir\u00eda informaci\u00f3n de regreso sin la divulgaci\u00f3n p\u00fablica de su existencia en el sistema. Con solo el nombre de usuario, esto es imposible.<\/p>\n

Por lo tanto, la respuesta es breve: solo por correo electr\u00f3nico. Si intentas restablecer solo con el nombre de usuario, habr\u00e1 casos en los que el usuario se preguntar\u00e1 qu\u00e9 ocurri\u00f3, o<\/em> estar\u00e1s revelando la existencia de cuentas. S\u00ed, es solo un nombre de usuario, no una direcci\u00f3n de correo electr\u00f3nico y s\u00ed, cualquiera puede elegir cualquier nombre de usuario (disponible), pero a\u00fan as\u00ed existe una gran probabilidad de que indirectamente est\u00e9s revelando a los propietarios de las cuentas debido a la tendencia de los usuarios a reutilizar nombres.<\/p>\n

\u00bfEntonces qu\u00e9 sucede cuando alguien olvida su nombre de usuario? Suponiendo que el nombre de usuario no sea al mismo tiempo una direcci\u00f3n de correo electr\u00f3nico (lo cual ocurre con frecuencia), el proceso es similar al inicio del restablecimiento de una contrase\u00f1a: introducimos la direcci\u00f3n de correo electr\u00f3nico y luego enviamos un mensaje a esa direcci\u00f3n, sin revelar su existencia. La \u00fanica diferencia es que esta vez el mensaje contiene solo el nombre de usuario y no una URL de restablecimiento de contrase\u00f1a. O eso, o el correo dir\u00e1 que no hay cuenta para esa direcci\u00f3n.<\/p>\n

Verificaci\u00f3n de identidad y precisi\u00f3n de las direcciones de correo electr\u00f3nico<\/h2>\n

\nUn aspecto clave del restablecimiento de contrase\u00f1as, y, probablemente, el m\u00e1s<\/em> clave es la verificaci\u00f3n de la identidad de la persona que intenta realizar el restablecimiento. \u00bfEs realmente el propietario leg\u00edtimo de la cuenta, o alguien est\u00e1 tratando de hackearla o incomodar al propietario?<\/p>\n

Es evidente que el correo electr\u00f3nico es el canal m\u00e1s conveniente y com\u00fan para la verificaci\u00f3n de identidad. No est\u00e1 protegido contra un uso inexperto (\u201cde tonto\u201d), y hay muchos casos en los que la simple capacidad de recibir correos en la direcci\u00f3n del propietario de la cuenta no es suficiente, si se requiere un alto grado de confianza en la identificaci\u00f3n (por eso se utiliza la 2FA), sin embargo, casi siempre es el punto de partida del proceso de restablecimiento.<\/p>\n

Si el correo electr\u00f3nico va a jugar un papel en proporcionar confianza, lo primero que hay que hacer es asegurarse de que la direcci\u00f3n de correo electr\u00f3nico sea realmente correcta. Si alguien comete un error tipogr\u00e1fico, evidentemente, el restablecimiento no comenzar\u00e1. El proceso de verificaci\u00f3n del correo electr\u00f3nico en el momento de registro es una manera confiable de comprobar la validez de la direcci\u00f3n. Todos hemos visto esto en la pr\u00e1ctica: te registras, te env\u00edan un correo con una URL \u00fanica en la que debes hacer clic, lo que confirma que realmente eres el propietario de esa cuenta de correo electr\u00f3nico. La imposibilidad de acceder al sistema hasta finalizar este proceso garantiza que haya motivaci\u00f3n para confirmar la direcci\u00f3n.<\/p>\n

Al igual que en muchos otros aspectos de la seguridad, tal modelo reduce la usabilidad a cambio de proporcionar un mayor grado de seguridad respecto a la identidad del usuario. Esto puede ser aceptable para un sitio web que el usuario valora altamente y que con gusto a\u00f1adir\u00e1 otro paso al proceso (servicios de pago, banca, etc.), pero tales cosas pueden ahuyentar al usuario si percibe su cuenta como \u201cdesechable\u201d y la utiliza simplemente como un medio para comentar una publicaci\u00f3n.<\/p>\n

Identificaci\u00f3n de qui\u00e9n inici\u00f3 el proceso de restablecimiento<\/h2>\n

\nEs evidente que existen razones para el uso malicioso de la funci\u00f3n de restablecimiento, y los atacantes pueden aprovecharla de muchas maneras diferentes. Un truco simple que podemos utilizar para ayudar a confirmar la fuente de la solicitud (este truco generalmente<\/em> funciona) es agregar en el correo de solicitud de restablecimiento la direcci\u00f3n IP del solicitante. Esto proporciona al destinatario cierta<\/em> informaci\u00f3n para identificar la fuente de la solicitud.<\/p>\n

Aqu\u00ed hay un ejemplo de la funci\u00f3n de restablecimiento que estoy integrando en ASafaWeb:<\/p>\n

\"Todo
\nEl enlace \u00abfind out more\u00bb (\u00abSaber m\u00e1s\u00bb) lleva al usuario al sitio web ip-adress.com<\/a><\/noindex>, que informa sobre detalles como la ubicaci\u00f3n y la organizaci\u00f3n del solicitante del restablecimiento:<\/p>\n

\"Todo
\nPor supuesto, cualquier persona que quiera ocultar su identidad tiene muchas formas de ofuscar su verdadera direcci\u00f3n IP, sin embargo, este es un m\u00e9todo conveniente para agregar una identificaci\u00f3n parcial al solicitante, y en la mayor\u00eda de los<\/em> algunos casos, esto te dar\u00e1 una idea suficiente de qui\u00e9n realiza la solicitud de restablecimiento de contrase\u00f1a.<\/p>\n

Notificaci\u00f3n de cambios por correo electr\u00f3nico<\/h2>\n

\nEsta publicaci\u00f3n est\u00e1 impregnada de un tema: la comunicaci\u00f3n; informa al propietario de la cuenta lo m\u00e1s posible sobre lo que sucede en cada etapa del proceso, sin revelar nada que pueda utilizarse con malas intenciones. Lo mismo se aplica a la situaci\u00f3n cuando la contrase\u00f1a realmente ha cambiado \u2014 \u00a1informa al propietario!<\/em><\/strong><\/p>\n

Las razones para cambiar la contrase\u00f1a pueden ser dos fuentes:<\/p>\n

    \n
  1. Cambio de contrase\u00f1a despu\u00e9s de iniciar sesi\u00f3n, porque el usuario quiere una nueva contrase\u00f1a<\/li>\n
  2. Restablecimiento de contrase\u00f1a sin iniciar sesi\u00f3n, porque el usuario la ha olvidado<\/li>\n<\/ol>\n

    \nAunque esta publicaci\u00f3n est\u00e1 principalmente dedicada al restablecimiento, la notificaci\u00f3n en el primer caso reduce el riesgo de que alguien cambie la contrase\u00f1a sin el conocimiento del propietario leg\u00edtimo. \u00bfC\u00f3mo puede suceder esto? Un escenario muy com\u00fan es obtener la contrase\u00f1a del propietario leg\u00edtimo (una contrase\u00f1a reutilizada que se ha filtrado de otra fuente; una contrase\u00f1a obtenida mediante keylogging; una contrase\u00f1a f\u00e1cilmente adivinable, etc.), despu\u00e9s de lo cual un atacante decide cambiarla, bloqueando as\u00ed al propietario. Sin la notificaci\u00f3n por correo electr\u00f3nico, el verdadero propietario no sabr\u00e1 sobre el cambio de contrase\u00f1a.<\/p>\n

    Por supuesto, en el caso de un restablecimiento de contrase\u00f1a, el propietario ya deber\u00eda haber iniciado el proceso por s\u00ed mismo (o eludido los m\u00e9todos de verificaci\u00f3n de identidad mencionados anteriormente), por lo que el cambio no deber\u00eda<\/em> no deber\u00eda ser una sorpresa para \u00e9l, sin embargo, la confirmaci\u00f3n por correo electr\u00f3nico ser\u00e1 un feedback positivo y una verificaci\u00f3n adicional. Adem\u00e1s, esto asegura la coherencia con el escenario descrito anteriormente.<\/p>\n

    Oh, y en caso de que no sea obvio \u2014 \u00a1no env\u00edes la nueva contrase\u00f1a por correo!<\/em><\/strong> A algunos eso les puede parecer gracioso, pero eso sucede<\/a><\/noindex>:<\/p>\n

    \"Todo<\/p>\n

    Registros, registros, registros y un poco m\u00e1s de registros<\/h2>\n

    \nLa funci\u00f3n de restablecimiento de contrase\u00f1as resulta atractiva para los atacantes: ya sea que quieran acceder a la cuenta de otra persona o simplemente causar molestias al propietario de la cuenta\/sistema. Muchas de las pr\u00e1cticas descritas anteriormente permiten reducir la probabilidad de abusos, pero no los previenen, y definitivamente no impedir\u00e1n que las personas intenten usar la funci\u00f3n de manera inapropiada.<\/p>\n

    Para reconocer comportamientos maliciosos, la pr\u00e1ctica del registro es absolutamente invaluable, y me refiero a un registro muy detallado<\/em><\/strong>. Registre los intentos fallidos de inicio de sesi\u00f3n, los restablecimientos de contrase\u00f1as, los cambios de contrase\u00f1as (es decir, cuando el usuario ya ha iniciado sesi\u00f3n) y pr\u00e1cticamente todo lo que pueda ayudarle a comprender lo que est\u00e1 sucediendo; esto ser\u00e1 muy \u00fatil en el futuro. Registre incluso partes individuales del proceso, por ejemplo, una buena funci\u00f3n de restablecimiento deber\u00eda incluir la iniciaci\u00f3n del restablecimiento a trav\u00e9s del sitio web (registre la solicitud e intentos de inicio de sesi\u00f3n para restablecimientos con nombres de usuario o correos electr\u00f3nicos incorrectos), registre las visitas al sitio web a la URL de restablecimiento (incluidas las tentativas de usar un token incorrecto), y luego registre el \u00e9xito o el fracaso de la respuesta a la pregunta secreta.<\/em> Cuando hablo de registro, me refiero no solo a registrar el hecho de que se carg\u00f3 una p\u00e1gina, sino tambi\u00e9n a recopilar la mayor cantidad posible de informaci\u00f3n,<\/p>\n

    si no es confidencial . Chicos,<\/em><\/strong>\u00a1por favor, no registren contrase\u00f1as en los logs! En los logs debe registrarse la identidad del usuario autenticado (\u00e9l estar\u00e1 autenticado si<\/em><\/strong> cambia una contrase\u00f1a existente o intenta restablecer<\/em> la contrase\u00f1a de otra persona despu\u00e9s de haber iniciado sesi\u00f3n), cualquier nombre de usuario o direcci\u00f3n de correo electr\u00f3nico que intente, as\u00ed como cualquier token de restablecimiento que intente utilizar. Pero tambi\u00e9n vale la pena registrar aspectos como las direcciones IP y, si es posible, incluso los encabezados de las solicitudes. Esto le permite recrear no solo lo que el<\/em> usuario (o atacante) intenta hacer, sino tambi\u00e9n que<\/em> qui\u00e9n es \u00e9l. qui\u00e9n<\/em> Delegar responsabilidades a otros ejecutores<\/p>\n

    Delegaci\u00f3n de responsabilidades a otros ejecutores<\/h2>\n

    \nSi crees que todo esto representa una gran cantidad de trabajo, no est\u00e1s solo. De hecho, construir un sistema confiable para gestionar cuentas es una tarea compleja. No se trata de que sea dif\u00edcil t\u00e9cnicamente, simplemente tiene muchas particularidades. Implica no solo el restablecimiento, sino que tambi\u00e9n existe todo un proceso de registro, almacenamiento seguro de contrase\u00f1as, manejo de m\u00faltiples intentos fallidos de inicio de sesi\u00f3n, etc., etc. Promuevo la idea de utilizar funcionalidades listas como el proveedor de membres\u00eda de ASP.NET<\/a><\/noindex>, pero adem\u00e1s de eso, se necesita hacer mucho m\u00e1s.<\/p>\n

    Hoy en d\u00eda, hay muchos proveedores externos que se hacen cargo de todas las molestias y abstraen todo esto en un servicio administrado. Entre estos servicios est\u00e1n OpenID, OAuth e incluso Facebook. Algunas personas creen firmemente en este modelo<\/a><\/noindex> (OpenID ha tenido mucho \u00e9xito en Stack Overflow), sin embargo, otros lo consideran un verdadero desastre<\/a><\/noindex>.<\/p>\n

    Sin duda, un servicio como OpenID resuelve muchos problemas para los desarrolladores, pero tambi\u00e9n es innegable que introduce nuevos. \u00bfJuegan alg\u00fan papel? S\u00ed, pero es evidente que no observamos un uso masivo de los servicios de proveedores de autenticaci\u00f3n. Bancos, aerol\u00edneas e incluso tiendas, todos implementan su propio mecanismo de autenticaci\u00f3n, y es claro que hay razones muy v\u00e1lidas para esto.<\/p>\n

    Restablecimiento malintencionado<\/h2>\n

    \nUn aspecto importante de cada uno de los ejemplos mencionados anteriormente es que la antigua contrase\u00f1a se considera in\u00fatil solo despu\u00e9s de verificar la identidad del propietario de la cuenta<\/em><\/strong>. Esto es crucial, porque si la cuenta se pudiera restablecer hasta<\/em> sin verificaci\u00f3n de identificaci\u00f3n, se abrir\u00eda la puerta a todo tipo de acciones malintencionadas.<\/p>\n

    Aqu\u00ed hay un ejemplo: alguien participa en una subasta en un sitio y, cerca del final del proceso de pujas, bloquea a los competidores iniciando el proceso de restablecimiento, elimin\u00e1ndolos as\u00ed de la subasta. Es evidente que si una funci\u00f3n de restablecimiento dise\u00f1ada deficientemente puede ser explotada de manera incorrecta, esto podr\u00eda llevar a graves consecuencias negativas. Cabe mencionar que bloquear cuentas mediante intentos fallidos de inicio de sesi\u00f3n es una situaci\u00f3n similar, pero ese es un tema para otro art\u00edculo.<\/p>\n

    Como mencion\u00e9 anteriormente, si se permite a los usuarios an\u00f3nimos restablecer la contrase\u00f1a de cualquier cuenta solo con la direcci\u00f3n de correo electr\u00f3nico, es una situaci\u00f3n perfecta para un ataque de tipo \"denegaci\u00f3n de servicio\". Esto puede no ser el tipo de ataque del que estamos acostumbrados a hablar, pero no hay una manera m\u00e1s r\u00e1pida de bloquear el acceso a una cuenta que con una funci\u00f3n de restablecimiento de contrase\u00f1a mal pensada. DoS<\/a><\/noindex>, del que estamos acostumbrados a hablar, pero no existe una forma m\u00e1s r\u00e1pida de bloquear el acceso a una cuenta que con una funci\u00f3n de restablecimiento de contrase\u00f1a mal dise\u00f1ada.<\/p>\n

    El eslab\u00f3n m\u00e1s d\u00e9bil<\/h2>\n

    \nDesde la perspectiva de proteger una cuenta, todo lo mencionado anteriormente es admirable, pero siempre debes tener en cuenta el ecosistema que rodea a la cuenta que est\u00e1s protegiendo. Perm\u00edteme dar un ejemplo:<\/p>\n

    ASafaWeb est\u00e1 alojado en un servicio incre\u00edble proporcionado por AppHarbor. El proceso de restablecimiento de la cuenta de hosting es el siguiente:<\/p>\n

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

    \"Todo
    \nPaso 2:<\/strong><\/p>\n

    \"Todo
    \nPaso 3:<\/strong><\/p>\n

    \"Todo
    \nPaso 4:<\/strong><\/p>\n

    \"Todo
    \nDespu\u00e9s de leer toda la informaci\u00f3n anterior, es f\u00e1cil entender qu\u00e9 aspectos en un mundo ideal implementar\u00edamos de manera diferente. Sin embargo, quiero decir que si publico un sitio como ASafaWeb en el servicio de AppHarbor, y luego creo excelentes preguntas y respuestas secretas, agrego un segundo factor de autenticaci\u00f3n y hago todo lo dem\u00e1s de acuerdo a las reglas, eso no cambia el hecho de que el eslab\u00f3n m\u00e1s d\u00e9bil de todo el proceso puede romper todo esto. Si alguien se autentica exitosamente en AppHarbor utilizando mi informaci\u00f3n, podr\u00e1 cambiar la contrase\u00f1a de cualquier cuenta de ASafaWeb a su conveniencia.<\/p>\n

    La cuesti\u00f3n es que la resistencia de la implementaci\u00f3n de la seguridad debe ser considerada de manera integral: es necesario modelar las amenazas de cada punto de entrada del sistema, incluso si es un proceso superficial, como iniciar sesi\u00f3n en AppHarbor. Esto deber\u00eda darme una buena idea de cu\u00e1ntos esfuerzos necesito invertir en el proceso de restablecimiento de contrase\u00f1a de ASafaWeb.<\/p>\n

    Uniendo todo<\/h2>\n

    \nEsta publicaci\u00f3n contiene una gran cantidad de informaci\u00f3n, por lo que quiero concentrarla en un esquema visual simple:<\/p>\n

    \"Todo
    \nRecuerda que debes realizar un registro lo m\u00e1s detallado posible de cada uno de estos puntos. Eso es todo, \u00a1es as\u00ed de simple!<\/p>\n

    Resultados<\/h2>\n

    \nMi publicaci\u00f3n parece abarcativa, sin embargo, hay muchos materiales adicionales que podr\u00eda haber<\/em> incluirlo, pero decid\u00ed evitar esto por brevedad: el papel de la direcci\u00f3n de correo electr\u00f3nico de recuperaci\u00f3n, la situaci\u00f3n en la que pierdes el acceso al correo electr\u00f3nico vinculado a la cuenta (por ejemplo, si dejaste tu trabajo) y as\u00ed sucesivamente. Como mencion\u00e9 anteriormente, la funci\u00f3n de restablecimiento no es tan complicada, solo que hay muchos puntos de vista sobre ella.<\/p>\n

    Incluso aunque el restablecimiento no es tan dif\u00edcil, a menudo se implementa incorrectamente. Arriba vimos un par de ejemplos donde la implementaci\u00f3n puede<\/em> puede causar problemas, y hay muchos m\u00e1s precedentes donde un restablecimiento incorrecto realmente<\/em> ha causado problemas. Recientemente se descubri\u00f3 que se utiliz\u00f3 el restablecimiento de contrase\u00f1a para robar bitcoins por un valor de 87 mil d\u00f3lares.<\/a><\/noindex>\u00a1Ese es un resultado negativo serio!<\/p>\n

    As\u00ed que ten cuidado con tus funciones de restablecimiento, modela amenazas<\/a><\/noindex> en diferentes puntos, y al dise\u00f1ar la funci\u00f3n no te quites el sombrero negro, porque hay una gran probabilidad de que alguien m\u00e1s se lo ponga.<\/p>\n

    <\/p>\n

    Publicidad<\/h4>\n

    \nVDSina<\/b> ofrece planes econ\u00f3micos servidores en alquiler<\/a><\/noindex> con pago diario, cada servidor est\u00e1 conectado a un canal de Internet de 500 megabits y est\u00e1 protegido gratuitamente contra ataques DDoS.<\/p>\n

    \"Todo<\/a><\/noindex>
    \n
    Fuente:     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\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\udd47Todo lo que quer\u00edas saber sobre el restablecimiento seguro de contrase\u00f1as. Parte 2 | ProHoster","description":"Autenticaci\u00f3n de dos factores Todo lo que has le\u00eddo en la primera parte se refer\u00eda a la identificaci\u00f3n basada en lo que.","canonical_url":"https:\/\/prohoster.info\/es\/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":"es_ES","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\/es\/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\/es\/wp-json\/wp\/v2\/posts\/97639","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=97639"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/97639\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/97640"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=97639"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=97639"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=97639"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}