Autenticación de dos factores
Todo lo que usted ha leído en relación con la identificación se basa en lo que sabe la persona que solicita. Sabe su dirección de correo electrónico, sabe cómo acceder a ella (es decir, conoce su contraseña de correo electrónico) y sabe las respuestas a las preguntas secretas.
El "conocimiento" se considera un factor de autenticación; los otros dos factores comunes son lo que usted tiene, como un dispositivo físico, y quién es usted, como huellas dactilares o la retina del ojo.
En la mayoría de los casos, realizar una identificación biológica es poco factible, especialmente cuando hablamos de la seguridad de las aplicaciones web, por lo que en la autenticación 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ísico, como :
El token físico se utiliza a menudo para la autenticación en VPN corporativas y servicios financieros. Para autenticarse en el servicio, es necesario usar tanto la contraseña como el código en el token (que a menudo cambia) junto con un PIN. Teóricamente, para identificarse, un atacante debe conocer la contraseña, tener el token y también conocer el PIN del token. En el escenario de restablecimiento de contraseña, la contraseña en sí no es conocida, pero poseer el token puede usarse para confirmar la propiedad de la cuenta. Por supuesto, al igual que con cualquier implementación de protección, , pero definitivamente aumenta la barrera de entrada.
Uno de los principales problemas de este enfoque es el costo y la logística de la implementación; estamos hablando de entregar dispositivos físicos a cada cliente y de educarlos en el nuevo proceso. Además, los usuarios deben tener el dispositivo consigo, lo que no siempre es posible en el caso de un token físico. Otra opción es implementar el segundo factor de autenticación mediante SMS, que en el caso de 2FA puede servir como confirmación de que la persona que realiza el proceso de restablecimiento tiene el teléfono móvil del propietario de la cuenta. Así es como lo hace Google:
También es necesario habilitar , pero esto significa que en el próximo restablecimiento de contraseña, su teléfono móvil puede convertirse en un segundo factor de autenticación. Permítanme demostrarlo con mi iPhone por razones que pronto serán claras:
Después de identificar la dirección de correo electrónico, la cuenta de Google determina que la verificación en dos pasos está activada y podemos restablecer la cuenta a través de verificación que se envía por SMS al teléfono móvil del propietario de la cuenta:
Ahora necesitamos elegir el inicio del proceso de restablecimiento:
Esta acción genera el envío de un correo electrónico a la dirección registrada:
Este correo contiene la URL de restablecimiento:
Al acceder a la URL de restablecimiento se envía un SMS y el sitio web pide que se ingrese:
Este es el SMS:
Después de ingresarlo en el navegador, regresamos al territorio del restablecimiento clásico de contraseña:
Probablemente esto parece un poco prolijo, y así es, pero el formulario confirma que la persona que está restableciendo tiene acceso a la dirección de correo electrónico y al teléfono móvil del propietario de la cuenta. Pero esto puede ser hasta nueve veces más seguro que restablecer la contraseña solo a través del correo electrónico. Sin embargo, hay problemas...
El problema está relacionado con los teléfonos inteligentes. El dispositivo mostrado a continuación solo puede autenticar un factor de autenticación: puede recibir SMS, pero no correos electrónicos:
Sin embargo, este dispositivo puede recibir SMS y recibir correos sobre el restablecimiento de contraseña:
El problema es que consideramos el correo electrónico como el primer factor de autenticación, y el SMS (o incluso una aplicación generadora de tokens) como el segundo, pero hoy en día están combinados en un solo dispositivo. Por supuesto, esto significa que si alguien accede a su teléfono inteligente, toda esta comodidad se reduce a que hemos vuelto a un solo canal; este segundo factor, 'lo que tiene', significa que también tiene el primer factor. Y todo esto está protegido por un PIN de cuatro dígitos... si es que el teléfono tiene un PIN en absoluto y estaba bloqueado.
Sí, la función de 2FA implementada por Google proporciona definitivamente una protección adicional, pero no está protegida 'contra los necios', y definitivamente no depende de dos canales completamente autónomos.
Restablecimiento por nombre de usuario frente a restablecimiento por dirección de correo electrónico
¿Se debe permitir el restablecimiento solo a través de la dirección de correo electrónico? ¿O el usuario debe poder restablecerlo también 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 que otra persona puede tener una cuenta con ese nombre. En la sección anterior, el restablecimiento por correo electrónico garantizaba que el propietario legítimo de dicha dirección de correo siempre recibiría información de regreso sin la divulgación pública de su existencia en el sistema. Con solo el nombre de usuario, esto es imposible.
Por lo tanto, la respuesta es breve: solo por correo electrónico. Si intentas restablecer solo con el nombre de usuario, habrá casos en los que el usuario se preguntará qué ocurrió, o estarás revelando la existencia de cuentas. Sí, es solo un nombre de usuario, no una dirección de correo electrónico y sí, cualquiera puede elegir cualquier nombre de usuario (disponible), pero aún así existe una gran probabilidad de que indirectamente estés revelando a los propietarios de las cuentas debido a la tendencia de los usuarios a reutilizar nombres.
¿Entonces qué sucede cuando alguien olvida su nombre de usuario? Suponiendo que el nombre de usuario no sea al mismo tiempo una dirección de correo electrónico (lo cual ocurre con frecuencia), el proceso es similar al inicio del restablecimiento de una contraseña: introducimos la dirección de correo electrónico y luego enviamos un mensaje a esa dirección, sin revelar su existencia. La única diferencia es que esta vez el mensaje contiene solo el nombre de usuario y no una URL de restablecimiento de contraseña. O eso, o el correo dirá que no hay cuenta para esa dirección.
Verificación de identidad y precisión de las direcciones de correo electrónico
Un aspecto clave del restablecimiento de contraseñas, y, probablemente, el más clave es la verificación de la identidad de la persona que intenta realizar el restablecimiento. ¿Es realmente el propietario legítimo de la cuenta, o alguien está tratando de hackearla o incomodar al propietario?
Es evidente que el correo electrónico es el canal más conveniente y común para la verificación de identidad. No está protegido contra un uso inexperto (“de tonto”), y hay muchos casos en los que la simple capacidad de recibir correos en la dirección del propietario de la cuenta no es suficiente, si se requiere un alto grado de confianza en la identificación (por eso se utiliza la 2FA), sin embargo, casi siempre es el punto de partida del proceso de restablecimiento.
Si el correo electrónico va a jugar un papel en proporcionar confianza, lo primero que hay que hacer es asegurarse de que la dirección de correo electrónico sea realmente correcta. Si alguien comete un error tipográfico, evidentemente, el restablecimiento no comenzará. El proceso de verificación del correo electrónico en el momento de registro es una manera confiable de comprobar la validez de la dirección. Todos hemos visto esto en la práctica: te registras, te envían un correo con una URL única en la que debes hacer clic, lo que confirma que realmente eres el propietario de esa cuenta de correo electrónico. La imposibilidad de acceder al sistema hasta finalizar este proceso garantiza que haya motivación para confirmar la direcció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ñadirá otro paso al proceso (servicios de pago, banca, etc.), pero tales cosas pueden ahuyentar al usuario si percibe su cuenta como “desechable” y la utiliza simplemente como un medio para comentar una publicación.
Identificación de quién inició el proceso de restablecimiento
Es evidente que existen razones para el uso malicioso de la función 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 funciona) es agregar en el correo de solicitud de restablecimiento la dirección IP del solicitante. Esto proporciona al destinatario cierta información para identificar la fuente de la solicitud.
Aquí hay un ejemplo de la función de restablecimiento que estoy integrando en ASafaWeb:
El enlace «find out more» («Saber más») lleva al usuario al sitio web , que informa sobre detalles como la ubicación y la organización del solicitante del restablecimiento:
Por supuesto, cualquier persona que quiera ocultar su identidad tiene muchas formas de ofuscar su verdadera dirección IP, sin embargo, este es un método conveniente para agregar una identificación parcial al solicitante, y en la mayoría de los algunos casos, esto te dará una idea suficiente de quién realiza la solicitud de restablecimiento de contraseña.
Notificación de cambios por correo electrónico
Esta publicación está impregnada de un tema: la comunicación; informa al propietario de la cuenta lo más 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ón cuando la contraseña realmente ha cambiado — ¡informa al propietario!
Las razones para cambiar la contraseña pueden ser dos fuentes:
- Cambio de contraseña después de iniciar sesión, porque el usuario quiere una nueva contraseña
- Restablecimiento de contraseña sin iniciar sesión, porque el usuario la ha olvidado
Aunque esta publicación está principalmente dedicada al restablecimiento, la notificación en el primer caso reduce el riesgo de que alguien cambie la contraseña sin el conocimiento del propietario legítimo. ¿Cómo puede suceder esto? Un escenario muy común es obtener la contraseña del propietario legítimo (una contraseña reutilizada que se ha filtrado de otra fuente; una contraseña obtenida mediante keylogging; una contraseña fácilmente adivinable, etc.), después de lo cual un atacante decide cambiarla, bloqueando así al propietario. Sin la notificación por correo electrónico, el verdadero propietario no sabrá sobre el cambio de contraseña.
Por supuesto, en el caso de un restablecimiento de contraseña, el propietario ya debería haber iniciado el proceso por sí mismo (o eludido los métodos de verificación de identidad mencionados anteriormente), por lo que el cambio no debería no debería ser una sorpresa para él, sin embargo, la confirmación por correo electrónico será un feedback positivo y una verificación adicional. Además, esto asegura la coherencia con el escenario descrito anteriormente.
Oh, y en caso de que no sea obvio — ¡no envíes la nueva contraseña por correo! A algunos eso les puede parecer gracioso, pero :
Registros, registros, registros y un poco más de registros
La función de restablecimiento de contraseñas 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ácticas descritas anteriormente permiten reducir la probabilidad de abusos, pero no los previenen, y definitivamente no impedirán que las personas intenten usar la función de manera inapropiada.
Para reconocer comportamientos maliciosos, la práctica del registro es absolutamente invaluable, y me refiero a un registro muy detallado. Registre los intentos fallidos de inicio de sesión, los restablecimientos de contraseñas, los cambios de contraseñas (es decir, cuando el usuario ya ha iniciado sesión) y prácticamente todo lo que pueda ayudarle a comprender lo que está sucediendo; esto será muy útil en el futuro. Registre incluso partes individuales del proceso, por ejemplo, una buena función de restablecimiento debería incluir la iniciación del restablecimiento a través del sitio web (registre la solicitud e intentos de inicio de sesión para restablecimientos con nombres de usuario o correos electrónicos incorrectos), registre las visitas al sitio web a la URL de restablecimiento (incluidas las tentativas de usar un token incorrecto), y luego registre el éxito o el fracaso de la respuesta a la pregunta secreta. Cuando hablo de registro, me refiero no solo a registrar el hecho de que se cargó una página, sino también a recopilar la mayor cantidad posible de información,
si no es confidencial . Chicos,¡por favor, no registren contraseñas en los logs! En los logs debe registrarse la identidad del usuario autenticado (él estará autenticado si cambia una contraseña existente o intenta restablecer la contraseña de otra persona después de haber iniciado sesión), cualquier nombre de usuario o dirección de correo electrónico que intente, así como cualquier token de restablecimiento que intente utilizar. Pero también 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 usuario (o atacante) intenta hacer, sino también que quién es él. quién Delegar responsabilidades a otros ejecutores
Delegación de responsabilidades a otros ejecutores
Si crees que todo esto representa una gran cantidad de trabajo, no estás solo. De hecho, construir un sistema confiable para gestionar cuentas es una tarea compleja. No se trata de que sea difícil técnicamente, simplemente tiene muchas particularidades. Implica no solo el restablecimiento, sino que también existe todo un proceso de registro, almacenamiento seguro de contraseñas, manejo de múltiples intentos fallidos de inicio de sesión, etc., etc. , pero además de eso, se necesita hacer mucho más.
Hoy en día, hay muchos proveedores externos que se hacen cargo de todas las molestias y abstraen todo esto en un servicio administrado. Entre estos servicios están OpenID, OAuth e incluso Facebook. Algunas personas (OpenID ha tenido mucho éxito en Stack Overflow), sin embargo, otros .
Sin duda, un servicio como OpenID resuelve muchos problemas para los desarrolladores, pero también es innegable que introduce nuevos. ¿Juegan algún papel? Sí, pero es evidente que no observamos un uso masivo de los servicios de proveedores de autenticación. Bancos, aerolíneas e incluso tiendas, todos implementan su propio mecanismo de autenticación, y es claro que hay razones muy válidas para esto.
Restablecimiento malintencionado
Un aspecto importante de cada uno de los ejemplos mencionados anteriormente es que la antigua contraseña se considera inútil solo después de verificar la identidad del propietario de la cuenta. Esto es crucial, porque si la cuenta se pudiera restablecer hasta sin verificación de identificación, se abriría la puerta a todo tipo de acciones malintencionadas.
Aquí 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ándolos así de la subasta. Es evidente que si una función de restablecimiento diseñada deficientemente puede ser explotada de manera incorrecta, esto podría llevar a graves consecuencias negativas. Cabe mencionar que bloquear cuentas mediante intentos fallidos de inicio de sesión es una situación similar, pero ese es un tema para otro artículo.
Como mencioné anteriormente, si se permite a los usuarios anónimos restablecer la contraseña de cualquier cuenta solo con la dirección de correo electrónico, es una situación perfecta para un ataque de tipo "denegación de servicio". Esto puede no ser el tipo de ataque del que estamos acostumbrados a hablar, pero no hay una manera más rápida de bloquear el acceso a una cuenta que con una función de restablecimiento de contraseña mal pensada. , del que estamos acostumbrados a hablar, pero no existe una forma más rápida de bloquear el acceso a una cuenta que con una función de restablecimiento de contraseña mal diseñada.
El eslabón más débil
Desde 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ás protegiendo. Permíteme dar un ejemplo:
ASafaWeb está alojado en un servicio increíble proporcionado por AppHarbor. El proceso de restablecimiento de la cuenta de hosting es el siguiente:
Paso 1:
Paso 2:
Paso 3:
Paso 4:
Después de leer toda la información anterior, es fácil entender qué aspectos en un mundo ideal implementaríamos 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ón y hago todo lo demás de acuerdo a las reglas, eso no cambia el hecho de que el eslabón más débil de todo el proceso puede romper todo esto. Si alguien se autentica exitosamente en AppHarbor utilizando mi información, podrá cambiar la contraseña de cualquier cuenta de ASafaWeb a su conveniencia.
La cuestión es que la resistencia de la implementación 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ón en AppHarbor. Esto debería darme una buena idea de cuántos esfuerzos necesito invertir en el proceso de restablecimiento de contraseña de ASafaWeb.
Uniendo todo
Esta publicación contiene una gran cantidad de información, por lo que quiero concentrarla en un esquema visual simple:
Recuerda que debes realizar un registro lo más detallado posible de cada uno de estos puntos. Eso es todo, ¡es así de simple!
Resultados
Mi publicación parece abarcativa, sin embargo, hay muchos materiales adicionales que podría haber incluirlo, pero decidí evitar esto por brevedad: el papel de la dirección de correo electrónico de recuperación, la situación en la que pierdes el acceso al correo electrónico vinculado a la cuenta (por ejemplo, si dejaste tu trabajo) y así sucesivamente. Como mencioné anteriormente, la función de restablecimiento no es tan complicada, solo que hay muchos puntos de vista sobre ella.
Incluso aunque el restablecimiento no es tan difícil, a menudo se implementa incorrectamente. Arriba vimos un par de ejemplos donde la implementación puede puede causar problemas, y hay muchos más precedentes donde un restablecimiento incorrecto realmente ha causado problemas. Recientemente se descubrió que ¡Ese es un resultado negativo serio!
Así que ten cuidado con tus funciones de restablecimiento, en diferentes puntos, y al diseñar la función no te quites el sombrero negro, porque hay una gran probabilidad de que alguien más se lo ponga.
Publicidad
VDSina ofrece planes económicos con pago diario, cada servidor está conectado a un canal de Internet de 500 megabits y está protegido gratuitamente contra ataques DDoS.
Fuente: habr.com
