Autenticación de dos factores
Todo lo que leyó en la primera parte se refiere a la identificación basada en lo que sabe el solicitante . Conoce su dirección de correo electrónico, sabe cómo acceder a ella (es decir, conoce su contraseña de correo electrónico) y conoce las respuestas a las preguntas de seguridad.
El "conocimiento" cuenta como un factor de autenticación; otros dos factores comunes son lo que tienes , como un dispositivo físico, y quién eres , como huellas dactilares o retina.
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 la autenticación de dos factores (2FA) generalmente usa el segundo atributo: "lo que tienes". Una variación popular de este segundo factor es un token físico como RSA SecurID :
El token físico se usa a menudo para la autenticación en VPN corporativas y servicios financieros. Para la autenticación en el servicio, debe utilizar tanto la contraseña como el código del token (que cambia con frecuencia) en combinación con el PIN. En teoría, para la identificación, el atacante debe conocer la contraseña, tener un token y también conocer el PIN del token. En un escenario de restablecimiento de contraseña, la contraseña en sí es obviamente desconocida, pero la posesión del token se puede utilizar para confirmar la propiedad de la cuenta. Por supuesto, como con cualquier implementación de seguridad, esto no es "infalible" , pero definitivamente levanta la barrera de entrada.
Uno de los principales problemas de este enfoque es el costo y la logística de implementación; estamos hablando de entregar dispositivos físicos a cada cliente y enseñarles un nuevo proceso. Además, los usuarios deben tener un dispositivo con ellos, lo que no siempre es el caso con 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 reinicio tiene el teléfono móvil del titular de la cuenta. Así es como lo hace Google:
También debe habilitar la verificación en dos pasos , pero esto significa que la próxima vez que restablezca su contraseña, su teléfono móvil puede convertirse en el segundo factor de autenticación. Déjame demostrarte esto con mi iPhone por razones que pronto quedarán claras:
Después de identificar la dirección de correo electrónico de la cuenta, Google determina que se ha habilitado 2FA y podemos restablecer la cuenta mediante la verificación, que se envía por SMS al teléfono móvil del titular de la cuenta:
Ahora debemos seleccionar el inicio del proceso de reinicio:
Esta acción da como resultado que se envíe un correo electrónico a la dirección registrada:
Este correo electrónico contiene la URL de restablecimiento:
Al acceder a la URL de restablecimiento, se envía un SMS y el sitio web le solicita ingresar:
Este es el SMS:
Después de ingresarlo en el navegador, regresamos al territorio del clásico restablecimiento de contraseña:
Probablemente suene un poco detallado, y lo es, pero el formulario confirma que la persona que realiza el reinicio tiene acceso a la dirección de correo electrónico y al teléfono móvil del titular de la cuenta. Pero puede ser nueve veces más seguro que restablecer su contraseña solo por correo electrónico. Sin embargo, hay problemas ...
El problema está en los teléfonos inteligentes. El dispositivo que se muestra a continuación solo puede autenticar un factor de autenticación: puede recibir SMS pero no correo electrónico:
Sin embargo, este dispositivo puede recibir SMS y recibir correos electrónicos de restablecimiento de contraseña:
El problema es que consideramos el correo electrónico como el primer factor de autenticación y los SMS (o incluso una aplicación generadora de tokens) como el segundo, pero hoy en día se combinan en un solo dispositivo. Por supuesto, esto significa que si alguien accede a su teléfono inteligente, toda esta conveniencia se reduce al hecho de que volvemos al mismo canal; este segundo factor, "lo que tienes" significa que también tienes el primer factor. Y todo esto está protegido por un PIN de cuatro dígitos ... si el teléfono tiene un PIN y está bloqueado.
Sí, la función 2FA de Google ciertamente brinda protección adicional, pero no es infalible y ciertamente no depende de dos canales completamente autónomos.
Restablecer por nombre de usuario vs restablecer por correo electrónico
¿Debo permitir solo el restablecimiento de la dirección de correo electrónico? ¿O el usuario también debería poder restablecer por nombre? El problema con el restablecimiento por nombre de usuario es que no hay forma de notificar al usuario de un nombre de usuario incorrecto sin revelar que alguien más podría tener una cuenta con ese nombre de usuario. En la sección anterior, el restablecimiento por correo electrónico garantizaba que el propietario legítimo de ese correo electrónico siempre recibiría comentarios sin revelar públicamente su existencia en el sistema. Esto no se puede hacer usando solo el nombre de usuario.
Entonces la respuesta es breve: solo correo electrónico. Si intenta restablecer solo con el nombre de usuario, habrá ocasiones en las que el usuario se preguntará qué sucedió.o revelará la existencia de cuentas. Sí, esto 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 existe una alta probabilidad de que revele indirectamente a los propietarios de las cuentas debido a la tendencia de los usuarios a reutilizar. nombre.
Entonces, ¿qué sucede cuando alguien olvida su nombre de usuario? Si aceptamos que el nombre de usuario no es inmediatamente una dirección de correo electrónico (y esto sucede a menudo), entonces el proceso es similar a cómo comienza un restablecimiento de contraseña: ingresamos una dirección de correo electrónico y luego enviamos un mensaje a esta dirección sin revelar su existencia. La única diferencia es que esta vez, el mensaje solo contiene el nombre de usuario y no la URL de restablecimiento de contraseña. O eso, o el correo electrónico dirá que no hay una cuenta para esta dirección.
Verificación de identidad y exactitud de direcciones de correo electrónico
Un aspecto clave del restablecimiento de contraseña, y quizás incluso el aspecto más clave, es verificar la identidad de la persona que intenta realizar el restablecimiento. ¿Es este el propietario legítimo de la cuenta o alguien está intentando piratearla o incomodar al propietario?
Obviamente, el correo electrónico es la forma más conveniente y común de verificar su identidad. No está protegido contra el mal manejo ("del tonto"), y hay muchos casos en los que la simple capacidad de recibir cartas a la dirección del propietario de la cuenta no es suficiente si se requiere un alto grado de confianza en la identificación (razón por la cual se usa 2FA), pero casi siempre es el punto de partida proceso de reinicio.
Si el correo electrónico va a desempeñar un papel en la generación de confianza, el primer paso es asegurarse de que la dirección de correo electrónico sea correcta. Si alguien se confunde con un símbolo, obviamente no se iniciará el reinicio. El proceso de verificación de correo electrónico en el momento del registro es una forma confiable de verificar la exactitud de la dirección. Todos hemos visto esto en la práctica: te registras, te envían un correo electrónico con una URL única para hacer clic, lo que confirma que realmente eres el propietario de esa cuenta de correo electrónico. No iniciar sesión antes de completar este proceso asegura que hay motivación para verificar la dirección.
Como ocurre con muchos otros aspectos de la seguridad, dicho modelo reduce la usabilidad a cambio de proporcionar un mayor grado de seguridad en relación con la identidad del usuario. Esto puede ser aceptable para un sitio, registro en el que el usuario valora mucho y con gusto agregará otra etapa del proceso (servicios pagos, banca, etc.), pero tales cosas pueden alienar al usuario si percibe la cuenta como "desechable" y utiliza , por ejemplo, simplemente como un medio para comentar una publicación.
Identificar quién inició el proceso de reinicio
Obviamente, existen razones para el uso malintencionado de la función de reinicio, y los atacantes pueden usarla de muchas formas diferentes. Un truco simple que podemos usar para ayudar a verificar el origen de la solicitud (este truco generalmente funciona) es agregar el restablecimiento de la dirección IP del solicitante al correo electrónico. Esto le proporciona al destinatario cierta información para identificar el origen de la solicitud.
Aquí hay un ejemplo de la función de reinicio que estoy incrustando actualmente en ASafaWeb:
El enlace "obtener más información" lleva al usuario a ip-adress.com , proporcionando información como la ubicación y la organización de la persona que solicita el restablecimiento:
Por supuesto, cualquier persona que quiera ocultar su identidad tiene muchas formas de ocultar su dirección IP real, sin embargo, esta es una forma conveniente de agregar la identidad parcial del solicitante y, en la mayoría de los casos, le dará una buena idea de quién realizará una solicitud de restablecimiento de contraseña.
Cambiar notificación por correo electrónico
Esta publicación está imbuida de un tema: comunicación; comunicar lo más posible al titular de la cuenta sobre lo que está sucediendo en cada etapa del proceso, sin revelar nada que pueda usarse con intenciones maliciosas. Lo mismo se aplica cuando la contraseña realmente ha cambiado: ¡ notifique al propietario de esto!
Hay dos fuentes de motivos para cambiar una contraseña:
- Cambiar la contraseña después de iniciar sesión porque el usuario quiere una nueva contraseña
- Restablecer una contraseña sin iniciar sesión porque el usuario la ha olvidado
Aunque esta publicación trata principalmente sobre restablecimiento, la notificación en primera instancia reduce el riesgo de que alguien cambie la contraseña sin el conocimiento del propietario legítimo. ¿Cómo puede pasar esto? Un escenario muy común es obtener la contraseña del propietario legítimo (una contraseña reutilizada filtrada de otra fuente; una contraseña obtenida por registro de teclas; una contraseña fácil de adivinar, etc.), después de lo cual un atacante decide cambiarla, bloqueando así al propietario. Sin notificación por correo electrónico, el propietario actual no se dará cuenta del cambio de contraseña.
Por supuesto, en el caso de un restablecimiento de contraseña, el propietario ya tenía que iniciar el proceso (u omitir las herramientas de verificación de identificación descritas anteriormente), por lo que el cambio no deberíale sorprenderá, sin embargo, un correo electrónico de confirmación será un comentario positivo y una verificación adicional. Además, proporciona coherencia con el escenario anterior.
Ah, y en caso de que aún no sea obvio, ¡no envíe la nueva contraseña por correo electrónico! Esto puede hacer reír a algunos, pero esto sucede :
Registros, registros, registros y algunos registros más
La función de restablecimiento de contraseña es atractiva para los atacantes: un atacante desea obtener acceso a la cuenta de otra persona o simplemente incomodar al propietario de la cuenta / sistema. Muchas de las prácticas descritas anteriormente pueden reducir la probabilidad de abuso, pero no lo previenen, y ciertamente no evitarán que las personas intenten utilizar la función de formas no deseadas.
El registro es una práctica absolutamente invaluable para reconocer el comportamiento malicioso, y me refiero a un registro muy detallado . Registre los intentos fallidos de iniciar sesión, restablecer las contraseñas, cambiar las contraseñas (es decir, cuando el usuario ya inició sesión) y casi cualquier cosa que pueda ayudarlo a comprender lo que está sucediendo; será muy útil en el futuro. Grabe incluso partes separadas en los registrosproceso, por ejemplo, una buena función de restablecimiento debe incluir iniciar un restablecimiento a través del sitio web (capturar la solicitud y los intentos de inicio de sesión para restablecer con un nombre de usuario o correo electrónico incorrecto), registrar la visita al sitio web mediante la URL de restablecimiento (incluidos los intentos de usar el token) y luego registre el éxito o el fracaso de la respuesta a la pregunta de seguridad.
Cuando hablo de registro, me refiero no solo a registrar el hecho de cargar una página, sino también a recopilar la mayor cantidad de información posible si no es confidencial . ¡Chicos, no registren contraseñas! En los registros, debe registrar la identidad del usuario autorizado (estará autorizado si cambiacontraseña existente, o intentar restablecer la contraseña de otra persona después de iniciar sesión), cualquier nombre de usuario o dirección de correo electrónico que haya probado, además de cualquier token de restablecimiento que intente usar. Pero también vale la pena registrar aspectos como direcciones IP y, si es posible, incluso solicitar encabezados. Esto le permite recrear no solo lo que el usuario (o atacante) está tratando de hacer, sino también quiénes son.
Delegación de responsabilidad a otros artistas intérpretes o ejecutantes
Si cree que esto es una gran cantidad de trabajo, entonces no está solo. De hecho, construir un sistema de administración de cuentas sólido no es una tarea fácil. No es que sea técnicamente pesado, es solo que tiene muchas características. No se trata solo de restablecer, hay un proceso completo de registro, almacenamiento seguro de contraseñas, manejo de múltiples intentos de inicio de sesión no válidos, etc., etc. Si bien estoy promoviendo la idea de utilizar una funcionalidad lista para usar como el proveedor de membresía ASP.NET , todavía hay mucho por hacer más allá.
En la actualidad, existen muchos proveedores externos que felizmente eliminan el dolor y lo resumen todo en un solo servicio administrado. Estos servicios incluyen OpenID, OAuth e incluso Facebook. Algunas personasNo hay límite para creer en este modelo (OpenID ha tenido mucho éxito en Stack Overflow), pero otros lo ven literalmente como una pesadilla .
Sin duda, un servicio como OpenID resuelve muchos problemas de los desarrolladores, pero también indudablemente agrega otros nuevos. ¿Tienen algún papel que desempeñar? Sí, pero obviamente no estamos viendo un uso masivo de proveedores de servicios de autenticación. Los bancos, las aerolíneas e incluso las tiendas implementan su propio mecanismo de autenticación, y obviamente hay muy buenas razones para ello.
Descarga maliciosa
Un aspecto importante de cada uno de los ejemplos anteriores es que la contraseña anterior se considera inútil solo después de que se haya verificado la identidad del propietario de la cuenta . Esto es importante porque si la cuenta pudiera restablecerse antes de la verificación de identidad, abriría todo tipo de actividad maliciosa.
Aquí hay un ejemplo: alguien está pujando en un sitio de subastas, y hacia el final del proceso de puja, bloquea a los competidores iniciando un proceso de reinicio, eliminándolos así de la puja. Obviamente, si se puede hacer un mal uso de una función de reinicio mal diseñada, se pueden producir graves resultados negativos. Vale la pena señalar que bloquear cuentas a través de intentos de inicio de sesión incorrectos es una situación similar, pero este es un tema para otra publicación.
Como dije anteriormente, brindar a los usuarios anónimos la capacidad de restablecer la contraseña de cualquier cuenta simplemente conociendo su dirección de correo electrónico es una situación preparada para un ataque de denegación de servicio. Puede que no sea el mismo DoS, de la que estamos acostumbrados a hablar, pero no hay forma más rápida de bloquear el acceso a su cuenta que con una función de restablecimiento de contraseña mal pensada.
Eslabón más débil
Desde el punto de vista de la protección de una cuenta, todo lo escrito anteriormente es excelente, sin embargo, siempre debe recordar el ecosistema que rodea a la cuenta que está protegiendo. Permítanme darles un ejemplo:
ASafaWeb está alojado por un servicio increíble proporcionado por AppHarbor. El proceso de restablecimiento de una cuenta de alojamiento es el siguiente:
Etapa 1:
Etapa 2:
Etapa 3:
Etapa 4:
Después de leer toda la información anterior, ya es fácil entender qué aspectos en un mundo ideal implementaríamos de manera un poco diferente. Lo que quiero decir aquí, sin embargo, es que si publico un sitio como ASafaWeb en AppHarbor, y luego se me ocurren algunas preguntas y respuestas de seguridad excelentes, agrego un segundo factor de autenticación y hago el resto de acuerdo con las reglas, entonces esto no niega el hecho de que el enlace más débil en todo el proceso será capaz de romperlo todo. Si alguien se autentica con éxito en AppHarbor usando mi información, ¡entonces puede reemplazar la contraseña de cualquier cuenta de ASafaWeb con la que necesita!
El punto es que la robustez de la implementación de la protección debe considerarse de manera integral: es necesario simular amenazas a cada punto de entrada del sistema, incluso si es un proceso superficial, por ejemplo, ingresar al sistema AppHarbor. Esto debería darme una buena idea de cuánto esfuerzo debo poner en el proceso de restablecimiento de contraseña de ASafaWeb.
Poniendolo todo junto
Esta publicación contiene mucha información, por lo que quiero concentrarla en un esquema visual simple:
Recuerde registrar lo más detallado posible para cada uno de estos elementos. ¡Eso es, es simple!
Salir
Mi publicación parece ser completa, pero hay una gran cantidad de material adicional que podría incluir en ella, pero decidí dejarla fuera en aras de la brevedad: el papel de la dirección de correo electrónico de rescate, la situación en la que se pierde el acceso al correo electrónico asociado con la cuenta (por ejemplo, renunció a su trabajo) y así sucesivamente. Como dije anteriormente, la función de reinicio no es tan difícil, solo que hay muchos puntos de vista al respecto.
Aunque el restablecimiento no es tan difícil, a menudo se aplica incorrectamente. Hemos visto un par de ejemplos anteriores en los que la implementación puede generar problemas, y hay muchos más casos de uso en los que el restablecimiento incorrecto en realidad causó problemas. Recientemente se reveló queEl restablecimiento de contraseña se utilizó para robar $ 87,000 en bitcoins . ¡Este es un resultado negativo grave!
Por lo tanto, tenga cuidado con sus funciones de reinicio, simule amenazas en diferentes puntos, y al diseñar una función, no se quite el sombrero negro, ¡porque hay una alta probabilidad de que alguien más lo use!
Publicidad
VDSina ofrece servidores económicos en alquiler con pago diario, cada servidor está conectado a un canal de Internet de 500 Megabits y está protegido de ataques DDoS de forma gratuita.
