mozilla

Revision 643855 of InsecurePasswords

  • Revision slug: Security/InsecurePasswords
  • Revision title: InsecurePasswords
  • Revision id: 643855
  • Created:
  • Creator: siyaam
  • Is current revision? No
  • Comment

Revision Content

Insecure Passwords MDN page
 
The HTTPS protocol is designed to protect user data from eavesdropping (breach of confidentiality) and from modification (breach of integrity) on the network. Websites that handle user data should use HTTPS to protect their users from hackers. Without it, it is trivial to steal user information (such as their login credentials). This was famously demonstrated by Firesheep.
 
Serving insecure login forms is especially dangerous because of the wide variety of attacks that can be used against them. Network eavesdroppers steal a user's credentials directly by sniffing the network, or modify the served page in transit to enable a plethora of attacks.
 
The security panel in the Firefox Web Console warns developers if they serve pages that request passwords, like login forms, over an insecure connection. There are several scenarios in which a web developer can fail to protect their user's login experience:
 
1. Serving the login form over HTTP. Even if the form action is an HTTPS URL, the user's login form is not protected because an attacker can modify the page received by the user (for example, attackers can insert a keylogging script that exfiltrates their password as they type it, or they can change the form destination to post the sensitive data to a server that they control). Here is a screenshot presenting the problem with the relevant warning messages displayed in the security tab of the web console:
 
Login Fields on an Insecure Page
 
2. Using an HTTP URL in the form action. In this case, any data the user enters is sent through the network in cleartext. The user's password is clearly visible to anyone sniffing the network from the time the password leaves the user's computer to the time it reaches your website's servers. Here is another screenshot presenting the html source of the form and the relevant warning message:
Login fields on a form with an http:// action
 
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.
Login fields on an http:// iframe
 
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.
 

Revision Source

<div id="magicdomid2">
 <span class="author-g-xb9r5a26crrtk8p5">Insecure Passwords MDN page</span></div>
<div id="magicdomid3">
 &nbsp;</div>
<div id="magicdomid4">
 <span class="author-g-xb9r5a26crrtk8p5">The <a href="https://en.wikipedia.org/wiki/HTTP_Secure" title="https://en.wikipedia.org/wiki/HTTP_Secure">HTTPS</a> protocol is designed to protect user</span><span class="author-g-nz122z8n36s7o58x0fxu"> </span><span class="author-g-xb9r5a26crrtk8p5">data from eavesdropping (breach of confidentiality) and from modification (breach of integrity) on the network. Websites that handle user data should use HTTPS to protect their users from hackers. Without it, it is trivial to steal user information (such as their login credentials). This was famously demonstrated by <a href="http://codebutler.com/firesheep/" title="http://codebutler.com/firesheep/">Firesheep</a>.</span></div>
<div id="magicdomid5">
 &nbsp;</div>
<div id="magicdomid8">
 <span class="author-g-xb9r5a26crrtk8p5">Serving insecure login forms is especially dangerous because of the wide variety of attacks that can be used against them. Network eavesdroppers steal a user's credentials directly by sniffing the network, or modify the served page in transit to enable a plethora of attacks.</span></div>
<div id="magicdomid9">
 &nbsp;</div>
<div id="magicdomid10">
 <span class="author-g-xb9r5a26crrtk8p5">The security panel in the Firefox Web Console warns developers if they serve pages that request passwords, like login forms, over an insecure connection. There are several scenarios in which a web developer can fail to protect their user</span><span class="author-g-nz122z8n36s7o58x0fxu">'</span><span class="author-g-xb9r5a26crrtk8p5">s login experience:</span></div>
<div id="magicdomid11">
 &nbsp;</div>
<div id="magicdomid12">
 <span class="author-g-xb9r5a26crrtk8p5">1. Serv</span><span class="author-g-nz122z8n36s7o58x0fxu">ing</span><span class="author-g-xb9r5a26crrtk8p5"> the login form over HTTP. Even if the form action is an HTTPS URL, the user's login form is not protected because an attacker can modify the page received by the user</span><span class="author-g-nz122z8n36s7o58x0fxu"> (</span><span class="author-g-xb9r5a26crrtk8p5">for example</span><span class="author-g-nz122z8n36s7o58x0fxu">, attackers can</span><span class="author-g-xb9r5a26crrtk8p5"> insert a keylogging script that exfiltrates their password as they type it</span><span class="author-g-nz122z8n36s7o58x0fxu">, or they can change the form destination to post the sensitive data to a server that they control). Here is a screenshot presenting the problem with the relevant warning messages displayed in the security tab of the web console:</span></div>
<div>
 &nbsp;</div>
<div>
 <img alt="Login Fields on an Insecure Page" src="https://mdn.mozillademos.org/files/5951/insecure_page2_with_arrows_cropped.jpeg" style="width: 1072px; height: 517px;" /></div>
<div>
 &nbsp;</div>
<div id="magicdomid15">
 <span class="author-g-nz122z8n36s7o58x0fxu">2. Using an HTTP URL in the form action. In this case, any data the user enters is sent through the network in cleartext. The user's password is clearly visible to anyone sniffing the network from the time the password leaves the user's computer to the time it reaches your website's servers.</span> Here is another screenshot presenting the html source of the form and the relevant warning message:</div>
<div id="magicdomid16">
 <img alt="Login fields on a form with an http:// action" src="https://mdn.mozillademos.org/files/5947/insecure_form_action2_with_arrows_cropped.jpeg" style="width: 1072px; height: 468px;" /></div>
<div>
 &nbsp;</div>
<div id="magicdomid17">
 <span class="author-g-xb9r5a26crrtk8p5">3. </span><span class="author-g-nz122z8n36s7o58x0fxu">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.</span></div>
<div id="magicdomid20">
 <img alt="Login fields on an http:// iframe" src="https://mdn.mozillademos.org/files/5953/insecure_iframe3_with_arrows_cropped.jpeg" style="width: 1072px; height: 710px;" /></div>
<div>
 &nbsp;</div>
<div id="magicdomid21">
 <span class="author-g-nz122z8n36s7o58x0fxu">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.</span></div>
<div id="magicdomid22">
 &nbsp;</div>
Revert to this revision