Pàgina MDN sobre Contrasenyes insegures
El protocol HTTPS ha estat dissenyat per a protegir les dades d'usuari d'escoltes insegures (eavesdropping, ruptura de confidencialitat) i de modificacions (ruptura d'integritat) a la xarxa. Websites que utilitzen dades personals haurien d'utilitzar HTTPS per a protegir els seus usuaris dels hackers. Si no, és molt fàcil que la informació de l'usuari sigui robada, com per exemple les seves credencials de login. Això va ser demostrat, com és ben conegut, per Firesheep.
Oferir formularis de login insegurs és especialment perillós perquè poden sofrir una gran varietat d'atacs. Els hackers que realitzen les escoltes insegures poden capturar les credencials de la xarxa quan cerquen dins la xarxa o modificar la pàgina servida quan es realiza el Login per a executar-hi un atac.
El panell de securetat de Firefox Web Console adverteix els desenvolupadors si tenen pàgines que demanen contrasenyes, com ara formularis de login, que van sobre una connexió insegura. Hi ha molts escenaris en què un desenvolupador pot fallar en protegir l'experiència de login dels usuaris:
1. Servint el formulari de login sobre HTTP. Encara que l'acció del formulari sigui una URL de tipus HTTPS, el formulari de login no estarà protegit perquè un atacant podria modificar la pàgina rebuda per l'usuari (per exemple, el hacker podria insertar un script de keylogging que extreu la contrasenya mentre s'està escrivint, o que pot canviar la destinació del formulari per a redirigir i guardar la informació sensible enviada a un servidor controlat per ell). A continuació es mostra una captura de pantalla mostrant el problema amb les missatges d'advertència desplegats a la pestanya de seguretat de la consola web::
2. Emprant una URL de tipus HTTP en l'acció del formulari. En aquest cas, les dades que l'usuari escriu son enviades a través de la xarxa en format de text sense xifrar. O sigui, que la contrasenya de l'usuari és clarament visible per a qualsevol hacker que estigui rastrejant la web en el moment que va des que l'usuari espitja el botó fins que les dades arriben al servidor de la vostra web. A continuació es mostra una altra captura de pantalla mostrant el codi HTML del formulari i el missatge d'advertència:
3. Serving the login form in an HTTP iframe (or an HTTPS frame that is embedded in an HTTP frame). Even if the topmost page is HTTPS, including the password field in an HTTP iframe is equivalent to including it in an HTTP page. Attackers can modify the page and steal the user's credentials.
Sometimes websites require username and passwords, but don't actually store data that is very sensitive. For example, a news site may save which news articles a user wants to go back and read, but not save any other data about a user. Web developers of the news site may be less motivated to secure their site and their user credentials. Unfortunately, password reuse is a big problem [link?]. Users use the same password across multiple sites (news websites, social networks, email providers, banks). Hence, even if access to the username and password to your site doesn't seem like a huge risk to you, it is a great risk to users who have used the same username and password to login to their bank accounts. Attackers are getting smarter; they steal username/password pairs from one site, and then try reusing them on more lucrative sites.
