Aquí podría ser tu PUBLICIDAD


La guía definitiva para la autenticación de sitios basada en formularios

votos
4943

Autenticación basada en formularios para sitios web

Creemos que Stack Overflow 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 dicho experimento.

Debe incluir temas tales como:

  • Cómo iniciar sesión
  • Cómo desconectarse
  • Cómo permanecer conectado
  • Gestión de cookies (incluida la configuración recomendada)
  • Cifrado SSL / HTTPS
  • Cómo almacenar contraseñas
  • Usando preguntas secretas
  • Olvidé mi nombre de usuario / contraseña
  • Uso de nonces para evitar falsificaciones de solicitudes entre sitios (CSRF)
  • OpenID
  • Casilla Recordarme
  • Autocompletado del navegador de nombres de usuario y contraseñas
  • URL secretas ( URL pública protegida por resumen)
  • Comprobando la fortaleza de la contraseña
  • Validación de correo electrónico
  • y mucho más sobre autenticación basada en formularios ...

No debe incluir cosas como:

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

Por favor ayúdenos por:

  1. Sugerir subtemas
  2. Presentando buenos artículos sobre este tema
  3. Editando la respuesta oficial
Publicado el 02/08/2008 a las 20:51
fuente por usuario Michiel de Mare
En otros idiomas...        العربية       

12 respuestas

votos
3460

PARTE I: Cómo iniciar sesión

Supondremos que ya sabe cómo crear un formulario HTML de inicio de sesión + contraseña que PUBLICA los valores a un script en el lado del servidor para la autenticación. Las siguientes secciones se ocuparán de los patrones de autenticación práctica sólida y de cómo evitar las dificultades de seguridad más comunes.

¿HTTPS o no a HTTPS?

A menos que la conexión ya sea segura (es decir, en túnel mediante HTTPS utilizando SSL / TLS), sus valores de formulario de inicio de sesión se enviarán en texto claro, lo que permite a cualquier persona que escuche en la línea entre el navegador y el servidor web leer los inicios de sesión mediante. Este tipo de intervención telefónica se realiza de manera rutinaria por parte de los gobiernos, pero en general no abordaremos los cables 'de propiedad' excepto para decir esto: si está protegiendo algo importante, use HTTPS.

En esencia, la única forma práctica de protegerse contra escuchas telefónicas / detección 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 eludido fácilmente por un atacante que esté escuchando.

Por supuesto, si está dispuesto a ser un 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) Transfiere tu propio cifrado / hash de JavaScript

Dado el costo no nulo y la dificultad técnica percibida de configurar un certificado SSL en su sitio web, algunos desarrolladores están tentados de implementar sus propios esquemas de cifrado o hash en el navegador para evitar pasar inicios de sesión sin cifrar a través de 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, asegurar la línea con una encriptación fuerte o usar una respuesta de desafío comprobada. mecanismo (si no sabe qué es eso, solo 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 hash la contraseña puede ser efectiva contra la divulgación de contraseñas , es vulnerable a ataques de repetición, ataques / secuestros Man-In-The-Middle (si un atacante puede inyectar unos pocos bytes en su página HTML no segura antes de que llegue a su navegador, simplemente pueden comentar el hash en JavaScript) o ataques de fuerza bruta (ya que le está entregando al atacante tanto el nombre de usuario, como la contraseña de hash y de sal).

CAPTCHAS contra la humanidad

Los CAPTCHA están destinados a frustrar una categoría específica de ataque: prueba automatizada de diccionario / fuerza bruta sin operador humano. No hay duda de que esta es una amenaza real, sin embargo, hay maneras de lidiar con ella a la perfección que no requieren un CAPTCHA, específicamente esquemas de aceleración de inicio de sesión en el servidor debidamente diseñados - los discutiremos luego.

Sepa que las implementaciones de CAPTCHA no se crean de la misma manera; a menudo no son solucionables por humanos, la mayoría de ellos son ineficaces contra los bots, todos son ineficaces contra la mano de obra barata del tercer mundo (según OWASP , la tasa actual de explotación es de $ 12 por cada 500 pruebas), y algunas implementaciones pueden ser técnicamente ilegal en algunos países (ver la Hoja de referencia de autenticación de OWASP ). Si debe usar un CAPTCHA, use el reCAPTCHA de Google , ya que es resistente al OCR por definición (ya que utiliza escaneos de libros clasificados por OCR) y se esfuerza por ser fácil de usar.

Personalmente, tiendo a pensar que CAPTCHAS es molesto, y los uso solo como último recurso cuando un usuario no ha podido iniciar sesión varias veces y las demoras de aceleración se ven maximizadas. Esto sucederá en raras ocasiones para ser aceptable, y fortalece el sistema como un todo.

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

Esto finalmente puede ser de conocimiento común después de todos los hacks altamente publicitados y fugas de datos de usuario que hemos visto en los últimos años, pero debe decirse: No almacene contraseñas en texto claro en su base de datos. Las bases de datos de los usuarios se piratean, filtran o extraen rutinariamente a través de la inyección de SQL, y si está almacenando contraseñas en texto sin formato, eso es 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 y contraseña PUBLICADA desde el formulario de inicio de sesión sea correcta? La respuesta es hash usando una función de derivación de tecla . Cada vez que se crea un nuevo usuario o se cambia una contraseña, se toma la contraseña y se ejecuta a través de un KDF, como Argon2, bcrypt, scrypt o PBKDF2, convirtiendo la contraseña de texto claro ("correcthorsebatterystaple") en una larga cadena de aspecto aleatorio , que es mucho más seguro almacenar en su base de datos. Para verificar un inicio de sesión, ejecuta la misma función hash en la contraseña ingresada, esta vez transfiere la sal y compara la cadena hash resultante con el valor almacenado en su base de datos. Argon2, brypt y scrypt almacenan la sal con el hash ya. Consulte este artículo en sec.stackexchange para obtener información más detallada.

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

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 fuertes (es decir, no contienen suficiente entropía) y un atacante con acceso a los hashes puede completar un ataque de adivinación de contraseñas. Esta es la razón por la que se usa un KDF: estos "alargan la llave" de manera efectiva, lo que significa que cada contraseña que adivina un atacante implica iterar el algoritmo de hash varias veces, por ejemplo 10,000 veces, haciendo que la contraseña del atacante adivine 10,000 veces más despacio.

Datos de sesión: "has iniciado sesión como Spiderman69"

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

Si no está familiarizado con los datos de la sesión, así es cómo funciona: una cadena generada aleatoriamente se almacena en una cookie que expira y se utiliza para hacer referencia a una colección de datos, los datos de la sesión, que se almacenan en el servidor. Si está usando un marco MVC, esto ya se maneja sin dudas.

Si es posible, asegúrese de que la cookie de sesión tenga los indicadores seguros y de solo HTTP establecidos cuando se envíen al navegador. El indicador httponly proporciona cierta protección contra la cookie que se lee con un 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 detección de red. El valor de la cookie no debe ser predecible. Cuando se presente una cookie que hace referencia a una sesión inexistente, su valor debe reemplazarse inmediatamente 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 completamente tan seguros como los inicios de sesión convencionales cuando los usuarios entienden cómo manejarlos; y, por otro lado, representan un enorme riesgo de seguridad en manos de usuarios descuidados, que pueden utilizarlos en computadoras públicas y olvidarse de cerrar la sesión, y que 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 con regularidad, 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 la conciencia limpia. De lo contrario, puede suscribirse a la filosofía de que los usuarios descuidados con sus credenciales de inicio de sesión se encargarán de ellos si son pirateados. No es como si fuéramos a las casas de nuestros usuarios y arrancáramos todas esas notas Post-it que inducen palmas con contraseñas que han alineado en el borde de sus monitores, tampoco.

Por supuesto, algunos sistemas no pueden darse el lujo de tener una cuenta pirateada; para tales sistemas, no hay forma de que pueda justificar tener 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 obtener un montón de elementos correctos, y el artículo hace un excelente trabajo al explicar cada uno.

  2. Y solo para reiterar una de las trampas más comunes, NO ALMACENE LA PERSONALIZADA COOKIE DE INICIO DE SESIÓN (TOKEN) EN SU BASE DE DATOS, ¡SOLO UN ASPECTO DE TI! El token de inicio de sesión es Equivalente de contraseña, por lo que si un atacante tiene en sus manos su base de datos, podrían usar los tokens para iniciar sesión en cualquier cuenta, como si fueran combinaciones de inicio de sesión y contraseña de texto claro. Por lo tanto, usar hash (de acuerdo con https://security.stackexchange.com/a/63438/5002 un hash débil funcionará bien para este propósito) cuando se almacenan tokens de inicio de sesión persistentes.

PARTE III: Uso de preguntas secretas

No implemente 'preguntas secretas' . La función de 'preguntas secretas' es un anti patrón de seguridad. Lea el documento del enlace número 4 de la lista DEBE LEER. Puede 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 o la mascota favorita de la madre

  • 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 responder que adivinar su contraseña. Cuál, para cualquier contraseña decente, es cada pregunta que puedes imaginar

En conclusión, las preguntas de seguridad son intrínsecamente inseguras en prácticamente todas sus formas y variaciones, y no deberían 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 convenientemente ahorran el costo de unas pocas llamadas de soporte de 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 debes usar preguntas de seguridad para manejar contraseñas de usuario olvidadas / perdidas; tampoco es necesario decir que nunca debe enviar por correo electrónico a los usuarios sus contraseñas reales. Existen al menos dos peligros más comunes para evitar en este campo:

  1. No restablezca una contraseña olvidada a una contraseña segura autogenerada: estas contraseñas son notoriamente difíciles de recordar, lo que significa que el usuario debe cambiarlas o escribirlas, por ejemplo, en un color amarillo brillante Post-It 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.

  2. Siempre hash el código / token de contraseña perdido en la base de datos. OTRA VEZ , este código es otro ejemplo de Equivalente de contraseña, por lo que DEBE ser hash en caso de que un atacante tenga en sus manos su base de datos. Cuando se solicita un código de contraseña perdido, envíe el código de texto claro a la dirección de correo electrónico del usuario, luego cópielo, 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 formulario de inicio de sesión, o un atacante simplemente usará esto para obtener acceso en su lugar. Asegurarse de generar "códigos de contraseña perdidos" muy largos (por ejemplo, 16 caracteres alfanuméricos sensibles a las mayúsculas y minúsculas) es un buen comienzo, pero considere agregar el mismo esquema de aceleración que el propio 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 verificación de la realidad: las 500 contraseñas más comunes

Bien, quizás la lista no sea la lista canónica de las contraseñas más comunes en cualquier sistema en cualquier lugar , pero es una buena indicación de lo mal que la gente elegirá sus contraseñas cuando no haya una política implementada. Además, la lista se ve espantosamente cerca de su hogar cuando la compara con análisis públicamente disponibles de contraseñas recientemente robadas.

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

Frustrar esto requiere 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 diseño de diccionario y teclado (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 fortaleza de la contraseña y mostrar un medidor de fuerza visual a un usuario es bueno, pero insuficiente. A menos que se haga cumplir, muchos usuarios lo ignorarán.

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

PARTE VI: Mucho más - O: Prevención de intentos de inicio de sesión de fuego rápido

Primero, eche un vistazo a los números: velocidades de recuperación de contraseña: ¿por cuánto tiempo se pondrá de pie su contraseña?

Si no tiene tiempo para revisar las tablas en ese enlace, esta es la lista de ellas:

  1. No hace falta prácticamente ningún tiempo para descifrar una contraseña débil, incluso si la descifra con un ábaco

  2. No requiere prácticamente tiempo para descifrar una contraseña alfanumérica de 9 caracteres, si es insensible a mayúsculas / minúsculas

  3. No se necesita prácticamente tiempo para descifrar una contraseña de mayúsculas y minúsculas intrincada, símbolos y letras y números, si tiene menos de 8 caracteres (una PC de escritorio puede buscar en todo el espacio de teclado hasta 7 caracteres en una cuestión de días o incluso horas)

  4. Sin embargo, tomaría una cantidad de tiempo desmesurada para 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, muchos, pero podemos centrarnos en la parte más importante: el hecho de que prevenir un gran número de intentos de inicio de sesión sucesivos de disparos rápidos (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 efectivas contra ataques de fuerza bruta (y ataques de diccionario, pero dado que ya está empleando una política sólida de contraseñas, no deberían ser un problema) :

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

  • Bloqueando cuentas y requiriendo verificación de correo electrónico después de N intentos fallidos (este es un ataque DoS esperando a suceder)

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

Práctica recomendada n. ° 1: un breve retraso que aumenta con el número de intentos fallidos, como:

  • 1 intento fallido = sin demora
  • 2 intentos fallidos = 2 segundos de retraso
  • 3 intentos fallidos = retraso de 4 segundos
  • 4 intentos fallidos = 8 segundos de retraso
  • 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: la demora no es un retraso antes de devolver la respuesta al navegador. Es más como un tiempo de espera o período refractario durante el cual los intentos de inicio de sesión a una cuenta específica o desde una dirección IP específica no serán aceptados ni evaluados en absoluto. Es decir, las credenciales correctas no volverán en un inicio de sesión exitoso, y las credenciales incorrectas no provocarán un aumento de la demora.

Práctica recomendada n. ° 2: una demora de duración media que entra en vigor 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 largo puede ser muy molesto para un usuario legítimo. A los usuarios olvidados no les gustará.

Práctica recomendada n. ° 3: combinación de los dos enfoques, ya sea un retraso de tiempo fijo y corto que entre en vigor después de N intentos fallidos, como:

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

O bien, 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 fue tomado de las sugerencias de mejores prácticas de OWASP (enlace 1 de la lista DEBE LEER), y se debe considerar la mejor práctica, incluso si se admite que está en el lado restrictivo.

Sin embargo, como regla general, diría que, cuanto más sólida sea su política de contraseñas, menos tendrá que molestar a los usuarios con retrasos. Si necesita contraseñas fuertes (números alfanuméricos sensibles a las mayúsculas y minúsculas + símbolos) de más de 9 caracteres, podría darles a los usuarios 2-4 intentos de contraseña no retardada antes de activar la aceleración.

El ataque DoS a este esquema de limitación de inicio de sesión final 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) pasen, para que los usuarios legítimos ni siquiera se retrasen mientras el ataque está en progreso . De esta forma, el muy poco práctico ataque DoS se convierte en un ataque extremadamente poco práctico.

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

PARTE VII: Ataques de fuerza bruta distribuidos

Solo como un lado, los atacantes más avanzados intentarán eludir el límite de inicio de sesión "difundiendo sus actividades":

  • Distribuir los intentos en una botnet para evitar marcar la dirección IP

  • En lugar de elegir un usuario y probar las 50,000 contraseñas más comunes (que no pueden, debido a nuestra aceleración), escogerán LA contraseña más común y la probarán contra 50,000 usuarios en su lugar. De esta forma, no solo logran evitar las medidas de máximo intento como los CAPTCHA y la aceleración de inicio de sesión, también aumentan sus posibilidades de éxito, ya que la contraseña número 1 más común es mucho más probable que el número 49.995.

  • Espaciar las solicitudes de inicio de sesión para cada cuenta de usuario, por ejemplo, con 30 segundos de diferencia, para escabullirse por debajo del 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 continuo de la frecuencia de inicio de sesión incorrecta de su sitio como base para un límite superior que luego impondrá a todos los usuarios.

Demasiado abstracto? Déjame reformular:

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

También publiqué una pregunta con más detalles y una muy buena discusión sobre cómo evitar las trampas difíciles al defenderse de los ataques de fuerza bruta distribuidos.

PARTE VIII: Autenticación de dos factores y proveedores de autenticación

Las credenciales pueden verse comprometidas, ya sea por exploits, contraseñas que se anoten o pierdan, por el robo de las computadoras portátiles o por el ingreso de usuarios a los sitios de phishing. Los inicios de sesión pueden protegerse aún más con autenticación de dos factores, que utilizan factores fuera de banda, como 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 por completo a un servicio de inicio de sesión único, donde otro proveedor maneja la recolección de credenciales. Esto lleva el problema a un tercero confiable. Google y Twitter ofrecen servicios SSO basados ​​en estándares, mientras que Facebook ofrece una solución propietaria similar.

DEBE LEER ENLACES Acerca de la autenticación web

  1. Guía de Autentificación / Autentificación OWASP de OWASP
  2. Lo que se debe y no se debe hacer con la autenticación de clientes en la web (documento de investigación muy legible del MIT)
  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)
Respondida el 25/01/2009 a las 12:27
fuente por usuario Jens Roland


Aquí podría ser tu PUBLICIDAD


votos
382

Artículo definitivo

Enviando credenciales

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

  • Si la conexión entre el cliente y el servidor no está encriptada, todo lo que haces es vulnerable a los ataques man-in-the-middle . 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 del cliente y hacerse pasar por los usuarios a la perfección, etc. etc. SSL con Autoridades de certificación de confianza está diseñado para prevenir ataques MitM.
  • La contraseña hash recibida por el servidor es menos segura si no realiza un trabajo redundante adicional en el servidor.

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

Almacenamiento de contraseñas

Nunca almacene contraseñas como texto sin formato en la base de datos. Ni siquiera si no le importa la seguridad de su propio sitio. Asuma que algunos de sus usuarios reutilizarán la contraseña de su cuenta bancaria en línea. Por lo tanto, almacene la contraseña hash y deseche el original. Y asegúrese de que la contraseña no aparezca en los registros de acceso o de la aplicación. OWASP recomienda el uso de Argon2 como su primera opción para nuevas aplicaciones. Si 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, las contraseñas idénticas significan hashes idénticos: esto hace que las tablas de búsqueda de hash sean una forma efectiva de descifrar muchas contraseñas al mismo tiempo. En cambio, almacena el hash salado . Una sal es una cadena adjunta a la contraseña antes de la mezcla: 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. Mira aquí 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 demostrar 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 es mejor. Lea la PARTE III: Usar preguntas secretas en la respuesta de @Jens Roland aquí en esta wiki.

Cookies de sesión

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

Las cookies pueden ser secuestradas : solo son tan seguras como el resto de la máquina del cliente y otras comunicaciones. Se pueden leer desde el disco, detectarse en el tráfico de la red, eliminarse mediante un ataque de secuencias de comandos entre sitios, detectarse 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 se cierra o abandona su dominio).

Si desea autenticar a sus usuarios, puede establecer una cookie persistente, pero debe ser distinta de una cookie de sesión completa. Puede establecer un indicador adicional que el usuario ha iniciado sesión automáticamente y necesita iniciar sesión para operaciones confidenciales reales. Esto es popular entre los sitios de compras que desean ofrecerle una experiencia de compra personalizada y sin problemas, pero aún así proteger sus detalles financieros. Por ejemplo, cuando regresa a visitar Amazon, le muestran una página que parece haber iniciado sesión, pero cuando va a realizar un pedido (o cambia su dirección de envío, tarjeta de crédito, etc.), le piden que confirme 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

Respondida el 02/08/2008 a las 09:40
fuente por usuario Michiel de Mare

votos
146

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

Voy a seguir adelante y hablar propuesta de Mozilla BrowserID (o quizás más precisamente, el verificado Enviar Protocolo ) en el espíritu de la búsqueda de una ruta de actualización a mejores enfoques para la autenticación en el futuro.

Voy a resumir de esta manera:

  1. Mozilla es una organización no lucrativa con los valores que se alinean bien con la búsqueda de buenas soluciones a este problema.
  2. La realidad de hoy es que la mayoría de los sitios web utilizan la autenticación basada en formularios
  3. La autenticación basada en formulario tiene un gran inconveniente, que se aumenta el riesgo de suplantación de identidad . Se les pide a los usuarios introducir información sensible en una zona controlada por una entidad remota, en lugar de una zona controlada por el agente de usuario (navegador).
  4. Ya que los navegadores son de confianza implícita (la idea de un agente de usuario es actuar en nombre del usuario), que pueden ayudar a mejorar esta situación.
  5. La fuerza primaria frenando el progreso aquí es estancamiento despliegue . Las soluciones deben ser descompuestos en pasos que proporcionan algún beneficio incremental en su propia cuenta.
  6. El método más simple descentralizada para expresar la identidad que se construye en la infraestructura de Internet es el nombre de dominio.
  7. Como segundo nivel de expresión de la identidad, cada dominio gestiona su propio conjunto de cuentas.
  8. La forma “cuenta de @dominio” es conciso y apoyado por una amplia gama de protocolos y esquemas de URI. Un identificador tal es, por supuesto, más universalmente reconocida como una dirección de correo electrónico.
  9. proveedores de correo electrónico son ya la de-facto proveedores de identidad en línea primaria. flujos de restablecimiento de contraseñas actuales generalmente permiten tomar el control de una cuenta si se puede demostrar que el control de la dirección de correo electrónico asociada de esa cuenta.
  10. Se propuso el protocolo de correo electrónico verificado proporcionar un método seguro, basado en la criptografía de clave pública, para agilizar el proceso de probar al dominio B que tiene una cuenta en el dominio A.
  11. Para los navegadores que no soportan el protocolo de correo electrónico verificado (en la actualidad todos ellos), Mozilla proporciona una cuña que implementa el protocolo en el lado del cliente el código JavaScript.
  12. Para los servicios de correo electrónico que no son compatibles con el protocolo de correo electrónico verificado, el protocolo permite a terceros para actuar como un intermediario de confianza, afirmando que han verificado la propiedad de un usuario de una cuenta. No es deseable tener un gran número de estas terceras partes; esta capacidad está destinado sólo para permitir una ruta de actualización, y es mucho más preferible que los servicios de correo electrónico proporcionan estas mismas afirmaciones.
  13. Mozilla ofrece su propio servicio para actuar como un tercero de confianza. Los proveedores de servicios (es decir, partes que confían) que implementan el protocolo de correo electrónico verificado pueden optar por confiar en afirmaciones o no de Mozilla. servicio de Mozilla verifica la propiedad de 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 (s) de autenticación que pudieran ofrecer.
  15. Un gran beneficio interfaz de usuario que se busca aquí es el “selector de identidad”. Cuando un usuario visita un sitio y elige para autenticar, su navegador les muestra una selección de direcciones de correo electrónico ( “personal”, “trabajo”, “actividad política”, etc.) se pueden utilizar para identificarse en el sitio.
  16. Otro gran beneficio interfaz de usuario que se busca como parte de este esfuerzo está ayudando a que el navegador sabe más acerca de la sesión del usuario - que han iniciado sesión en la actualidad, sobre todo - por lo que puede mostrar que en el navegador de cromo.
  17. Debido a la naturaleza distribuida de este sistema, se evita el lock-in a los principales sitios como Facebook, Twitter, Google, etc. Cualquier persona puede poseer su propio dominio y por lo tanto actuar como su propio proveedor de identidad.

Esto no es estrictamente “la autenticación basada en formularios para los sitios web”. Pero es un esfuerzo de hacer la transición de la norma actual de la autenticación basada en formularios a algo más seguro: la autenticación navegador compatible.

Respondida el 08/08/2011 a las 04:32
fuente por usuario Charlie

votos
120

Sólo pensé que me gustaría compartir esta solución que he encontrado para trabajar bien.

Lo llamo el campo ficticio (aunque no lo he inventado esto así que no me crédito).

En resumen: sólo hay que insertarlo en tu <form>y comprobar para que sea vacío en la hora de validar:

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

El truco consiste en engañar a un bot para que piense que tiene que insertar datos en un campo obligatorio, por eso puse el nombre de la "e-mail" de entrada. Si ya tiene un campo llamado de correo electrónico que está utilizando usted debe tratar de nombrar el campo ficticio otra cosa, como "empresa", "teléfono" o "EMAILADDRESS". Sólo tiene que elegir algo que sabes que no es necesario y lo que suena como algo que la gente normalmente encontraría lógico que rellenar en un formulario web. Ahora ocultar el inputcampo usando CSS o JavaScript / jQuery - lo que le queda mejor - simplemente no activar la introducción typede hiddeno bien el bot no caiga en la trampa.

Cuando se está validando la forma (ya sea cliente o servidor) comprobar si su campo ficticio se ha llenado para determinar si se envía por un humano o un robot.

Ejemplo:

En caso de un humano: El usuario no verá el campo ficticio (en mi caso llamado "e-mail") y no tratará de llenarlo. Por lo que el valor del campo ficticio todavía debe estar vacío cuando el formulario ha sido enviado.

En caso de un robot: El robot verá un campo cuyo tipo es texty un nombre email(o lo que sea que llaman) y tendrá lógicamente intentar llenarlo con los datos apropiados. No importa si una decoración cuidada el formulario de entrada con un poco de fantasía CSS, los desarrolladores web lo hacen todo el tiempo. Cualquiera que sea el valor en el campo ficticio es, no nos importa el tiempo que es más grande que 0los personajes.

He utilizado este método en un libro de visitas en combinación con CAPTCHA de , y no he visto un solo puesto de spam desde entonces. Había utilizado una solución CAPTCHA sólo antes, pero con el tiempo dio lugar a unos cinco mensajes de spam cada hora. Añadiendo el campo ficticio en forma se ha detenido (al menos hasta ahora) todo el correo no deseado aparezca.

Creo que esto también se puede utilizar muy bien con un formulario de acceso / autenticación.

Advertencia : Por supuesto, este método no es 100% a prueba de tontos. Los robots pueden ser programados para ignorar los campos de entrada con el estilo display:noneque se le aplica. También hay que pensar en las personas que utilizan alguna forma de auto-completado (como la mayoría de los navegadores han incorporado!) Para automóviles de cantidades de llenado todos los campos del formulario para ellos. Puede ser que del mismo modo que recoger un campo ficticio.

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

¡Ser creativo!

Respondida el 22/05/2012 a las 01:11
fuente por usuario Pieter888

votos
71

No creo que la respuesta anterior es "malo", pero hay grandes extensiones de autenticación que no se tocan (o más bien el énfasis está en "cómo implementar sesiones de cookies", no en "qué opciones están disponibles y cuáles son las ventajas offs".

Mis ediciones sugeridas / respuestas son

  • El problema radica más en la configuración de cuentas que en la comprobación de contraseñas.
  • El uso de dos authenitication factor es mucho más seguro que los medios más inteligentes de cifrado de la contraseña
  • NO trate de implementar su propio formulario de acceso o almacenamiento de base de datos de contraseñas, a menos que los datos sean almacenados no tiene valor en la creación de la cuenta y la auto-generado (es decir, estilo web 2.0 como Facebook, Flickr , etc.)

    1. Recopilación de autenticación es un enfoque basado en los estándares de apoyo en todos los principales navegadores y servidores, que no va a enviar una contraseña, incluso por un canal seguro.

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

Sin embargo, no recomiendo esto, a excepción de los servicios de valor público, bajos. Este es un problema con algunas de las otras respuestas anteriores - no intente una re-implementar mecanismos authetication del lado del servidor - este problema se ha resuelto y está apoyada por la mayoría de los navegadores más importantes. No utilizar cookies. No guarde nada en su propia base de datos enrollados a mano. Sólo hay que preguntar, por solicitud, si la solicitud es autheticated. Todo lo demás debe ser compatible con el software de configuración y de confianza de terceros.

Asi que ...

En primer lugar, estamos confundiendo la creación inicial de una cuenta (con una contraseña) con la re-verificación de la contraseña posteriormente. Si soy Flickr y la creación de su sitio por primera vez, el nuevo usuario tiene acceso a valor cero (espacio de la tela en blanco). Realmente no me importa si la persona que crea la cuenta está mintiendo sobre su nombre. Si estoy creando una cuenta de la intranet del hospital / extranet, el valor se encuentra en todos los registros médicos, y por lo que no se preocupan por la identidad (*) del creador de la cuenta.

Esta es la parte muy, muy difícil. La única solución decente es una red de confianza. Por ejemplo, se inscribe en el hospital como médico. Se crea una página web alojada en algún lugar con su foto, su número de pasaporte y una clave pública, y el hash a todos con la clave privada. A continuación, visita el hospital y el administrador del sistema se ve en su pasaporte, si ve la foto que coincide, y luego hashes el hash página web / foto con la clave privada del hospital. A partir de ahora podemos intercambiar de forma segura las claves y tokens. Como cualquiera puede que confía en el hospital (no es el ingrediente secreto por cierto). El administrador del sistema también puede darle una RSA mochila u otro autenticación de dos factores.

Pero esto es un montón de problemas, y no 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 - inicio de sesión único con mecanismos de un tercero de confianza -, básicamente, el usuario verifica contra un tercero de confianza. (Nota: esto no es de ninguna manera el no es de fiar OAuth )

  2. SRP - tipo de autenticación de contraseña inteligente sin un tercero de confianza. Pero aquí estamos entrando en los dominios de la "es más seguro utilizar autenticación de dos factores, incluso si eso es más costoso"

  3. SSL lado del cliente - dar a los clientes un certificado de clave pública (apoyo en todos los principales navegadores - pero plantea dudas sobre la seguridad de la máquina cliente).

Al final se trata de una solución de compromiso - ¿cuál es el costo de una brecha de seguridad contra el costo de la aplicación de enfoques más seguros. Un día, podemos ver una adecuada PKI ampliamente aceptada y así no más propias formas de autenticación laminado y bases de datos. Un día...

Respondida el 08/08/2011 a las 05:29
fuente por usuario you cad sir - take that

votos
48

Cuando hash, no utilice algoritmos hash rápido como MD5 (existen muchas implementaciones de hardware). Usar algo como SHA-512. Para las contraseñas, los hashes más lentas son mejores.

Cuanto más rápido se puede crear hashes, más rápido cualquier corrector fuerza bruta puede trabajar. Por lo tanto, los hashes más lentas se ralentizará ataques de fuerza bruta. Un algoritmo de hash lenta hará ataques de fuerza bruta poco práctico para las contraseñas más largas (+ 8 dígitos)

Respondida el 09/08/2011 a las 12:07
fuente por usuario josh

votos
46

Un buen artículo sobre la estimación de la contraseña es realista:

Blog »Blog Archive» zxcvbn Dropbox Tech: estimación realista de la contraseña

Respondida el 08/11/2012 a las 12:15
fuente por usuario Frutik

votos
41

Mi regla favorito en lo que respecta a la autenticación de sistemas: utilizar frases de contraseña, las contraseñas. Fácil de recordar, difícil de romper. Más información: Horror Codificación: Contraseñas vs frases codificadas

Respondida el 24/11/2012 a las 10:15
fuente por usuario pixeline

votos
20

Me gustaría añadir una sugerencia que he usado, basado en la defensa en profundidad. Usted no necesita tener el mismo sistema de autenticación y autenticación para administradores como usuarios regulares. Puede tener una forma independiente de acceso en una URL distinta ejecutar código separado para las solicitudes que conceder privilegios elevados. Éste puede tomar decisiones que serían un total dolor a los usuarios habituales. Uno de estos que he utilizado es en realidad a desordenar la URL de inicio de sesión para el acceso de administrador y correo electrónico del administrador de la nueva URL. Detiene cualquier ataque de fuerza bruta de inmediato como su nueva URL puede ser arbitrariamente difícil (cadena aleatoria muy largo), pero sólo inconveniente con el administrador de usuario está siguiendo un enlace en su correo electrónico. El atacante ya no sabe dónde incluso publicar a.

Respondida el 18/07/2015 a las 01:18
fuente por usuario Iain Duncan

votos
12

Me dont't sabía si era posible para responder a esto como una respuesta o como un comentario. Yo he optado por la primera opción.

En cuanto a la poing PARTE IV: ¿Ha olvidado la funcionalidad de contraseña en la primera respuesta, me gustaría hacer un punto sobre la sincronización ataques.

En los recuerda su contraseña formas, un atacante podría potencialmente comprobar una lista completa de los mensajes de correo electrónico y detectar que se registra en el sistema (ver enlace más abajo).

Respecto de la forma para contraseña olvidada, me gustaría añadir que es una buena idea para igualar los tiempos entre consultas correctas y unsucessful con alguna función de retardo.

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

Respondida el 16/08/2015 a las 05:31
fuente por usuario rxx

votos
10

Me gustaría añadir una observación muy importante:

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

Muchas empresas despliegan "uso interno" sitios web que son, efectivamente, "las aplicaciones corporativas" que pasan a se han aplicado mediante las URL. Estas URLs pueden (supuestamente ...) sólo se pueden resolver dentro "de la red interna de la empresa." (Red que incluye mágicamente todos conectados a la VPN 'guerreros de la carretera.')

Cuando un usuario se conecta-cumplidamente a la red antes mencionada, su identidad ( "autenticación") es [ya ...] "concluyente conocido", como es su permiso ( "autorización") para hacer ciertas cosas ... por ejemplo. .. "para acceder a este sitio web."

Este servicio "autenticación + autorización" puede ser proporcionado por varias tecnologías diferentes, tales como LDAP (Microsoft OpenDirectory) , o Kerberos.

Desde su punto de vista, sólo tiene que saber esto: que cualquier persona que legítimamente Vientos-para arriba en su sitio web debe "token" ir acompañada de [un entorno variable que contiene mágicamente ...] una ( Es decir, la ausencia de un contador de este tipo debe ser motivo inmediatas para 404 Not Found.)

Valor del token no tiene sentido para usted, pero, en caso de necesidad, "existen medios apropiados" por el cual su sitio web puede "[autoridad] pedirle a alguien que conozca (LDAP ... etc)" acerca de cualquier y todos los ( !) pregunta que usted pueda tener. En otras palabras, usted no servirse de cualquier "lógica de cosecha." En su lugar, se recabará de la autoridad e implícitamente confía en su veredicto.

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

Respondida el 29/04/2015 a las 01:06
fuente por usuario Mike Robinson

votos
5

Utilizar OpenID Conectar o acceso administrado por el usuario .

Como nada es más eficiente que no hacerlo en absoluto.

Respondida el 10/08/2016 a las 10:27
fuente por usuario jwilleke


Aquí podría ser tu PUBLICIDAD