¿Es suficiente esta seguridad de inicio de sesión?

Cuidado con el exceso, es contraproducente. Si su sistema de inicio de sesión es demasiado incómodo o molesto, los usuarios intentarán activamente solucionarlo. "Usuarios", aquí, incluye a los desarrolladores de aplicaciones y administradores de servidores.

  

el formulario de inicio de sesión es seguro SSL

Este es el más importante, pero no "solo". En teoría, todo el sitio debe estar protegido con SSL, no solo con el formulario de inicio de sesión. SSL proporciona confidencialidad con respecto a los escuchas ilegales, pero si da como resultado una cookie que luego envía de forma clara para mantener la sesión, entonces un escuchador solo tiene que enviar la misma cookie para secuestrar una sesión. Si solo el formulario de inicio de sesión está protegido con SSL, la única seguridad que obtiene aquí es en combinación con una capacitación exhaustiva contra el phishing: usted educa a los usuarios para que no envíen sus contraseñas a sitios que no tienen SSL activo, y por lo tanto usted necesita un sitio SSL. Pero eso es marginal.

  La contraseña

se convierte a sha256 antes   siendo transmitido (bcrypt es muy lento   todavía para JS / navegador cliente)

Este es inútil. Solo significa que el resultado SHA-256 es la contraseña. Si un atacante puede capturarlo, entonces el atacante puede usarlo para iniciar sesión, sin siquiera saber la contraseña "verdadera".

  

la contraseña hash está cifrada con   clave privada almacenada como CONSTANTE en   aplicación / archivo

Esta función es una ganancia de seguridad solo en la situación en la que el atacante podría obtener las contraseñas con hash pero no los archivos de la aplicación. Si esta es una situación realista es discutible. Por otro lado, esa clave constante molestará a los administradores cuando se va a actualizar la aplicación y puede incurrir en un tiempo de inactividad adicional (es muy fácil olvidarlo al implementar ...). Además, esto hace que la confidencialidad de los archivos de la aplicación sea un objetivo importante, que es bastante poco común.

  

recaptcha en el primer fallo de inicio de sesión

Esto será más molesto que seguro.

  

sistema de inicio de sesión por dispositivo, por lo que si   el usuario intenta 5 inicios de sesión dif y   Están todos mal, él está fuera. no es 5   por inicio de sesión

No bloquee cuentas, solo agregue retrasos (por ejemplo, un minuto). De lo contrario, cualquiera puede bloquear la cuenta de cualquiera, lo cual es un problema. El conteo de intentos por dispositivo es bueno, pero es sutil y puede ser contraproducente: existen algunas redes (incluido el ISP) con NAT o proxy masivo, que se convierten, desde el punto de vista del servidor, en miles de solicitudes de inicio de sesión desde la misma fuente IP.

  

autenticación de 2 pasos usando sms, correo electrónico? o   AlterEgo - tal vez una vez por dispositivo +   ubicación y para ser utilizado si quieres   cambia tu contraseña

     

si inicia sesión   desde una ubicación diferente diferente   desde el historial, envíe SMS / Email al usuario

Los SMS pueden molestar a los usuarios: no funcionan bien para los usuarios internacionales, requieren un teléfono móvil funcional en el momento y algunas personas pagan por los SMS que reciben (depende del país y del proveedor de telefonía móvil). El correo electrónico es ligeramente mejor (pero, por supuesto, no si la aplicación que está intentando proteger es un correo web ...).

  

tiene la opción de guardar el inicio de sesión   dispositivo + ubicación en la historia (es decir, no   Utilice esta opción si está en un netcafe   o una red pública, etc.) así lo hará   siempre pide tu 2step

Tenga en cuenta que en un netcafe, la seguridad va por el fregadero. Un registrador de claves es demasiado invisible. No hay mucho que puedas hacer contra eso.

  

Entonces, ¿creo que voy a exagerar?

Sí. Pero, lo que es más importante, también le falta la característica importante, que es SSL en todo el sitio.

Los factores clave que siempre busco en una especificación de definición de proyecto faltan aquí:

¿Qué estás protegiendo? ¿De quién lo estás protegiendo? ¿Cuál es el impacto si está comprometido?

Si está protegiendo su lista de cumpleaños de amigos, es casi seguro que es una exageración. Si está protegiendo el material de Top Secret del espionaje internacional o corporativo, puede ser demasiado débil.

Debe pensar en el riesgo potencial, los actores de amenazas que lo pueden atacar y otros factores como la resistencia (¿un inicio de sesión fallido un lunes por la mañana hace que sea extremadamente difícil para un usuario obtener acceso cuando realmente lo necesita? )

Esperamos que tenga respuestas a estas, pero a menos que las publique aquí puede ser difícil para otros proporcionar orientación sobre la arquitectura de seguridad.

Estás usando muchas palabras de seguridad aquí, pero el resultado final no es tan seguro como debería ser, y como Lucanos dice que hay mucha redundancia.

Vaya a leer este hilo .

  

la contraseña se convierte a sha256 antes de ser transmitida (bcrypt es demasiado lento aún para JS / navegador cliente)   bcrypt hashes almacenados

¿Eso significa que generas un hash bcrypt del hash sha256 de la contraseña? Sin un salt, la contraseña de sha256 no hace nada para ayudar a la seguridad, y usar una segunda ronda de hash tampoco ayuda.

  

la contraseña con hash se cifra con una clave privada almacenada como CONSTANTE en la aplicación / archivo

¿Qué? ¿Por qué? ¿Alguna vez quieres recuperar el hash del hash de la contraseña? Incluso si lo hicieras, la forma de hacerlo sería cifrar usando una clave pública.

  

recaptcha en el primer fallo de inicio de sesión

No agrega mucho valor.

  

si la información del dispositivo / ubicación cambia al iniciar sesión, finalice la sesión

Por lo tanto, estamos hablando de la administración de sesiones y de la autenticación, en ese caso, todavía tienes mucho trabajo por hacer.

Hay algunas cosas que no consigo aquí, y probablemente una o dos cosas que vale la pena agregar:

• la contraseña con hash está cifrada con clave privada almacenada como CONSTANTE en aplicación / archivo

Como "CONSTANTE", ¿qué significa eso? ¿Es difícil codificado? ¿Cómo se protege? Estoy de acuerdo con otras publicaciones en que una sal es un buen plan: si usted salta y hash las contraseñas, no veo la necesidad de cifrarlas. Y, si la clave privada para su cifrado se almacena en un archivo plano o codificado en la aplicación, tiene una debilidad allí. Recomiendo encontrar una manera de proteger mejor esta clave.

• "por dispositivo"

En varios lugares mencionas que estás siguiendo el comportamiento "por dispositivo", ¿qué significa eso? ¿Cómo estás determinando qué es el dispositivo? Aquí está implicando un tipo de autenticación de dispositivo, y por lo poco que sé sobre esta área, la mayoría de las formas son inmensamente falsas, y las formas que no requieren la emisión de dispositivos desde un punto de confianza, lo que puede cambiar mucho su modelo de operación. .

En los lugares donde dices "por dispositivo", tendrás que pensar qué significa si el dispositivo está falsificando tu sistema. Además, si ha decidido que "Dirección IP"="dispositivo", es posible que deba considerar numerosas situaciones en las que la dirección IP del usuario está cambiando sin que el usuario tenga la culpa.

• permitir que el historial de inicio de sesión sea borrado de dispositivos antiguos

¿Es eso algo que estás completamente preparado para soportar? Frotar, digamos, una cookie es bastante fácil, pero ¿te refieres a todas las partes de la memoria? Personalmente, si estuviera haciendo esta promesa, la vincularía de alguna manera para que si el sistema operativo colocara la información de inicio de sesión en un lugar extraño, no fuera una violación de lo que mi sistema había prometido a los usuarios.

También veo algunos problemas:

• ¿Cómo puede un usuario recuperarse de una contraseña perdida / olvidada?

Lo veo citando un proceso bastante complicado para cambiar la contraseña. Si este es un sistema web casual, apostaría dinero a que esta será su función menos utilizada. En su lugar, los usuarios se alejarán del sistema, solo para regresar y necesitar sus contraseñas y los han olvidado por completo (o los escribieron en una nota adhesiva en sus pantallas ... eso es aún peor).

Necesitará una forma de recuperar / restablecer la contraseña que se ajuste a su modelo de alta protección. ¿Está atendido por una persona? ¿Tienen preguntas de respaldo para responder? ¿Reciben una contraseña de restablecimiento por correo electrónico fuera de banda? Cada mecanismo de recuperación tiene riesgo, y generalmente menos riesgo = mayor costo; por ejemplo, la verificación de identidad definitiva de la compañía de mi tarjeta de crédito para este tipo de preguntas es una pregunta dolorosa con una persona real sobre mi historial de compras. Muy bien, pero costoso en términos del salario de esa persona.

• Una forma sencilla para que los usuarios veten el sistema

La credencial presentada por el servidor en SSL debería ser lo suficientemente buena, pero muy pocos usuarios tienen suficiente PKI para eso. Sé que las grandes instituciones financieras han empezado a utilizar palabras e imágenes seleccionadas por los usuarios que los usuarios deben verificar durante el inicio de sesión. El objetivo principal aquí es evitar una situación en la que un phisher podría enviar a su usuario un correo electrónico para que lo envíen a "paypa1.com" (un número 1, no una letra), y obtener sus contraseñas. Ya que tiene funciones que se adaptan al inicio de sesión remoto, su atacante podrá usar una cuenta de usuario legítima desde cualquier sistema.

• Otra ingeniería social

Es probable que estos dos problemas no sean los únicos procesos orientados a las personas en los que deba pensar: ¿registra los accesos? ¿Tiene un plan para separar la auditoría de inicio de sesión de los privilegios de administración? ¿Cuánto acceso tienen los administradores y cómo está protegido el sistema de ellos? ¿Hay otros ataques de ingeniería social que puedan funcionar?

Hasta ahora, lo que describe es una tecnología pesada y una luz humana: está hablando de un par de mecanismos que pueden tener un impacto en la usabilidad, lo que podría hacer que los usuarios no usen el sistema o que los usuarios tomen medidas para piratear El sistema lo hace más fácil de usar, y me preocupa que no haya pensado en los vectores de ataque de un ingeniero social. Al igual que el agua, los piratas informáticos encontrarán la grieta o hendidura más fácil de usar.

Te estoy golpeando con las cosas pesadas aquí, porque mi percepción es que estás tratando de diseñar algo de alta calidad para algo que presumiblemente es de alto riesgo. Si eso es lo que está tratando de diseñar, entonces debe realizar una copia de seguridad y ver el sistema whole : su comunidad de usuarios, el nacimiento hasta la muerte de las cuentas, el comportamiento dentro del sistema y los riesgos de mala conducta.

Sólo voy a ofrecer algunas preguntas para intentar y 1) educarme y 2) ofrecerle una perspectiva diferente sobre el sistema:

  

la contraseña se convierte a sha256 antes de ser transmitida (bcrypt es demasiado lento aún para JS / navegador cliente)

Para comenzar, si está utilizando una conexión SSL, ¿necesita hacer esto? Incluso en el caso de que alguien haya podido interceptar la contraseña con hash, ¿cómo es eso más seguro que interceptar la contraseña de texto simple? Si pude falsificar el inicio de sesión y enviar la misma carga útil hash, ¿en qué se diferencia?

  

un hash de todos los valores importantes de la base de datos de inicio de sesión para ese usuario, de modo que si se modifican mediante una inyección, el hash no coincidirá y la cuenta se bloqueará

Entonces, si el usuario actualiza su dirección de correo electrónico o contraseña, ¿el hash cambiará y la sesión terminará? ¿O tiene garantías para permitir que estos cambios legítimos se manejen?

  

si la información del dispositivo / ubicación cambia al iniciar sesión, finalice la sesión (para evitar el robo de la sesión)

No estoy 100% seguro de esto, pero esto podría significar que un teléfono móvil podría ser expulsado de una sesión (legítima) si hace la transición de WiFi a GSM / Celular, GSM / Celular a WiFi o posiblemente dentro de la red GSM / Celular ( si cambia la dirección IP pública presentada por el dispositivo)?

  

sistema de inicio de sesión por dispositivo por dispositivo, por lo que si el usuario intenta 5 inicios de sesión diferidos y todos se equivocan, está fuera. no es 5 por inicio de sesión

¿Cómo estás siguiendo "por dispositivo"? ¿Por la dirección IP? Se puede compartir. ¿Por una galleta? Se puede purgar. ¿Por una cadena de User-Agent? También se puede cambiar.

Aparte de estos, algunas de las otras ideas suenan bien.

Ok, esto es lo que he aprendido de las respuestas de todos

• Use SSL, no es necesario que el lado de la contraseña del hash no tenga sentido, SSL es la forma correcta de protegerse contra el rastreo.
• Use BCrypt (w / Salt) para almacenar el hash de la contraseña, SCrypt si puedo encontrar una implementación de PHP de este.
• No bloquee el inicio de sesión por una contraseña fallida, solo use un límite de tiempo creciente para evitar DOS. Por supuesto, registrar los intentos fallidos y alertar a los administradores si se está volviendo inusualmente alto.
• el cifrado y la repetición de las contraseñas no tiene sentido
• considere formas de examinar el sistema y evitar la ingeniería social
• forzar contraseñas largas y duras para los usuarios, como usar passwdqc para verificar y permitirles saber qué contraseñas se esperan de ellos.
• el bloqueo debido a los cambios de ubicación / dispositivo puede ser problemático en los teléfonos celulares, inalámbricos o en algunos ISP, considere tal vez simplemente cerrar la sesión.
• necesita implementar adecuadamente la administración de sesiones
• la sesión de administrador debe permanecer dentro del área SSL.