¿Por qué los formularios de inicio de sesión siguen usando 'name = “pass”' o similar?

3

Dado que hay muchos scripts MitM de rastreo de contraseñas por ahí que combinan el tráfico en busca de frases clave como "pass" y "password".

¿Por qué los fabricantes mantienen los mismos nombres de variables y facilitan a los atacantes?

Seguramente los fabricantes (de enrutadores, etc.) podrían usar la variable "pasar" en el código fuente, pero cambiarla a una cadena aleatoria específica para ese dispositivo en el momento del lanzamiento, lo que hace que sea casi imposible seleccionar la contraseña. sin peinar manualmente un gran archivo de paquetes capturados.

    
pregunta aidan 23.07.2017 - 11:39
fuente

2 respuestas

4

Autocompletar. La mayoría de los navegadores ahora tienen administradores de contraseñas, que posiblemente sean más seguros que recordar su contraseña, ya que le permiten tener contraseñas diferentes que son ilegibles para cada sitio. ¿Cómo puede un usuario recordar que su contraseña de Facebook es "a! 34-tU62-He4M" y su contraseña de Google "e4T? -Y5Bf-6gR6". Compuesto que con el número de cuentas que las personas tienen y se vuelve una locura. Ahora, si todo lo que un usuario necesita recordar es su contraseña maestra, y siempre que las contraseñas se almacenen de forma segura, pueden tener contraseñas únicas para cada sitio que sean seguras.

Los administradores de contraseñas solo pueden funcionar si saben cuál es la entrada. Un campo llamado "x1" no significa nada para un administrador de contraseñas, y no capturará ni completará datos en él. Sin embargo, se marcará un campo denominado "contraseña".

    
respondido por el zzarzzur 23.07.2017 - 14:53
fuente
1

Usted está asumiendo una gran cantidad de fabricantes de enrutadores: principalmente, que son buenos en las mejores prácticas de seguridad. Caso en cuestión: mi enrutador (un linkysys) no tiene un nombre en el campo de la contraseña, porque convierte el formulario en un envío ajax que pasa la contraseña a través de la autenticación BÁSICA. No hace esto a través de HTTPS (una opción terrible), y también intenta desactivar la función de autocompletar en el campo de contraseña (otro terrible elección de seguridad ). (Ahora recuerdo por qué compré un enrutador compatible con el firmware de código abierto: es hora de descubrirlo ...). En serio: no asuma que los fabricantes de enrutadores tienen alguna idea de lo que están haciendo cuando se trata de seguridad. editar Anteriormente dije que la contraseña de mi enrutador estaba encriptada en el lado del cliente antes de enviar. Me di cuenta de que la seguridad era tan mala que no había forma de que lo hicieran. Así que hice doble comprobación. No estaba encriptado. Eran solo base64 que codificaba la combinación de nombre de usuario y contraseña para facilitar el transporte.

Como lo mencionó @ISMSDEV, su sugerencia es solo seguridad a través de la oscuridad. Como regla general, no es el mejor método para asegurar nada. La seguridad a través de la oscuridad puede disuadir ataques automatizados más simples, por lo que no es una locura intentarlo, siempre que su aplicación sea segura. No querrá preocuparse por eso como su único método de seguridad (que obviamente no es lo que está sugiriendo).

Sin embargo, todas las cosas en el software implican un análisis de costo-beneficio. La introducción de métodos de seguridad ad hoc es más probable que presente más errores (y más puntos por vulnerabilidades) que cualquier otra cosa. Más seguridad siempre es buena, pero debe asegurarse de que cualquier medida de seguridad dada tenga un beneficio real. Agregar más código para mantener con beneficio marginal probablemente dañará la seguridad a largo plazo.

Presumiblemente, la mayoría de los fabricantes de enrutadores no consideran que una función de seguridad valga la pena. Por otra parte, ni siquiera consideran que la seguridad básica valga la pena el esfuerzo. shrug

    
respondido por el Conor Mancone 24.07.2017 - 05:24
fuente

Lea otras preguntas en las etiquetas