El siguiente texto busca dar a conocer las pautas necesarias o los procesos a seguir cuando se realiza pruebas a una pagina de autenticación(logín)
ID de usuario
Asegúrese de que los nombres de usuario / ID de usuario distinguen entre mayúsculas y minúsculas. Muchos sitios utilizan direcciones de correo electrónico de nombres de usuario y direcciones de correo electrónico son ya sensibles a mayúsculas. De todos modos, sería muy extraño para 'smith' usuario y el usuario 'Smith' ser diferentes usuarios. Podría resultar en una grave confusión.
Implementar controles adecuados de seguridad de la contraseña
Una de las principales preocupaciones cuando se utilizan contraseñas para la autenticación de la contraseña es. Una "fuerte" política de contraseñas hace que sea difícil o improbable, incluso para una de adivinar la contraseña a través de medios manuales o automatizados. Las siguientes características definen una contraseña segura:
Longitud de la contraseña
Las contraseñas más largas proporcionan una mayor combinación de caracteres y por lo tanto hacer que sea más difícil para un atacante adivinar.
- La longitud mínima de las contraseñas deben ser aplicadas por la aplicación.
- Contraseñas de menos de 10 caracteres se consideran débiles ( [1] ).
Mientras que la aplicación longitud mínima puede causar problemas con la memorización de contraseñas entre algunos usuarios, las aplicaciones deben alentarlos a establecer contraseñas (frases o combinaciones de palabras) que pueden ser mucho más largas que las contraseñas típicas y sin embargo, mucho más fácil de recordar.
- Longitud máxima de la contraseña no debe ser demasiado baja, ya que evitará que los usuarios creen contraseñas. Longitud máxima típica es de 128 caracteres.
- Las palabras de paso de menos de 20 caracteres se consideran generalmente débil si sólo se componen de caracteres en minúsculas latinas.
- Cada carácter cuenta!
- Asegúrese de que todos los caracteres que el usuario escribe en realidad está incluido en la contraseña. Hemos visto que los sistemas de truncar la contraseña a una longitud más corta que lo que el usuario siempre (por ejemplo, truncado en 15 caracteres cuando entraron 20).
- Esto generalmente se maneja mediante el establecimiento de la longitud de todos los campos de contraseña de entrada a ser exactamente la misma longitud que la contraseña de longitud máxima.Esto es particularmente importante si la longitud de la contraseña max es corta, como 20-30 caracteres.
Contraseña Complejidad
Las aplicaciones deben cumplir las reglas de complejidad de contraseñas para impedir contraseñas fáciles de adivinar. Contraseña mecanismos deben permitir prácticamente cualquier carácter que el usuario puede escribir a formar parte de su contraseña, incluido el carácter de espacio. Las contraseñas deben, obviamente, ser sensible a mayúsculas el fin de aumentar su complejidad. De vez en cuando, nos encontramos con sistemas en los que las contraseñas no son sensibles a mayúsculas, a menudo debido a problemas legados del sistema, como los mainframes antiguos que no tienen contraseñas mayúsculas y minúsculas.
El mecanismo de cambio de contraseña deben exigir un nivel mínimo de complejidad que tenga sentido para la aplicación y su población de usuarios. Por ejemplo:
- Las contraseñas deben cumplir al menos 3 de los siguientes 4 reglas de complejidad
- por lo menos un carácter en mayúsculas (AZ)
- por lo menos un carácter en minúscula (az)
- al menos 1 dígito (0-9)
- por lo menos un carácter especial ("£ $% &! ...) - no se olvide de tratar el espacio como caracteres especiales (común en frases de paso)
- al menos 10 caracteres
- más a 128 caracteres
- no más de 2 caracteres idénticos consecutivos (por ejemplo, 111 no permitido)
Como aplicación requieren políticas de contraseñas más complejas, tienen que ser muy claros acerca de lo que estas políticas.
- La política requiere debe mencionarse explícitamente en la página de cambio de contraseña
- asegúrese de incluir todos los caracteres especiales que permiten, por lo que es evidente para el usuario
Recomendación:
- Idealmente, la aplicación podría indicar al usuario que escriba como su nueva contraseña en qué parte de la directiva de complejidad de su nueva contraseña cumple
- De hecho, el botón de envío debe estar sombreados hasta que la nueva contraseña cumple la directiva de complejidad y la segunda copia de la nueva contraseña coincide con la primera. Esto hará que sea mucho más fácil para el usuario a entender y cumplir con la política de la complejidad.
Independientemente de cómo se comporta la interfaz de usuario, cuando un usuario envía su solicitud de cambio de contraseña:
- Si la nueva contraseña no cumple con la directiva de complejidad, el mensaje de error debe describir todas las reglas de complejidad que la nueva contraseña no cumple, no sólo la primera regla que no cumple con
Cambio de contraseñas debe ser fácil, no una caza en la oscuridad.
Implementar Mecanismo Secure Password Recovery
Es común para una aplicación para tener un mecanismo que proporciona un medio para que un usuario para obtener acceso a su cuenta en el caso de que se olvide su contraseña. Por favor, consulte Forgot_Password_Cheat_Sheet para más detalles sobre esta función.
Requerir Re-autenticación para las características sensibles
Con el fin de mitigar CSRF y secuestro de sesión, es importante exigir las credenciales actuales para una cuenta antes de la actualización de la información de cuenta confidencial, como la contraseña del usuario, el correo electrónico del usuario, o antes de las transacciones sensibles, como el envío de una compra a una nueva dirección. Sin esta contramedida, un atacante puede ser capaz de ejecutar transacciones confidenciales a través de un ataque CSRF o XSS sin necesidad de conocer las credenciales actuales del usuario. Además, un atacante puede obtener acceso físico temporal en el navegador del usuario o robar su ID de sesión para hacerse cargo de la sesión del usuario.
Utilizar la autenticación de factores múltiples
Múltiples factores de autenticación (AMF) está utilizando más de un factor de autenticación para iniciar sesión o procesar una transacción:
- Algo que saber (datos de la cuenta o contraseñas)
- Algo que tiene (teléfonos fichas o móvil)
- Algo que está (biometría)
Esquemas de autenticación como contraseñas de un solo uso (OTP) implementados utilizando un token de hardware también puede ser clave en la lucha contra los ataques como CSRF y malware de cliente. Un número de tokens de hardware adecuados para MFA están disponibles en el mercado que permiten una buena integración con aplicaciones web. Véase: [2] .
Autenticación de cliente SSL
Autenticación del cliente SSL, también conocida como la autenticación de doble vía SSL, consta tanto, el navegador y el servidor, enviando a sus respectivos certificados SSL durante el proceso de negociación TLS. Así como usted puede validar la autenticidad de un servidor mediante el certificado y pedir una autoridad de certificación bien conocida (CA) si el certificado es válido, el servidor puede autenticar al usuario mediante la recepción de un certificado del cliente y validar contra un tercer partido CA o su propia CA. Para ello, el servidor más proporcionar al usuario con un certificado generado específicamente para él, asignando valores a los sujetos para que éstos se pueden utilizar para determinar el usuario debe validar el certificado. El usuario instala el certificado en el navegador y ahora lo utiliza para el sitio Web.
Es una buena idea hacer esto cuando:
- Es aceptable (o incluso preferido) que el usuario sólo tiene acceso al sitio web de un solo ordenador / navegador.
- El usuario no se asusta fácilmente por el proceso de instalación de certificados SSL en su navegador o habrá alguien, probablemente de soporte de TI, que lo hará por el usuario.
- El sitio web requiere un paso adicional de seguridad.
- También es una buena idea usar si el sitio web es para una intranet de una empresa u organización.
Generalmente no es una buena idea utilizar este método para la amplia y públicamente sitios web disponibles que tendrán un usuario medio. Por ejemplo, no sería una buena idea para implementar esto para un sitio web como Facebook. Si bien esta técnica puede evitar que el usuario tenga que escribir una contraseña (lo que protege contra un keylogger promedio de robar), todavía se considera una buena idea considerar el uso de una contraseña y la autenticación de cliente SSL combinados.
Autenticación y mensajes de error
Aplicado correctamente mensajes de error en el caso de la funcionalidad de autenticación se puede utilizar para los fines de identificación de usuario y contraseña enumeración. Una aplicación debe responder (HTTP y HTML) de una manera genérica.
Las respuestas de autenticación
Una aplicación debe responder con un mensaje de error genérico, independientemente de si el ID de usuario o la contraseña es incorrecta. También debe dar ninguna indicación a la condición de una cuenta existente.
Ejemplos incorrectos de respuesta
- "Inicio de sesión de usuario foo: Contraseña no válida"
- "Error de acceso, ID de usuario no válido"
- "Error de acceso, cuenta deshabilitada"
- "Error de acceso, este usuario no está activa"
Ejemplo de respuesta correcta
- "Error de acceso, ID de usuario o contraseña no válidos"
La respuesta correcta no indica si el ID de usuario o la contraseña es incorrecta el parámetro y, por tanto inferir un ID de usuario válido.
Códigos de error y de URL
La aplicación puede devolver un código de error HTTP diferente dependiendo de la respuesta de intento de autenticación. Se puede responder con un 200 para un resultado positivo y un 403 para un resultado negativo. A pesar de que una página genérica de error se muestra a un usuario, el código de respuesta HTTP pueden diferir que puede filtrar información acerca de si la cuenta es válida o no.
Transmitir contraseñas sólo sobre TLS
La página de inicio de sesión y todas las páginas siguientes deben ser autenticados exclusivamente accede a través de TLS. La página de inicio de sesión inicial, conocida como la "página de inicio de sesión de aterrizaje", debe ser servido a más de TLS. Si no se utiliza TLS para la página de destino de inicio de sesión permite a un atacante modificar la acción del formulario de inicio de sesión, lo que las credenciales del usuario se registre en una ubicación arbitraria. Si no se utiliza TLS para las páginas de inicio de sesión autenticado después de que el permite a un atacante ver el identificador de sesión sin cifrar y comprometer sesión autenticada del usuario.
Implementar bloqueo de cuentas
Si un atacante es capaz de adivinar las contraseñas de la cuenta sin quedar incapacitado debido a los intentos de autenticación fallidos, el atacante tiene la oportunidad de continuar con un ataque de fuerza bruta hasta que la cuenta se ve comprometida.
Automatizar brute-force/password adivinar los ataques a aplicaciones web es un desafío trivial. Contraseña mecanismos de bloqueo debe ser empleado que bloquear una cuenta si hay más de un número predeterminado de intentos de conexión fallidos se hacen.
Contraseña mecanismos de bloqueo tiene una debilidad lógica. Un atacante que lleva a cabo un gran número de intentos de autenticación en los nombres de cuentas conocidas pueden producir un resultado que bloquea bloques enteros de cuentas de usuario.
Dado que el propósito de un sistema de bloqueo de contraseña sea la protección contra los ataques de fuerza bruta, una estrategia sensata es de bloqueo de cuentas por un período de tiempo (por ejemplo, 20 minutos). Esto reduce de forma considerable los atacantes, al tiempo que permite la reapertura de las cuentas automáticamente para los usuarios legítimos.
El uso de protocolos de autenticación que no requieran contraseña
Mientras que la autenticación a través de una combinación de usuario / contraseña y el uso de autenticación de múltiples factores se considera generalmente seguro, hay casos de uso en los que no se considera la mejor opción o incluso seguro. Un ejemplo de esto son las aplicaciones de terceros que deseen conectarse a la aplicación web, ya sea desde un dispositivo móvil, otra situaciones sitio web, de escritorio o de otro tipo. Cuando esto sucede, no se considera seguro para permitir la aplicación de terceros para almacenar la combinación de usuario / contraseña, ya continuación se extiende la superficie de ataque en sus manos, en las que no está bajo su control. Por esto y otros casos de uso, existen varios protocolos de autenticación que pueden protegerlo de la exposición de los datos de los usuarios a los atacantes.
OAuth
Autorización Open (OAuth) es un protocolo que permite que una aplicación para la autenticación en el servidor como usuario, sin necesidad de contraseñas o cualquier servidor de un tercero que actúa como proveedor de identidad. Se utiliza una señal generada por el servidor, y proporciona la autorización cómo fluye la mayoría se producen, de modo que un cliente, tal como una aplicación móvil, puede indicar al servidor qué usuario está usando el servicio.
La recomendación es usar y aplicar OAuth 2,0, desde la primera versión se ha encontrado para ser vulnerables a la fijación de sesión.
OAuth 2.0 es actualmente utilizado y aplicado por la API de empresas como Facebook, Google, Twitter y Microsoft.
OpenId
OpenID es un protocolo basado en HTTP que utiliza proveedores de identidad para validar que un usuario es quien dice ser. Es un protocolo muy sencillo que permite a un proveedor de servicio inicia camino para el inicio de sesión único (SSO). Esto permite que el usuario vuelva a utilizar una identidad única administrada a un proveedor de identidad OpenID confianza y ser el mismo usuario en varios sitios web, sin la necesidad de proporcionar cualquier página web de la contraseña, excepto por el proveedor de identidad OpenID.
Debido a su simplicidad y que proporciona una protección de contraseñas, OpenId ha sido bien adoptada. Algunos de los proveedores de identidad bien conocidos para OpenId son Stack Exchange, Google, Facebook y Yahoo!
Para no empresarial ambiente, OpenId se considera una opción segura y mejor frecuencia, siempre que el proveedor de identidad es de confianza.
SAML
Aserción de seguridad Markup Language (SAML) es considerado a menudo compiten con OpenID. La versión más recomendada es de 2,0, ya que es muy característica completa y proporciona una gran seguridad. Al igual que con OpenID, SAML utiliza proveedores de identidad, pero a diferencia de ella, está basado en XML y proporciona una mayor flexibilidad. SAML se basa en redirige el navegador que envían datos XML. A diferencia de SAML, no sólo se inicia por un proveedor de servicios, pero también puede ser iniciada desde el proveedor de identidad. Esto permite al usuario navegar a través de diferentes portales sin dejar de ser autenticados sin tener que hacer nada, por lo que el proceso sea transparente.
Mientras OpenId ha tomado la mayor parte del mercado de consumo, SAML es a menudo la mejor opción para las aplicaciones empresariales. La razón de esto es que a menudo hay pocos proveedores de identidad OpenID que se consideran de clase de la empresa (lo que significa que la forma en que validar la identidad del usuario no tiene altos niveles requeridos por la identidad de la empresa). Es más común ver SAML se usa dentro de los sitios web de intranet, a veces incluso utilizando un servidor de la intranet como el proveedor de identidades.
En los últimos años, las aplicaciones como SAP ERP y SharePoint (SharePoint mediante Active Directory Federation Services 2.0) han decidido utilizar la autenticación SAML 2.0 como un método a menudo preferido para inicio de sesión único empresarial federación implementaciones cuando se requiere para los servicios web y la web aplicaciones.
Gestión de Sesiones de Directrices Generales
La administración de sesiones está directamente relacionada con la autenticación.Las directrices generales de gestión de sesión disponibles anteriormente en esta Hoja de trucos de autenticación de OWASP se han integrado en la nueva hoja de OWASP Sesión Cheat Gestión .
Administradores de Contraseñas
Encargados de la contraseña son programas, plugins del navegador o servicios web que automatizan la gestión de un gran número de credenciales diferentes, incluyendo la memorización y colmatación, lo que genera contraseñas al azar en sitios diferentes, etc La aplicación web puede ayudar a los administradores de contraseñas por:
- utilizando formularios HTML estándar para la entrada de nombre de usuario y contraseña,
- no usar en varias fases esquemas de acceso (nombre de usuario en la pantalla, luego la contraseña),
- no usar muy scripted (JavaScript) de autenticación Schem
No hay comentarios:
Publicar un comentario