Autenticación basada en formularios para sitios web

Creemos que Stack Overflow no solo debe ser un recurso para preguntas técnicas muy específicas, sino también 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
• Administrar cookies (incluidas las configuraciones recomendadas)
• Cifrado SSL / HTTPS
• Cómo almacenar contraseñas
• Usando preguntas secretas
• Funcionalidad de nombre de usuario / contraseña olvidada
• Uso de nonces para evitar falsificaciones de solicitudes entre sitios (CSRF)
• OpenID
• Casilla "Recordarme"
• Navegador de autocompletado de nombres de usuario y contraseñas
• URL secretas ( URL pública protegida por resumen)
• Comprobación de la seguridad 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 autorizaciones
• Autenticación básica HTTP

Por favor ayúdenos por:

1. Sugerir subtemas
2. Enviar 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 PUBLICA los valores en un script en el lado del servidor para la autenticación. Las secciones a continuación tratarán los patrones para una autenticación práctica y sólida, y cómo evitar las trampas de seguridad más comunes.

¿A HTTPS o no a HTTPS?

A menos que la conexión ya sea segura (es decir, tunelizada a través de HTTPS usando SSL / TLS), los valores de su formulario de inicio de sesión se enviarán en texto sin formato, lo que permite que cualquier persona que escuche 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 los gobiernos, pero en general, no abordaremos los cables 'propios' más que para decir esto: solo use HTTPS.

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

Por supuesto, si está dispuesto a ser un poco poco práctico, también puede 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 percibido (aunque ahora evitable ) y la dificultad técnica de configurar un certificado SSL en su sitio web, algunos desarrolladores se ven tentados a implementar sus propios esquemas de cifrado o hash en el navegador para evitar pasar inicios de sesión de texto sin cifrar por un cable no seguro.

Si bien este es un pensamiento noble, es esencialmente inútil (y puede ser una falla de seguridad ) a menos que se combine con uno de los anteriores, es decir, asegurar la línea con un cifrado fuerte o usar una respuesta de desafío probada 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 el hash de la contraseña puede ser efectivo contra la divulgación de la contraseña , 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ás entregando al atacante nombre de usuario, sal y contraseña hash).

CAPTCHAS contra la humanidad

CAPTCHA está destinado a frustrar una categoría específica de ataque: diccionario automatizado / prueba y error de fuerza bruta sin operador humano. No hay duda de que esta es una amenaza real, sin embargo, hay formas de tratarlo sin problemas que no requieren un CAPTCHA, específicamente esquemas de aceleración de inicio de sesión del lado del servidor específicamente diseñados; discutiremos eso más adelante.

Sepa que las implementaciones de CAPTCHA no se crean por igual; a menudo no tienen solución humana, la mayoría de ellos no son efectivos 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 500 pruebas), y algunas implementaciones pueden ser técnicamente ilegal en algunos países (ver la hoja de trucos de autenticación OWASP ). Si debe usar un CAPTCHA, use el reCAPTCHA de Google , ya que es difícil de OCR por definición (ya que usa escaneos de libros ya mal clasificados por OCR) y se esfuerza mucho por ser fácil de usar.

Personalmente, tiendo a encontrar CAPTCHAS 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 se han agotado. Esto ocurrirá raramente lo suficiente como para ser aceptable, y fortalece el sistema en su conjunto.

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

Finalmente, esto puede ser de conocimiento común después de todos los hacks muy publicitados y las filtraciones de datos de usuarios que hemos visto en los últimos años, pero hay que decir: No almacene contraseñas en texto sin cifrar en su base de datos. Las bases de datos de los usuarios se piratean, filtran o recogen de forma rutinaria mediante inyección SQL, y si está almacenando contraseñas sin formato, de texto sin formato, se acabó el juego instantáneamente 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 hashing usando una función de derivación de clave . 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 sin formato ("correcthorsebatterystaple") en una cadena larga 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 pasando la sal y compara la cadena hash resultante con el valor almacenado en su base de datos. Argon2, bcrypt y scrypt ya almacenan la sal con el hash. Consulte este artículo 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ás agregar una llamada 'sal' para proteger el hash contra las tablas del arco iris . Una sal efectivamente evita que dos contraseñas que coinciden exactamente se almacenen como el mismo valor hash, evitando que se escanee 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 los hash 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 KDF: estos efectivamente "estiran la clave" , lo que significa que cada contraseña que adivina un atacante provoca múltiples repeticiones 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 ha verificado el inicio de sesión y la contraseña en su base de datos de usuario y ha encontrado una coincidencia, el sistema necesita una forma de recordar que el navegador ha sido autenticado. Este hecho solo debe almacenarse 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 aleatoriamente se almacena en una cookie que caduca y se usa para hacer referencia a una colección de datos, los datos de la sesión, que se almacenan en el servidor. Si está utilizando un marco MVC, esto ya se maneja indudablemente.

Si es posible, asegúrese de que la cookie de sesión tenga los indicadores seguros y HTTP Only establecidos cuando se envían al navegador. El indicador HttpOnly proporciona cierta protección contra la cookie que se lee a través del ataque XSS. El indicador seguro garantiza que la cookie solo se envíe de vuelta a través de HTTPS y, por lo tanto, protege contra ataques de detección de redes. El valor de la cookie no debe ser predecible. Cuando se presenta 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 casilla de verificación "Recordarme" infame

Las cookies de inicio de sesión persistentes (funcionalidad "recordarme") son una zona peligrosa; 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 de seguridad en manos de usuarios descuidados, que pueden usarlos en computadoras públicas y olvidarse de cerrar 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 regularmente, pero sé cómo manejarlos de manera segura. Si está seguro de que sus usuarios saben lo mismo, puede usar inicios de sesión persistentes con la conciencia limpia. Si no, bueno, entonces puedes suscribirte a la filosofía de que los usuarios que son descuidados con sus credenciales de inicio de sesión se lo imponen si son pirateados. No es como si fuéramos a las casas de nuestros usuarios y arrancamos todas esas notas Post-It que inducen el uso de la palma de la mano con las contraseñas que han alineado en el borde de sus monitores.

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

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

1. Primero, tómese un tiempo para leer el artículo de Paragon Initiative sobre el tema. Tendrá que acertar un montón de elementos, y el artículo hace un gran trabajo al explicar cada uno.

2. Y solo para reiterar uno de los escollos más comunes, ¡NO ALMACENE LA COOKIE DE INICIO DE SESIÓN PERSONAL (TOKEN) EN SU BASE DE DATOS, ¡SOLO UN CHOQUE! El token de inicio de sesión es Equivalente a la contraseña, por lo que si un atacante tiene en sus manos su base de datos, podría usar los tokens para iniciar sesión en cualquier cuenta, como si fueran combinaciones de texto libre de inicio de sesión y contraseña. Por lo tanto, use hashing (de acuerdo con 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: Uso de preguntas secretas

No implemente 'preguntas secretas' . La función 'preguntas secretas' es un antipatrón de seguridad. Lea el documento del enlace número 4 de la lista DEBE LEER. Puedes preguntarle a Sarah Palin sobre eso, después de que 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 su mascota favorita

• Una simple 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. Lo cual, para cualquier contraseña decente, es cada pregunta que puedas imaginar

En conclusión, las preguntas de seguridad son inherentemente 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 que las preguntas de seguridad incluso existen en la naturaleza es que ahorran convenientemente el costo de algunas 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 debe usar preguntas de seguridad para manejar contraseñas de usuario olvidadas / perdidas; Tampoco hace falta decir que nunca debe enviar por correo electrónico a los usuarios sus contraseñas reales. Hay al menos dos escollos más comunes para evitar en este campo:

1. No restablezca una contraseña olvidada a una contraseña segura generada automáticamente; tales contraseñas son notoriamente 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 a esto 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 perdido en la base de datos. OTRA VEZ , este código es otro ejemplo de Equivalente de Contraseña, por lo que DEBE ser modificado 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 sin formato a la dirección de correo electrónico del usuario, luego escríbalo, 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. Es un buen comienzo asegurarse de generar 'códigos de contraseña perdidos' muy largos (por ejemplo, 16 caracteres alfanuméricos que distinguen entre mayúsculas y minúsculas), pero considere agregar el mismo esquema de aceleración que hace para el formulario de inicio de sesión.

PARTE V: Verificar la seguridad 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

De acuerdo, puede que la lista no es la canónica lista de la mayoría de las contraseñas comunes en cualquier sistema en cualquier lugar siempre , pero es una buena indicación de cómo la gente pobre va a elegir sus contraseñas cuando no existe una política forzada en su lugar. Además, la lista se ve terriblemente cerca de casa cuando la compara con análisis disponibles públicamente de contraseñas recientemente robadas.

Entonces: sin requisitos mínimos de seguridad de 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, 1 de cada 50 cuentas en su sitio web será descifrable.

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 diccionario y un análisis de diseño del 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 seguridad de la contraseña y mostrar un medidor de fuerza visual a un usuario es bueno, pero insuficiente. A menos que se aplique, 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 la seguridad de la contraseña xkcd de Randall Munroe .

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

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

Primero, eche un vistazo a los números: Velocidades de recuperación de contraseña: ¿cuánto tiempo durará su contraseña?

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

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

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

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

4. Sin embargo, tomaría una cantidad excesiva de tiempo 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 centrarnos en la parte más importante: el hecho de que evitar grandes cantidades de intentos de inicio de sesión sucesivos de fuego rápido (es decir, el ataque de fuerza bruta ) realmente no es tan difícil. Pero prevenirlo bien 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 como ya está empleando una política de contraseñas segura, 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í)

• Bloqueo de cuentas y solicitud de verificación de correo electrónico después de N intentos fallidos (este es un ataque DoS a punto de ocurrir)

• Y finalmente, 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 probables y mucho más complicados de lograr).

Mejor práctica n. ° 1: un retraso de tiempo corto 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 = 4 segundos de retraso
• 4 intentos fallidos = retraso de 8 segundos
• 5 intentos fallidos = 16 segundos de retraso
• etc.

El ataque DoS a 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 como un tiempo de espera o 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 volverán en un inicio de sesión exitoso, y las credenciales incorrectas no provocarán un aumento de retraso.

Mejor práctica # 2: un retraso de tiempo medio que entra en vigencia después de N intentos fallidos, como:

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

El ataque DoS a este esquema sería poco práctico, pero ciertamente factible. Además, puede ser relevante tener en cuenta que un retraso tan largo puede ser muy molesto para un usuario legítimo. A los usuarios olvidadizos no les gustará.

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

• 1-4 intentos fallidos = sin demora
• Más de 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 fue tomado de las sugerencias de mejores prácticas de OWASP (enlace 1 de la lista DEBE-LEER) y debe considerarse como la mejor práctica, incluso si es ciertamente del lado restrictivo.

Sin embargo, como regla general, diría: cuanto más fuerte sea su política de contraseña, menos tendrá que molestar a los usuarios con demoras. Si necesita contraseñas seguras (alfanuméricas que distingan entre mayúsculas y minúsculas + números y símbolos requeridos) de más de 9 caracteres, puede dar a los usuarios 2-4 intentos de contraseña sin demora antes de activar la limitación.

El ataque DoS a este esquema de aceleración de inicio de sesión final sería muy poco práctico. Y como toque final, siempre permita que pasen inicios de sesión persistentes (cookies) (y / o un formulario de inicio de sesión verificado por CAPTCHA) para que los usuarios legítimos ni siquiera se retrasen mientras el ataque está en curso . De esa manera, el ataque DoS muy poco práctico 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

Como comentario aparte, los atacantes más avanzados tratarán de eludir la limitación de inicio de sesión 'extendiendo sus actividades':

• Distribuir los intentos en una botnet 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 evitan medidas de intentos máximos como CAPTCHA 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 el número 49.995

• Espaciar las solicitudes de inicio de sesión para cada cuenta de usuario, digamos, con 30 segundos de diferencia, para escabullirse 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 usar un promedio continuo 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 en los últimos 3 meses. Usando eso (promedio de ejecución), su sistema puede establecer el límite global a 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 dentro de un día (o incluso mejor, controle la tasa de aceleración y se dispare en un umbral calculado), se activa la limitación de inicio de sesión en todo el sistema, lo que significa retrasos breves para TODOS los usuarios (aún, con la excepción de inicios de sesión de cookies y / o inicios de sesión de CAPTCHA de respaldo).

También publiqué una pregunta con más detalles y una muy buena discusión sobre cómo evitar trampas difíciles para 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 escritas y perdidas, computadoras portátiles con claves robadas o 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 maneja la recopilación de credenciales. Esto empuja el problema a un tercero de confianza. Google y Twitter proporcionan servicios SSO basados ​​en estándares, mientras que Facebook ofrece una solución propietaria similar.

ENLACES DEBEN LEER Acerca de la autenticación web

1. Guía de autenticación OWASP / Hoja de referencia de autenticación OWASP
2. Lo que se debe y no se debe 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)

Artículo definitivo

Envío de credenciales

La única forma práctica de enviar credenciales al 100% de forma segura es mediante SSL . Usar JavaScript para trocear la contraseña no es seguro. Errores 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 es 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 hacerse pasar por los usuarios perfectamente, etc. etc. SSL con autoridades de certificación confiables está diseñado para prevenir ataques MitM.
• La contraseña cifrada recibida por el servidor es menos segura si no realiza trabajo redundante adicional en el servidor.

Hay 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 sin formato en la base de datos. Ni siquiera si no le importa la seguridad de su propio sitio. Suponga que algunos de sus usuarios reutilizarán la contraseña de su cuenta bancaria en línea. Por lo tanto, guarde la contraseña cifrada y deseche el 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 hashes 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 a la vez. En cambio, almacene el hash salado . Una sal es una cadena agregada a la contraseña antes del hash: 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 aquí para más información 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 funciona mejor. Lea la PARTE III: Uso de preguntas secretas en la respuesta de @Jens Roland aquí en este 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 la identificación de la cookie, pero nadie más puede generar dicha cookie (TODO explica 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, detectar en el tráfico de la red, levantarlos mediante un ataque de secuencias de comandos en sitios cruzados, robar 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 se cierra o abandona su dominio).

Si desea iniciar sesión automáticamente a sus usuarios, puede configurar una cookie persistente, pero debe ser distinta de una cookie de sesión completa. Puede establecer un indicador adicional de que el usuario ha iniciado sesión automáticamente y necesita iniciar sesión real para operaciones confidenciales. Esto es popular entre los sitios de compras que desean brindarle una experiencia de compra personalizada y sin interrupciones, pero aún así proteger sus datos financieros. Por ejemplo, cuando vuelve a visitar Amazon, le muestran una página que parece que ha iniciado sesión, pero cuando realiza 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.

• Lo que se debe y no se debe hacer con la autenticación del cliente en la web (PDF)
  Artículo académico de 21 páginas con muchos consejos excelentes.
• Pregunte a YC: Mejores prácticas para la
  discusión del Foro de autenticación de usuarios sobre el tema
• Probablemente esté almacenando contraseñas
  Artículo incorrectamente introductorio sobre el almacenamiento de contraseñas
• Discusión: Coding Horror: Probablemente esté almacenando contraseñas incorrectamente.
  Discusión del foro sobre un artículo de Coding Horror.
• ¡Nunca almacene contraseñas en una base de datos!
  Otra advertencia sobre el almacenamiento de contraseñas en la base de datos.
• 
  Artículo de Wikipedia sobre descifrado de contraseñas sobre debilidades de varios esquemas de hash de contraseñas.
• Basta con las tablas del arco iris: lo que necesita saber sobre los esquemas de contraseña segura
  . Incluye una extensa discusión.

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

Seguiré y mencionaré el BrowserID propuesto por Mozilla (o quizás más precisamente, el Protocolo de correo electrónico verificado ) con 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 valores que se alinean bien con la búsqueda de buenas soluciones a este problema.
2. La realidad actual es que la mayoría de los sitios web utilizan 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 (toda 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 frena el progreso aquí es el punto muerto de despliegue . Las soluciones deben descomponerse en pasos que brinden un beneficio incremental por sí mismas.
6. El método descentralizado más simple para expresar una identidad 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 " @dominio de cuenta " es conciso y está respaldado por una amplia gama de protocolos y esquemas de URI. Tal identificador es, por supuesto, más universalmente reconocido como una dirección de correo electrónico.
9. Los proveedores de correo electrónico ya son los principales proveedores de identidad de facto en línea. Los flujos de restablecimiento de contraseña actuales generalmente le permiten tomar el control de una cuenta si puede probar que controla la dirección de correo electrónico asociada de esa cuenta.
10. El Protocolo de correo electrónico verificado se propuso para proporcionar un método seguro, basado en criptografía de clave pública, para racionalizar el proceso de probar al dominio B que tiene una cuenta en el dominio A.
11. Para los navegadores que no admiten el Protocolo de correo electrónico verificado (actualmente todos ellos), Mozilla proporciona una cuña que implementa el protocolo en el código JavaScript del lado del cliente.
12. Para los servicios de correo electrónico que no admiten 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 dichos terceros; Esta capacidad está destinada únicamente a permitir una ruta de actualización, y es 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 tan confiable. Los proveedores de servicios (es decir, las Partes confiantes) que implementan el Protocolo de correo electrónico verificado pueden optar por confiar o no en las afirmaciones de Mozilla. 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 (s) de autenticación que deseen ofrecer.
15. Una gran ventaja 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 gran beneficio de la interfaz de usuario que se busca como parte de este esfuerzo es ayudar al navegador a saber más sobre la sesión del usuario quién se ha registrado actualmente, para que pueda mostrar eso en el navegador Chrome.
17. Debido a la naturaleza distribuida de este sistema, evita el bloqueo a sitios importantes como Facebook, Twitter, Google, etc. Cualquier individuo puede ser dueño de 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 pasar de la norma actual de autenticación basada en formularios a algo más seguro: la autenticación compatible con el navegador.

Solo pensé en compartir esta solución que encontré que funcionaba bien.

Lo llamo el campo ficticio (aunque no he inventado esto, así que no me acrediten).

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 bot para que piense que tiene que insertar datos en un campo obligatorio, por eso llamé a la entrada "correo electrónico". Si ya tiene un campo llamado correo electrónico que está utilizando, intente nombrar el campo ficticio de otra manera, como "empresa", "teléfono" o "dirección de correo electrónico". Simplemente elija algo que sabe que no necesita y que suena como algo que la gente normalmente encontraría lógico para completar en un formulario web. Ahora ocultar el inputcampo usando CSS o JavaScript / jQuery - lo que le queda mejor - simplemente no se establece la entrada typea hiddeno 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 ficticio se ha completado para determinar si fue enviado por un humano o un bot.

Ejemplo:

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

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

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. Había usado una solución solo CAPTCHA antes, pero eventualmente resultó en aproximadamente cinco publicaciones de spam cada hora. Agregar el campo ficticio en el formulario ha detenido (al menos hasta ahora) la aparición de todo el spam.

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 se pueden programar para ignorar los campos de entrada con el estilo display:noneaplicado. También debe pensar en las personas que usan algún tipo de autocompletado (¡como la mayoría de los navegadores tienen incorporado!) Para autocompletar todos los campos del formulario. También podrían recoger un campo ficticio.

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

¡Ser creativo!

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

Mis ediciones / respuestas sugeridas son

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

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

  1. La autenticación implícita es un enfoque basado en estándares compatible con todos los principales navegadores y servidores, que no enviará una contraseña incluso a través de un canal seguro.

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

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

Entonces ...

Primero, estamos confundiendo la creación inicial de una cuenta (con una contraseña) con la verificación posterior de la contraseña. Si soy Flickr y creo su sitio por primera vez, el nuevo usuario tiene acceso al 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 reside en todos los registros médicos, por lo que me importa 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, te unes al hospital como médico. Usted crea una página web alojada en algún lugar con su foto, su número de pasaporte y una clave pública, y las numera con la clave privada. Luego visita el hospital y el administrador del sistema revisa su pasaporte, ve si la foto coincide con usted y luego aplica el hash de la página web / foto con la clave privada del hospital. De ahora en adelante podemos intercambiar llaves y tokens de forma segura. Como cualquiera que confíe en el hospital (existe la salsa secreta, por cierto). El administrador del sistema también puede darle un dongle RSA u otra autenticación de dos factores.

Pero esto es una gran cantidad de una molestia, 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, mecanismos de inicio de sesión único con un tercero confiable, básicamente el usuario verifica contra un tercero confiable. (Nota: esto no es de ninguna manera el no confiable OAuth )

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

3. Lado del cliente SSL : otorgue a los clientes un certificado de clave pública (soporte en todos los principales navegadores, 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 seguridad frente al costo de implementar enfoques más seguros. Un día, podemos ver una PKI adecuada ampliamente aceptada y, por lo tanto, no más formularios de autenticación y bases de datos propios. Un día...

Cuando realice el hash, no utilice algoritmos de hash rápidos como MD5 (existen muchas implementaciones de hardware). Usa 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 puede funcionar cualquier verificador de fuerza bruta. Los hash más lentos, por lo tanto, ralentizarán el forzamiento bruto. Un algoritmo de hash lento hará que la fuerza bruta sea poco práctica para contraseñas más largas (8 dígitos +)

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

Blog de Dropbox Tech »Archivo del blog» zxcvbn: estimación realista de la seguridad de la contraseña

Mi regla favorita con respecto a los sistemas de autenticación: usar frases de contraseña, no contraseñas. Fácil de recordar, difícil de descifrar. Más información: Coding Horror: Passwords vs. Pass Phrases

Me gustaría agregar una sugerencia que he usado, basada en la defensa en profundidad. No necesita 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 que ejecute código separado para solicitudes que otorgarán altos privilegios. Este puede tomar decisiones que serían un dolor total para los usuarios habituales. Uno de los que he usado es codificar la URL de inicio de sesión para el acceso de administrador y enviarle la nueva URL por correo electrónico. 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 usuario administrador es seguir un enlace en su correo electrónico. El atacante ya no sabe dónde POSTAR.

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

Con respecto a la parte IV de poing : la funcionalidad de contraseña olvidada en la primera respuesta, haría un comentario sobre los ataques de sincronización.

En el 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 (consulte el enlace a continuación).

Con respecto al formulario de contraseña olvidada, agregaría que es una buena idea igualar los tiempos entre consultas exitosas y no exitosas con alguna función de retraso.

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

Me gustaría agregar 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 "solo uso interno" que son, efectivamente, "aplicaciones corporativas" que se han implementado a través de URL. Estas URL pueden (supuestamente ...) solo resolverse dentro de "la red interna de la compañía".(Qué red incluye mágicamente a todos los 'guerreros de la carretera' conectados a VPN).

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

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

Desde su punto de vista, simplemente sabe esto: que cualquiera que legítimamente termine en su sitio web debe estar acompañado por [una variable de entorno que contenga mágicamente ...] un "token". ( es decir, la ausencia de dicho token debe ser motivo inmediato para ello 404 Not Found).

El valor del token no tiene sentido para usted, pero, si surge la necesidad, "existen los medios apropiados" por los cuales su sitio web puede "[autoritativamente] preguntarle a alguien que sabe (LDAP ... etc.)" sobre todos y cada uno (!) pregunta que puedas tener. En otras palabras, no se vale de ninguna "lógica propia". En cambio, le preguntas a La Autoridad y confías implícitamente en su veredicto.

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

Use OpenID Connect o acceso administrado por el usuario .

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