securing security http authentication language-agnostic article

security - securing - La guía definitiva para la autenticación de sitios web basada en formularios



microservices jwt (12)

Artículo definitivo

Enviando credenciales

La única forma práctica de enviar credenciales de forma 100% segura es mediante SSL . Usar JavaScript para hash la contraseña no es seguro. Trampas comunes para el hashing de contraseñas del lado del cliente:

  • Si la conexión entre el cliente y el servidor no está encriptada, todo lo que haga será vulnerable a los ataques de intermediarios . Un atacante podría reemplazar el javascript entrante para romper el hash o enviar todas las credenciales a su servidor, podría escuchar las respuestas de los clientes y suplantar a los usuarios a la perfección, etc. El SSL con Autoridades de Certificación confiables está diseñado para prevenir ataques MitM.
  • La contraseña con hash recibida por el servidor es menos segura si no realiza un trabajo adicional y redundante en el servidor.

Existe otro método seguro llamado SRP , pero está patentado (aunque tiene licencia libre ) y hay pocas implementaciones buenas disponibles.

Almacenar contraseñas

Nunca almacene contraseñas como texto simple en la base de datos. Ni siquiera si no te importa la seguridad de tu propio sitio. Suponga que algunos de sus usuarios reutilizarán la contraseña de su cuenta bancaria en línea. Por lo tanto, almacene la contraseña con hash y deseche la original. Y asegúrese de que la contraseña no aparezca en los registros de acceso o en los registros de aplicaciones. OWASP recomienda el uso de Argon2 como su primera opción para nuevas aplicaciones. Si esto no está disponible, se debe usar PBKDF2 o scrypt en su lugar. Y, finalmente, si ninguno de los anteriores está disponible, use bcrypt.

Los hash por sí mismos también son inseguros. Por ejemplo, contraseñas idénticas significa hash idénticos, lo que hace que las tablas de búsqueda de hash sean una forma efectiva de descifrar muchas contraseñas a la vez. En su lugar, almacenar el hachís salado . Una sal es una cadena anexada a la contraseña antes del hashing: use una sal diferente (aleatoria) por usuario. La sal es un valor público, por lo que puede almacenarlos con el hash en la base de datos. Vea here para más sobre esto.

Esto significa que no puede enviar al usuario sus contraseñas olvidadas (porque solo tiene el hash). No restablezca la contraseña del usuario a menos que haya autenticado al usuario (los usuarios deben probar que pueden leer los correos electrónicos enviados a la dirección de correo electrónico almacenada (y validada)).

Preguntas de seguridad

Las preguntas de seguridad son inseguras, evite usarlas. ¿Por qué? Cualquier cosa que haga una pregunta de seguridad, una contraseña funciona mejor. Lea la PARTE III: Uso de preguntas secretas en @Jens Roland responda aquí en este wiki.

Galletas de sesión

Una vez que el usuario inicia sesión, el servidor envía una cookie de sesión al usuario. El servidor puede recuperar el nombre de usuario o la identificación de la cookie, pero nadie más puede generar dicha cookie (TODO explica los mecanismos).

Las cookies pueden ser secuestradas : son tan seguras como el resto de la máquina del cliente y otras comunicaciones. Se pueden leer desde el disco, rastrear el tráfico de la red, levantarse mediante un ataque de secuencias de comandos entre sitios, hacer phishing desde un DNS envenenado para que el cliente envíe sus cookies a los servidores incorrectos. No envíe cookies persistentes. Las cookies deben caducar al final de la sesión del cliente (el navegador cierra o abandona su dominio).

Si desea iniciar sesión automáticamente en sus usuarios, puede configurar una cookie persistente, pero debe ser distinta de una cookie de sesión completa. Puede establecer una marca adicional en la que el usuario haya iniciado sesión automáticamente y deba iniciar sesión en operaciones reales para operaciones confidenciales. Esto es popular entre los sitios de compras que desean brindarle una experiencia de compra perfecta y personalizada, pero que a la vez proteja sus detalles financieros. Por ejemplo, cuando vuelves a visitar Amazon, te muestran una página que parece que has iniciado sesión, pero cuando haces un pedido (o cambias tu dirección de envío, tarjeta de crédito, etc.), te piden que confirmes tu contraseña.

Los sitios web financieros, como bancos y tarjetas de crédito, por otro lado, solo tienen datos confidenciales y no deben permitir el inicio de sesión automático o un modo de baja seguridad.

Lista de recursos externos

Autenticación basada en formularios para sitios web

Creemos que el desbordamiento de pila no debe ser solo un recurso para preguntas técnicas muy específicas, sino también para pautas generales sobre cómo resolver variaciones en problemas comunes. La "autenticación basada en formularios para sitios web" debería ser un buen tema para tal experimento.

Debe incluir temas como:

  • Cómo iniciar sesión
  • Cómo cerrar sesión
  • Cómo permanecer conectado
  • Gestión de cookies (incluyendo la configuración recomendada)
  • Cifrado SSL / HTTPS
  • Cómo almacenar contraseñas
  • Usando preguntas secretas
  • Se olvidó la funcionalidad de nombre de usuario / contraseña
  • Uso de nonces para evitar falsificaciones de solicitudes entre sitios (CSRF)
  • OpenID
  • Casilla de verificación "Recuérdame"
  • Autocompletar navegador de nombres de usuario y contraseñas.
  • URLs secretas ( URL públicas protegidas por compendio)
  • Comprobando la fuerza de la contraseña
  • Validación de correo electrónico
  • y mucho más sobre la autenticación basada en formularios ...

No debe incluir cosas como:

  • Roles y autorización
  • Autenticación básica HTTP

Por favor ayúdenos por:

  1. Sugiriendo subtemas
  2. Presentando buenos artículos sobre este tema.
  3. Editando la respuesta oficial.

PARTE I: Cómo iniciar sesión

Asumiremos que ya sabe cómo crear un formulario HTML de inicio de sesión + contraseña que publique los valores en un script en el lado del servidor para la autenticación. Las secciones a continuación tratarán los patrones para la autenticación práctica de sonido y cómo evitar los escollos de seguridad más comunes.

¿A HTTPS o no a HTTPS?

A menos que la conexión ya sea segura (es decir, canalizada a través de HTTPS usando SSL / TLS), los valores de su formulario de inicio de sesión se enviarán en texto sin cifrar, lo que permite que cualquier persona que escuche en la línea entre el navegador y el servidor web pueda leer los inicios de sesión a medida que pasan. mediante. Este tipo de escuchas telefónicas se realiza de forma rutinaria por parte de los gobiernos, pero en general, no abordaremos los cables de "propiedad" más que para decir esto: si está protegiendo algo importante, use HTTPS.

En esencia, la única forma práctica de protegerse contra las escuchas telefónicas y el rastreo de paquetes durante el inicio de sesión es mediante el uso de HTTPS u otro esquema de cifrado basado en certificados (por ejemplo, TLS ) o un esquema de desafío-respuesta probado y probado (por ejemplo, el Diffie-Hellman basado en SRP). Cualquier otro método puede ser fácilmente evitado por un atacante de escuchas ilegales.

Por supuesto, si está dispuesto a ser poco práctico, también podría emplear algún tipo de esquema de autenticación de dos factores (por ejemplo, la aplicación Google Authenticator, un libro de códigos físico de "estilo de guerra fría" o un dongle generador de claves RSA). Si se aplica correctamente, esto podría funcionar incluso con una conexión no segura, pero es difícil imaginar que un desarrollador esté dispuesto a implementar autenticación de dos factores pero no SSL.

(No) Roll-your-own JavaScript cifrado / hashing

Dado el costo distinto de cero y la dificultad técnica percibida de configurar un certificado SSL en su sitio web, algunos desarrolladores están tentados a implementar sus propios esquemas de cifrado o hashing en el navegador para evitar la transferencia de inicios de sesión de texto simple por un cable no seguro.

Si bien este es un pensamiento noble, es esencialmente inútil (y puede ser un defecto de seguridad ) a menos que se combine con uno de los anteriores, es decir, ya sea asegurando la línea con un cifrado sólido o utilizando una respuesta de desafío probada y probada Mecanismo (si no sabe qué es eso, simplemente sepa que es uno de los conceptos más difíciles de probar, más difíciles de diseñar y más difíciles de implementar en seguridad digital).

Si bien es cierto que el hashing de la contraseña puede ser efectivo contra la revelación de la contraseña , es vulnerable a los ataques de repetición, ataques / secuestros Man-In-The-Middle (si un atacante puede inyectar algunos bytes en su página HTML no segura antes de que llegue a su En el navegador, simplemente pueden comentar el hash en el JavaScript), o los ataques de fuerza bruta (ya que le están dando al atacante el nombre de usuario, la sal y la contraseña de hash).

CAPTCHAS CONTRA LA HUMANIDAD.

CAPTCHA objetivo de CAPTCHA es frustrar una categoría específica de ataque: prueba y error automatizados de diccionario / fuerza bruta sin operador humano. No hay duda de que esto es una amenaza real, sin embargo, hay formas de lidiar con él sin problemas que no requieren un CAPTCHA, específicamente diseñados adecuadamente los esquemas de aceleración de inicio de sesión del lado del servidor - los discutiremos más adelante.

Sepa que las implementaciones de CAPTCHA no se crean por igual; a menudo no son solubles por el hombre, la mayoría de ellos son en realidad ineficaces contra los bots, todos ineficaces contra la mano de obra barata del tercer mundo (según OWASP , la tasa actual de talleres es de $ 12 por cada 500 pruebas), y algunas implementaciones pueden ser técnicamente ilegal en algunos países (vea la hoja de referencia de autenticación de OWASP ). Si debe usar un CAPTCHA, use reCAPTCHA de Google, ya que es difícil de definir por OCR (ya que utiliza escaneos de libros ya clasificados por OCR) y trata de ser muy fácil de usar.

Personalmente, tiendo a encontrar que CAPTCHAS es molesto, y los uso solo como último recurso cuando un usuario no ha podido iniciar sesión varias veces y los retrasos de aceleración son máximos. Esto sucederá raramente lo suficiente como para ser aceptable, y fortalece el sistema en su totalidad.

Almacenamiento de contraseñas / verificación de inicios de sesión

Finalmente, esto puede ser de conocimiento general después de todos los hacks altamente publicitados y las filtraciones de datos de usuarios que hemos visto en los últimos años, pero debe decirse: no almacene contraseñas en texto sin cifrar en su base de datos. Las bases de datos de los usuarios se piratean, filtran o se extraen de forma rutinaria a través de la inyección de SQL, y si está almacenando contraseñas en bruto y de texto simple, se trata de un juego instantáneo para su seguridad de inicio de sesión.

Entonces, si no puede almacenar la contraseña, ¿cómo verifica que la combinación de inicio de sesión + contraseña POSTED del formulario de inicio de sesión sea correcta? La respuesta es el hashing usando una función de derivación de claves . Cada vez que se crea un nuevo usuario o se cambia una contraseña, toma la contraseña y la ejecuta a través de un KDF, como Argon2, bcrypt, scrypt o PBKDF2, convirtiendo la contraseña de texto simple ("correcthorsebatterystaple") en una cadena larga y de apariencia aleatoria , que es mucho más seguro para almacenar en su base de datos. Para verificar un inicio de sesión, ejecute la misma función de hash en la contraseña ingresada, esta vez pase el salt y compare la cadena de hash resultante con el valor almacenado en su base de datos. Argon2, bcrypt y scrypt almacenan la sal con el hash ya. Echa un vistazo a este article en sec.stackexchange para obtener información más detallada.

La razón por la que se usa una sal es que el hash en sí mismo no es suficiente: querrá agregar la llamada ''sal'' para proteger el hash contra las tablas del arco iris . Un salt evita efectivamente que dos contraseñas que coincidan exactamente se almacenen como el mismo valor hash, evitando que se analice toda la base de datos en una ejecución si un atacante está ejecutando un ataque de adivinación de contraseña.

No se debe usar un hash criptográfico para el almacenamiento de contraseñas porque las contraseñas seleccionadas por el usuario no son lo suficientemente seguras (es decir, generalmente no contienen suficiente entropía) y un atacante con acceso a las hashes podría completar un ataque de adivinación de contraseñas en un tiempo relativamente corto. Esta es la razón por la que se usan los KDF, que efectivamente "estiran la clave" , lo que significa que cada contraseña que un atacante hace causa repeticiones múltiples del algoritmo hash, por ejemplo, 10.000 veces, lo que hace que el atacante adivine la contraseña 10.000 veces más lento.

Datos de la sesión - "Has iniciado sesión como Spiderman69"

Una vez que el servidor haya verificado el inicio de sesión y la contraseña en su base de datos de usuarios y haya encontrado una coincidencia, el sistema necesita una forma de recordar que el navegador se ha autenticado. Este hecho solo se debe almacenar del lado del servidor en los datos de la sesión.

Si no está familiarizado con los datos de la sesión, así es como funciona: una sola cadena generada de forma aleatoria se almacena en una cookie caducada y se utiliza para hacer referencia a una recopilación de datos (los datos de la sesión) que se almacena en el servidor. Si está utilizando un marco MVC, sin duda esto ya se ha gestionado.

Si es posible, asegúrese de que la cookie de sesión tenga las marcas de seguridad y HTTP Only establecidas cuando se envíen al navegador. La bandera HttpOnly proporciona cierta protección contra la cookie que se lee a través del ataque XSS. El indicador de seguridad garantiza que la cookie solo se envíe de vuelta a través de HTTPS y, por lo tanto, protege contra los ataques de rastreo de la red. El valor de la cookie no debe ser predecible. Cuando se presenta una cookie que hace referencia a una sesión no existente, su valor debe reemplazarse de inmediato para evitar la fijación de la sesión .

PARTE II: Cómo permanecer conectado: la infame casilla de verificación "Recordarme"

Las cookies de inicio de sesión persistentes (funcionalidad "recordarme") son una zona de peligro; por un lado, son tan seguros como los inicios de sesión convencionales cuando los usuarios entienden cómo manejarlos; y, por otro lado, representan un enorme riesgo para la seguridad en manos de usuarios descuidados, quienes pueden usarlos en computadoras públicas y se olvidan de cerrar sesión, y pueden no saber qué son las cookies del navegador o cómo eliminarlas.

Personalmente, me gustan los inicios de sesión persistentes para los sitios web que visito regularmente, pero sé cómo manejarlos de manera segura. Si está seguro de que sus usuarios saben lo mismo, puede usar los inicios de sesión persistentes con una conciencia limpia. Si no es así, bueno, entonces puede suscribirse a la filosofía de que los usuarios que son descuidados con sus credenciales de inicio de sesión se lo impusieron si son pirateados. No es como si vamos a las casas de nuestros usuarios y arrancamos todas esas notas Post-It que inducen facepalm con contraseñas que han alineado en el borde de sus monitores, tampoco.

Por supuesto, algunos sistemas no pueden permitirse tener cuentas hackeadas; para tales sistemas, no hay forma de justificar que haya inicios de sesión persistentes.

Si decide implementar cookies de inicio de sesión persistentes, así es como lo hace:

  1. Primero, tómese un tiempo para leer el artículo de Paragon Initiative sobre el tema. Tendrá que acertar en un montón de elementos, y el artículo explica muy bien cada uno.

  2. Y solo para reiterar uno de los escollos más comunes, NO ALMACENE LA COOKIE PERSONALIZADA DE INICIO DE SESIÓN (TOKEN) EN SU BASE DE DATOS, ¡SÓLO UN GOLPE! El token de inicio de sesión es equivalente a la contraseña, por lo que si un atacante se hiciera con la base de datos, podría usar los tokens para iniciar sesión en cualquier cuenta, como si fueran combinaciones de contraseña de inicio de sesión de texto simple. Por lo tanto, use el hash (según https://security.stackexchange.com/a/63438/5002 un hash débil funcionará bien para este propósito) al almacenar tokens de inicio de sesión persistentes.

PARTE III: Usar preguntas secretas

No implementes ''preguntas secretas'' . La característica ''preguntas secretas'' es un anti-patrón de seguridad. Lea el documento del enlace número 4 de la lista MUST-READ. Puedes preguntarle a Sarah Palin sobre eso, después de su Yahoo! La cuenta de correo electrónico fue pirateada durante una campaña presidencial anterior porque la respuesta a su pregunta de seguridad fue ... "Wasilla High School".

Incluso con preguntas especificadas por el usuario, es muy probable que la mayoría de los usuarios elijan:

  • Una pregunta secreta ''estándar'' como el apellido de soltera de la madre o la mascota favorita

  • Una simple pieza de trivia que cualquiera podría sacar de su blog, perfil de LinkedIn o similar

  • Cualquier pregunta que sea más fácil de contestar que adivinar su contraseña. Que, para cualquier contraseña decente, es cada pregunta que puedas imaginar

En conclusión, las preguntas de seguridad son intrínsecamente inseguras en prácticamente todas sus formas y variaciones, y no deben emplearse en un esquema de autenticación por ningún motivo.

La verdadera razón por la cual las preguntas de seguridad aún existen en la naturaleza es que ahorran convenientemente el costo de algunas llamadas de soporte de los usuarios que no pueden acceder a su correo electrónico para obtener un código de reactivación. Esto a expensas de la seguridad y la reputación de Sarah Palin. ¿Vale la pena? Probablemente no.

PARTE IV: Funcionalidad de contraseña olvidada

Ya mencioné por qué nunca debe usar preguntas de seguridad para manejar contraseñas de usuario olvidadas / perdidas; No hace falta decir que nunca debe enviar por correo electrónico a los usuarios sus contraseñas reales. Hay al menos dos fallas más comunes que se deben evitar en este campo:

  1. No restablezca una contraseña olvidada a una contraseña segura autogenerada, tales contraseñas son muy difíciles de recordar, lo que significa que el usuario debe cambiarla o escribirla, por ejemplo, en un post-it amarillo brillante en el borde de su monitor. En lugar de establecer una nueva contraseña, simplemente deje que los usuarios elijan una nueva de inmediato, que es lo que quieren hacer de todos modos. (Una excepción podría ser si los usuarios utilizan universalmente un administrador de contraseñas para almacenar / administrar contraseñas que normalmente serían imposibles de recordar sin escribirlas).

  2. Siempre hash el código / token de contraseña perdida en la base de datos. OTRA VEZ , este código es otro ejemplo de un equivalente de contraseña, por lo que DEBE estar bloqueado en caso de que un atacante tenga en su base de datos. Cuando se solicite un código de contraseña perdido, envíe el código de texto simple a la dirección de correo electrónico del usuario, luego pídalo, guarde el hash en su base de datos y deseche el original . Al igual que una contraseña o un token de inicio de sesión persistente.

Una nota final: siempre asegúrese de que su interfaz para ingresar el ''código de contraseña perdida'' sea al menos tan segura como su propio formulario de inicio de sesión, o un atacante simplemente usará esto para obtener acceso. Asegurarse de que genere "códigos de contraseña perdida" muy largos (por ejemplo, 16 caracteres alfanuméricos que distinguen entre mayúsculas y minúsculas) es un buen comienzo, pero considere agregar el mismo esquema de limitación que el formulario de inicio de sesión.

PARTE V: Comprobación de la fortaleza de la contraseña

Primero, querrá leer este pequeño artículo para una revisión de la realidad: las 500 contraseñas más comunes

Bueno, tal vez la lista no sea la lista canónica de las contraseñas más comunes en cualquier sistema, pero es una buena indicación de qué tan mal las personas elegirán sus contraseñas cuando no exista una política forzada. Además, la lista se ve terriblemente cerca de casa cuando la comparas con los análisis disponibles públicamente de las contraseñas robadas recientemente.

Entonces: sin requisitos mínimos de seguridad de la contraseña, el 2% de los usuarios usa una de las 20 contraseñas más comunes. Significado: si un atacante obtiene solo 20 intentos, una de cada 50 cuentas en su sitio web será crackable.

Para frustrar esto es necesario calcular la entropía de una contraseña y luego aplicar un umbral. La publicación especial 800-63 del Instituto Nacional de Estándares y Tecnología (NIST) tiene un conjunto de muy buenas sugerencias. Eso, cuando se combina con un análisis de distribución de teclado y diccionario (por ejemplo, ''qwertyuiop'' es una contraseña incorrecta), puede rechazar el 99% de todas las contraseñas mal seleccionadas a un nivel de 18 bits de entropía. Simplemente calcular la seguridad de la contraseña y mostrar un medidor de fuerza visual a un usuario es bueno, pero insuficiente. A menos que se aplique, lo más probable es que muchos usuarios lo ignoren.

Y para una actualización refrescante de la facilidad de uso de las contraseñas de alta entropía, se recomienda la contraseña de Randall Munroe xkcd .

Utilice la API Have I Been Pwned de Troy Hunt para verificar las contraseñas de los usuarios contra contraseñas comprometidas en violaciones de datos públicos.

PARTE VI: Mucho más, o bien: Prevención de intentos de inicio de sesión con fuego rápido

Primero, eche un vistazo a los números: Velocidades de recuperación de contraseñas: cuánto tiempo se mantendrá su contraseña

Si no tiene tiempo para mirar las tablas en ese enlace, aquí está la lista de ellas:

  1. Prácticamente no toma tiempo descifrar una contraseña débil, incluso si la descifra con un ábaco

  2. No lleva prácticamente tiempo descifrar una contraseña alfanumérica de 9 caracteres si no distingue entre mayúsculas y minúsculas

  3. Prácticamente no se necesita tiempo para descifrar una contraseña compleja, con mayúsculas y minúsculas, y una contraseña en mayúsculas y minúsculas si tiene menos de 8 caracteres (una PC de escritorio puede buscar en todo el espacio de teclas hasta 7 caracteres en una materia) de días o incluso horas)

  4. Sin embargo, tomaría una cantidad de tiempo excesiva descifrar incluso una contraseña de 6 caracteres, si estuviera limitado a un intento por segundo.

Entonces, ¿qué podemos aprender de estos números? Bueno, mucho, pero podemos enfocarnos en la parte más importante: el hecho de que evitar grandes cantidades de intentos de inicio de sesión sucesivos de disparo rápido (es decir, el ataque de fuerza bruta ) realmente no es tan difícil. Pero prevenirlo correctamente no es tan fácil como parece.

En términos generales, tiene tres opciones que son todas efectivas contra ataques de fuerza bruta (y ataques de diccionario, pero como ya está empleando una fuerte política de contraseñas, no deberían ser un problema) :

  • Presentar un CAPTCHA después de N intentos fallidos (molestos como el infierno y, a menudo, ineficaces, pero me estoy repitiendo aquí)

  • Bloqueo de cuentas y requerimiento de verificación de correo electrónico después de N intentos fallidos (esto es un ataque DoS espera de que ocurra)

  • Y, por último, la aceleración de inicio de sesión : es decir, establecer un retraso de tiempo entre intentos después de N intentos fallidos (sí, los ataques DoS todavía son posibles, pero al menos son mucho menos propensos y mucho más complicados de lograr).

Mejor práctica n.º 1: un breve retraso que aumenta con el número de intentos fallidos, como:

  • 1 intento fallido = sin demora
  • 2 intentos fallidos = retraso de 2 segundos
  • 3 intentos fallidos = 4 segundos de retraso
  • 4 intentos fallidos = retraso de 8 segundos
  • 5 intentos fallidos = 16 segundos de retraso
  • etc.

DoS atacar este esquema sería muy poco práctico, ya que el tiempo de bloqueo resultante es ligeramente mayor que la suma de los tiempos de bloqueo anteriores.

Para aclarar: el retraso no es un retraso antes de devolver la respuesta al navegador. Es más bien un tiempo de espera o un período refractario durante el cual los intentos de inicio de sesión en una cuenta específica o desde una dirección IP específica no serán aceptados o evaluados en absoluto. Es decir, las credenciales correctas no se devolverán en un inicio de sesión exitoso, y las credenciales incorrectas no generarán un aumento de demora.

Mejor práctica n.º 2: un retardo de tiempo de duración media que entra en vigencia después de N intentos fallidos, como:

  • 1-4 intentos fallidos = sin demora
  • 5 intentos fallidos = 15-30 minutos de retraso

DoS atacar este esquema sería bastante poco práctico, pero ciertamente factible. Además, podría ser relevante tener en cuenta que un retraso tan prolongado puede ser muy molesto para un usuario legítimo. Los usuarios olvidadizos no te gustarán.

Mejor práctica # 3: Combinar los dos enfoques, ya sea un retardo de tiempo corto y fijo que entra en vigencia después de N intentos fallidos, como:

  • 1-4 intentos fallidos = sin demora
  • 5 + intentos fallidos = 20 segundos de retraso

O, un retraso creciente con un límite superior fijo, como:

  • 1 intento fallido = 5 segundos de retraso
  • 2 intentos fallidos = 15 segundos de retraso
  • 3 + intentos fallidos = 45 segundos de retraso

Este esquema final se tomó de las sugerencias de mejores prácticas de OWASP (enlace 1 de la lista MUST-READ) y se debe considerar la mejor práctica, incluso si se admite en el lado restrictivo.

Sin embargo, como regla general, diría que cuanto más fuerte sea su política de contraseña, menos tendrá que molestar a los usuarios con retrasos. Si necesita contraseñas de más de 9 caracteres (caracteres alfanuméricos sensibles a mayúsculas y minúsculas requeridas) o más, puede dar a los usuarios 2 a 4 intentos de contraseña sin demora antes de activar la regulación.

DoS atacar este esquema final de estrangulamiento de inicio de sesión sería muy poco práctico. Y como toque final, siempre permita que los inicios de sesión persistentes (cookies) (y / o un formulario de inicio de sesión verificado por CAPTCHA) se transfieran, de modo que los usuarios legítimos no se retrasarán mientras el ataque esté en curso . De esa forma, el muy poco práctico ataque DoS se convierte en un ataque extremadamente poco práctico.

Además, tiene sentido realizar una aceleración más agresiva en las cuentas de administrador, ya que son los puntos de entrada más atractivos

PARTE VII: Ataques de fuerza bruta distribuidos

Dejando de lado, los atacantes más avanzados intentarán evadir el estrangulamiento de inicio de sesión "extendiendo sus actividades":

  • Distribuir los intentos en una red de bots para evitar el marcado de direcciones IP

  • En lugar de elegir un usuario y probar las 50.000 contraseñas más comunes (que no pueden, debido a nuestra limitación), elegirán LA contraseña más común y la probarán contra 50.000 usuarios. De esa manera, no solo obtienen medidas de intentos máximos como CAPTCHAs y aceleración de inicio de sesión, sino que también aumentan sus posibilidades de éxito, ya que la contraseña más común número 1 es mucho más probable que la número 49.995

  • Separando las solicitudes de inicio de sesión de cada cuenta de usuario, por ejemplo, con 30 segundos de diferencia, para colarse bajo el radar

Aquí, la mejor práctica sería registrar el número de inicios de sesión fallidos en todo el sistema y utilizar un promedio corriente de la frecuencia de inicio de sesión incorrecto de su sitio como base para un límite superior que luego impone a todos los usuarios.

Demasiado abstracto? Déjame reformular

Digamos que su sitio ha tenido un promedio de 120 inicios de sesión incorrectos por día durante los últimos 3 meses. Usando eso (promedio de ejecución), su sistema puede establecer el límite global en 3 veces ese, es decir. 360 intentos fallidos en un período de 24 horas. Luego, si el número total de intentos fallidos en todas las cuentas supera ese número dentro de un día (o incluso mejor, supervise la velocidad de aceleración y el disparo en un umbral calculado), se activa la aceleración de inicio de sesión en todo el sistema, lo que significa pequeños retrasos para TODOS los usuarios (aún así, con la excepción de los inicios de sesión de cookies y / o los inicios de sesión de respaldo de CAPTCHA).

También publiqué una pregunta con más detalles y una discusión realmente buena sobre cómo evitar las trampas falsas en la defensa de los ataques de fuerza bruta distribuidos

PARTE VIII: Proveedores de autenticación y autenticación de dos factores

Las credenciales pueden verse comprometidas, ya sea por exploits, las contraseñas que se escriben y se pierden, las computadoras portátiles con claves robadas o los usuarios que ingresan a los sitios de phishing. Los inicios de sesión pueden protegerse aún más con la autenticación de dos factores, que utiliza factores fuera de banda como los códigos de un solo uso recibidos de una llamada telefónica, mensaje SMS, aplicación o dongle. Varios proveedores ofrecen servicios de autenticación de dos factores.

La autenticación se puede delegar completamente a un servicio de inicio de sesión único, donde otro proveedor se encarga de recopilar las credenciales. Esto lleva el problema a un tercero de confianza. Google y Twitter proporcionan servicios de SSO basados ​​en estándares, mientras que Facebook proporciona una solución propietaria similar.

ENLACES DE SEGURIDAD DE LA LEY sobre la autenticación web

  1. Guía de OWASP para la autenticación / hoja de referencia de autenticación OWASP
  2. Qué hacer y qué no hacer con la autenticación del cliente en la Web (documento de investigación del MIT muy legible)
  3. Wikipedia: cookie HTTP
  4. Preguntas de conocimiento personal para la autenticación alternativa: preguntas de seguridad en la era de Facebook (documento de investigación de Berkeley muy legible)

Al hacer hash, no utilice algoritmos de hash rápidos como MD5 (existen muchas implementaciones de hardware). Utilice algo como SHA-512. Para las contraseñas, los hashes más lentos son mejores.

Cuanto más rápido pueda crear hashes, más rápido podrá funcionar cualquier comprobador de fuerza bruta. Por lo tanto, los hashes más lentos reducirán la velocidad de la fuerza bruta. Un algoritmo hash lento hará que la fuerza bruta no sea práctica para contraseñas más largas (8 dígitos +)

Me gustaría añadir un comentario muy importante:

  • "En una empresa, intra ajuste de red," la mayoría, si no todo lo anterior podría no aplicarse!

Muchas corporaciones implementan sitios web de "uso interno exclusivo" que, efectivamente, son "aplicaciones corporativas" que se implementaron a través de URL. Estas URL solo pueden (supuestamente ...) resolverse dentro de "la red interna de la empresa". (¿Qué red incluye mágicamente todos los ''guerreros de la carretera'' conectados a VPN?)

Cuando un usuario está debidamente conectado a la red antes mencionada, su identidad ("autenticación") es [ya ...] "conocida de manera concluyente", al igual que su permiso ("autorización") para hacer ciertas cosas ... como. .. "para acceder a este sitio web".

Este servicio de "autenticación + autorización" se puede proporcionar mediante varias tecnologías diferentes, como LDAP (Microsoft OpenDirectory) o Kerberos.

Desde su punto de vista, simplemente sabe esto: cualquier persona que legítimamente termine en su sitio web debe ir acompañada de [una variable de entorno que contiene mágicamente ...] un "token". (Es decir, la ausencia de tal token debe ser motivo inmediato para 404 Not Found ).

El valor del token no tiene sentido para usted, pero, en caso de que surja la necesidad, "existen los medios adecuados" mediante los cuales su sitio web puede "[con autoridad] preguntar a alguien que sabe (LDAP ... etc.)" sobre todos y cada uno (!) pregunta que pueda tener. En otras palabras, usted no se aprovecha de ninguna "lógica propia". En cambio, usted pregunta por La Autoridad y confía implícitamente en su veredicto.

Eh eh ... es bastante un trastorno mental-interruptor de la "Internet salvaje-y-lana."

Me gustaría agregar una sugerencia que he usado, basada en la defensa en profundidad. No es necesario tener el mismo sistema de autenticación y autenticación para los administradores que los usuarios normales. Puede tener un formulario de inicio de sesión separado en una url separada ejecutando un código separado para las solicitudes que otorgarán altos privilegios. Éste puede tomar decisiones que serían un dolor total para los usuarios regulares. Uno de los que he usado es en realidad codificar la URL de inicio de sesión para el acceso de administrador y enviar por correo electrónico a la nueva URL. Detiene cualquier ataque de fuerza bruta de inmediato ya que su nueva URL puede ser arbitrariamente difícil (cadena aleatoria muy larga), pero el único inconveniente de su administrador es seguir un enlace en su correo electrónico. El atacante ya no sabe dónde POST incluso.

No creo que la respuesta anterior sea "incorrecta", pero hay grandes áreas de autenticación que no se tratan (o, más bien, el énfasis está en "cómo implementar sesiones de cookies", no en "qué opciones están disponibles y en qué consisten"). -offs ".

Mis ediciones / respuestas sugeridas son

  • El problema radica más en la configuración de la cuenta que en la comprobación de la contraseña.
  • El uso de la autenticación de dos factores es mucho más seguro que los medios más inteligentes de cifrado de contraseñas

  • NO intente implementar su propio formulario de inicio de sesión o el almacenamiento de la base de datos de contraseñas, a menos que los datos que se almacenan no tengan valor en la creación de la cuenta y se generen de manera autodidacta (es decir, estilo web 2.0 como Facebook, Flickr , etc.)

    1. La Autenticación Digest es un enfoque basado en estándares admitido en todos los principales navegadores y servidores, que no enviará una contraseña incluso a través de un canal seguro.

Esto evita cualquier necesidad de tener "sesiones" o cookies ya que el propio navegador volverá a cifrar la comunicación cada vez. Es el enfoque de desarrollo más "ligero".

Sin embargo, no recomiendo esto, a excepción de los servicios públicos de bajo valor. Este es un problema con algunas de las otras respuestas anteriores. No intente volver a implementar los mecanismos de autenticación del lado del servidor. Este problema se resolvió y es compatible con la mayoría de los principales navegadores. No utilice cookies. No almacene nada en su propia base de datos enrollada a mano. Solo pregunte, por solicitud, si la solicitud está autenticada. Todo lo demás debe ser compatible con la configuración y el software de confianza de terceros.

Asi que ...

Primero, estamos confundiendo la creación inicial de una cuenta (con una contraseña) con la revisión posterior de la contraseña. Si soy Flickr y estoy creando su sitio por primera vez, el nuevo usuario tiene acceso a valor cero (espacio web en blanco). Realmente no me importa si la persona que crea la cuenta miente sobre su nombre. Si estoy creando una cuenta de la intranet / extranet del hospital, el valor está en todos los registros médicos, por lo que sí me importa la identidad (*) del creador de la cuenta.

Esta es la parte muy difícil. La única solución decente es una red de confianza. Por ejemplo, te unes al hospital como médico. Crea una página web alojada en algún lugar con su foto, su número de pasaporte y una clave pública, y los mezcla con la clave privada. Luego visita el hospital y el administrador del sistema mira su pasaporte, ve si la foto coincide con usted y luego hace un hash en la página web / hash de foto con la clave privada del hospital. A partir de ahora podemos intercambiar claves y fichas de forma segura. Como puede cualquier persona que confíe en el hospital (existe la salsa secreta BTW). El administrador del sistema también puede proporcionarle un dongle RSA u otra autenticación de dos factores.

Pero esto es un gran problema, y ​​no es muy web 2.0. Sin embargo, es la única forma segura de crear nuevas cuentas que tienen acceso a información valiosa que no es de creación propia.

  1. Kerberos y SPNEGO - mecanismos de inicio de sesión único con un tercero de confianza - básicamente el usuario verifica contra un tercero de confianza. (Nota: esto no es de ninguna manera el OAuth en el que no se puede confiar )

  2. SRP : una especie de autenticación de contraseña inteligente sin un tercero de confianza. Pero aquí estamos entrando a los reinos de "es más seguro usar autenticación de dos factores, incluso si es más costoso"

  3. SSL Lado del cliente SSL : dé a los clientes un certificado de clave pública (soporte en todos los navegadores principales, pero plantea preguntas sobre la seguridad de la máquina del cliente).

Al final, es una compensación: ¿cuál es el costo de una violación de la seguridad frente al costo de implementar enfoques más seguros? Un día, es posible que veamos una PKI adecuada ampliamente aceptada y, por lo tanto, no más bases de datos y formularios de autenticación enrollados. Un día...

No sé si fue mejor responder esto como una respuesta o como un comentario. Opté por la primera opción.

Con respecto a la PARTE IV: La funcionalidad de la contraseña olvidada en la primera respuesta, me gustaría hacer un punto sobre los ataques de tiempo.

En los formularios Recordar su contraseña , un atacante podría verificar una lista completa de correos electrónicos y detectar cuáles están registrados en el sistema (vea el enlace a continuación).

Con respecto al Formulario de contraseña olvidada, agregaría que es una buena idea igualar el tiempo entre consultas exitosas y no exitosas con alguna función de demora.

https://crypto.stanford.edu/~dabo/papers/webtiming.pdf

Simplemente pensé que compartiría esta solución que encontré para estar funcionando bien.

Lo llamo el Campo Dummy (aunque no lo he inventado así que no me acredites).

En resumen: solo tiene que insertar esto en su <form> y verificar que esté vacío al validar:

<input type="text" name="email" style="display:none" />

El truco es engañar a un robot para que piense que tiene que insertar datos en un campo obligatorio, por eso llamé la entrada "correo electrónico". Si ya tiene un campo llamado correo electrónico que está usando, debe intentar nombrar el campo ficticio con otra cosa como "compañía", "teléfono" o "dirección de correo electrónico". Simplemente elija algo que sepa que no necesita y lo que suena como algo que las personas normalmente encontrarían lógico para completar en un formulario web. Ahora ocultar el input campo usando CSS o JavaScript / jQuery - lo que le queda mejor - simplemente no activar la introducción type de hidden o bien el bot no caiga en la trampa.

Cuando esté validando el formulario (ya sea del lado del cliente o del servidor), verifique si su campo de relleno se ha completado para determinar si fue enviado por un humano o un bot.

Ejemplo:

En el caso de un ser humano: el usuario no verá el campo ficticio (en mi caso denominado "correo electrónico") y no intentará rellenarlo. Por lo tanto, el valor del campo ficticio aún debe estar vacío cuando se envía el formulario.

En el caso de un bot: el bot verá un campo cuyo tipo es text y un nombre email (o como se llame) e intentará lógicamente rellenarlo con los datos apropiados. No importa si diseñó el formulario de entrada con algún CSS sofisticado, los desarrolladores web lo hacen todo el tiempo. Cualquiera que sea el valor en el campo de relleno, no nos importa si es más grande que los 0 caracteres.

Utilicé este método en un libro de visitas en combinación con CAPTCHA , y no he visto una sola publicación de spam desde entonces. Antes había usado una solución solo para CAPTCHA, pero al final resultó en alrededor de cinco mensajes de spam cada hora. La adición del campo ficticio en el formulario ha detenido (al menos hasta ahora) la aparición de todo el correo no deseado.

Creo que esto también se puede usar bien con un formulario de inicio de sesión / autenticación.

Advertencia : Por supuesto, este método no es 100% infalible. Los bots pueden programarse para ignorar los campos de entrada con el estilo display:none aplicado. También debe pensar en las personas que utilizan algún tipo de autocompletado (como la mayoría de los navegadores tienen incorporado) para completar automáticamente todos los campos de formulario. Podrían igualmente recoger un campo ficticio.

También puede variar esto un poco dejando el campo de relleno visible pero fuera de los límites de la pantalla, pero esto depende totalmente de usted.

¡Ser creativo!

Primero, una advertencia fuerte de que esta respuesta no es la mejor opción para esta pregunta exacta. ¡Definitivamente no debería ser la mejor respuesta!

Seguiré adelante y mencionaré el BrowserID propuesto por Mozilla (o quizás más precisamente, el Protocolo Verificado de Correo Electrónico ) en el espíritu de encontrar una ruta de actualización para mejores enfoques de autenticación en el futuro.

Lo resumiré de esta manera:

  1. Mozilla es una organización sin fines de lucro con values que se alinean bien con la búsqueda de buenas soluciones a este problema.
  2. La realidad hoy en día es que la mayoría de los sitios web usan autenticación basada en formularios.
  3. La autenticación basada en formularios tiene un gran inconveniente, que es un mayor riesgo de phishing . Se solicita a los usuarios que ingresen información confidencial en un área controlada por una entidad remota, en lugar de un área controlada por su Agente de usuario (navegador).
  4. Dado que los navegadores son de confianza implícita (la idea de un agente de usuario es actuar en nombre del usuario), pueden ayudar a mejorar esta situación.
  5. La fuerza principal que detiene el progreso aquí es el bloqueo de la implementación . Las soluciones deben descomponerse en pasos que proporcionen algún beneficio incremental por sí mismos.
  6. El método descentralizado más simple para expresar una identidad que está integrada en la infraestructura de Internet es el nombre de dominio.
  7. Como segundo nivel de expresión de identidad, cada dominio administra su propio conjunto de cuentas.
  8. El formulario "cuenta @ dominio" es conciso y está soportado por una amplia gama de protocolos y esquemas de URI. Este identificador es, por supuesto, más reconocido universalmente como una dirección de correo electrónico.
  9. Los proveedores de correo electrónico ya son los proveedores de identidad primarios de facto en línea. Los flujos actuales de restablecimiento de contraseñas generalmente le permiten tomar el control de una cuenta si puede probar que controla la dirección de correo electrónico asociada a esa cuenta.
  10. El Protocolo Verificado de Correo Electrónico fue propuesto para proporcionar un método seguro, basado en la criptografía de clave pública, para agilizar el proceso de probar en el dominio B que tiene una cuenta en el dominio A.
  11. Para los navegadores que no son compatibles con el Protocolo de correo electrónico verificado (actualmente todos ellos), Mozilla proporciona un shim que implementa el protocolo en el código JavaScript del lado del cliente.
  12. Para los servicios de correo electrónico que no son compatibles con el Protocolo de correo electrónico verificado, el protocolo permite que terceros actúen como intermediarios de confianza, afirmando que han verificado la propiedad de una cuenta de un usuario. No es deseable tener un gran número de tales terceros; esta capacidad está destinada solo para permitir una ruta de actualización, y es muy preferible que los servicios de correo electrónico proporcionen estas afirmaciones por sí mismos.
  13. Mozilla ofrece su propio servicio para actuar como un tercero de confianza. Los proveedores de servicios (es decir, Partes confiables) que implementan el Protocolo de correo electrónico verificado pueden optar por confiar en las afirmaciones de Mozilla o no. El servicio de Mozilla verifica la propiedad de la cuenta de los usuarios utilizando los medios convencionales de enviar un correo electrónico con un enlace de confirmación.
  14. Los proveedores de servicios pueden, por supuesto, ofrecer este protocolo como una opción además de cualquier otro método de autenticación que deseen ofrecer.
  15. Un gran beneficio de la interfaz de usuario que se busca aquí es el "selector de identidad". Cuando un usuario visita un sitio y elige autenticarse, su navegador le muestra una selección de direcciones de correo electrónico ("personal", "trabajo", "activismo político", etc.) que pueden usar para identificarse en el sitio.
  16. Otro beneficio importante de la interfaz de usuario que se está buscando como parte de este esfuerzo es ayudar al navegador a conocer más sobre la sesión del usuario, en quién está registrado actualmente, principalmente, por lo que puede mostrarlo en el navegador del navegador.
  17. Debido a la naturaleza distribuida de este sistema, evita el bloqueo en sitios importantes como Facebook, Twitter, Google, etc. Cualquier individuo puede poseer su propio dominio y, por lo tanto, actuar como su propio proveedor de identidad.

Esto no es estrictamente "autenticación basada en formularios para sitios web". Pero es un esfuerzo para pasar de la norma actual de autenticación basada en formularios a algo más seguro: la autenticación compatible con el navegador.