Robo de mis datos POST

Question

Bueno, esto es probablemente bastante básico, pero las implicaciones son importantes para mí en esta fase de desarrollo. Estoy agradecido por cualquier aporte y discusión.

Los datos de este ejemplo no están protegidos mediante el cifrado SSL.

---

page1.php/asp contiene un formulario de qué puestos las variables username y password-page2.php/asp.

---

• Puede cualquier persona desde cualquier lugar de intercepción mis datos POST sólo escuchar para ello, tal vez con algún software de terceros como Firesheep?

Si la pregunta anterior hace VERDADERO:

• ¿Debo siempre tenga en cuenta mis datos POST no cifradas de libre acceso para cualquier persona?
• ¿El formulario de inicio de sesión estándar en mi sitio es solo una estratagema para representar una capa de seguridad que ni siquiera está ahí?
• ¿Debo considerar la función de inicio de sesión como una forma de personalizar la experiencia del usuario?
• ¿Tiene sentido alentar al usuario a NO utilizar su contraseña normal (supuestamente más segura), ya que no estará protegida durante sus procedimientos de registro e inicio de sesión?

Considero estas cuestiones, agradezco cualquier aporte y comentarios.

Answer 1

¿Alguien de CUALQUIER parte puede interceptar mis datos de POST simplemente escuchándolos, quizás con algún software de terceros como Firesheep?

No, el tráfico tiene que pasar cerca de ellos.

Si la pregunta anterior hace VERDADERO:

no lo hace, pero aún así.

¿Debo considerar siempre que mis datos POST no encriptados están disponibles gratuitamente para cualquier persona?

A menos que solo viaje a través de una LAN, entonces sí. Si solo viaja a través de una LAN, entonces agregue el calificador "en esa LAN" y la respuesta será sí.

¿El formulario de inicio de sesión estándar en mi sitio es solo una estratagema para representar una capa de seguridad que ni siquiera está ahí?

Sin

¿Debo entonces considerar la función de inicio de sesión sólo como una manera para mí para personalizar la experiencia del usuario?

Ciertamente, no debe hacer nada grave sin cifrado.

¿Tiene sentido alentar al usuario a NO utilizar su contraseña normal (supuestamente más segura), ya que no estará protegida durante sus procedimientos de registro e inicio de sesión?

Tendría sentido hacerlo para cualquier sistema. Incluso si la comunicación fuera segura, su servidor podría verse comprometido en el futuro, o podría ser un sistema de terceros y luego los datos allí utilizados para atacar su sistema.

Answer 2

Cuando el usuario envía el formulario de inicio de sesión a través de HTTP sin encriptar, sus datos se envían a su servidor mediante una serie de rutas. En cualquiera de estas rutas, sí, alguien podría oler los datos. Además, si la máquina del usuario estaba infectada, el pirata informático podría oler los datos localmente.

Si es un formulario de inicio de sesión, debe utilizar SSL, punto. También asegúrese de que la contraseña del usuario esté encriptada en su base de datos. El proceso para realizar la conexión debe ser:

1. usuario envía acceder a través de HTTPS con nombre de usuario y contraseña
2. servidor toma contraseña y se aplica un algoritmo hash para que, en general, el uso de MD5, aunque se recomienda algo fuerte como SHA256
3. servidor compara el valor encriptado de valor cifrado en la base de datos

esta manera, si su base de datos es cada vez hackeado, las contraseñas son muy, muy difícil de averiguar (a menos que utilizan algo básico como 'contraseña', pero ese es su culpa en ese p oint).

¿Tiene sentido para animar al usuario no utilizar su palabra de paso normal (que se supone más seguro), ya que no estará protegido?

Expulsarás a los usuarios.

Answer 3

Sí.Cualquiera que pueda ver los paquetes que pasan puede ver el nombre de usuario y la contraseña. Esto lo hace especialmente vulnerable cuando se está en redes Wi-Fi compartidas abiertas y similares.

Diría que todas sus suposiciones suenan verdaderas, y esta es especialmente la razón por la cual es una mala práctica compartir contraseñas entre servicios, especialmente cuando esos servicios tienen diferentes niveles de seguridad.

Le aconsejaría que cambie al inicio de sesión SSL si puede, en parte porque muchos usuarios ignorarán cualquier consejo que les dé sobre el uso de una contraseña común, y en parte porque es una buena práctica. Fue una buena práctica antes de cosas como Firesheep se hicieron tan fáciles de usar para las personas "normales", y es aún más importante ahora.

Answer 4

¿Debo considerar la función de inicio de sesión como una forma de personalizar la experiencia del usuario? ¿Tiene sentido alentar al usuario a NO usar su contraseña normal (supuestamente más segura), ya que no estará protegida durante sus procedimientos de registro e inicio de sesión?

Esto depende del sitio web que utiliza el formulario de inicio de sesión. La mayoría de los sitios grandes como Gmail usan https para la autenticación de inicio de sesión y luego cambian a http.(Ha habido informes de que este cambio también presenta algunas vulnerabilidades). Otros sitios envían un valor de sal en un campo de formulario oculto. Su contraseña original se reemplaza con la sal y el hash. La misma operación se repite en el servidor para garantizar que haya enviado la contraseña correcta. Esto sucede detrás de la escena, por lo que un usuario no puede estar seguro de si se envió sin cifrar. Se espera que los sitios buenos hagan esto. Los sitios comunes pueden no hacer esto. Muchas páginas de configuración de enrutadores y módems no emplean cifrado u ofuscación.