Esta tradução está incompleta. Por favor, ajude a traduzir este artigo do Inglês.
Servir formulários de sessão sobre HTTP é especialmente perigoso por causa da grande variedade de ataques que podem ser utilizados contra eles para extrair a palavra-passe de um utilizador. As escutas ocultas de rede podem roubar a palavra-passe de um utilziador que "farejam" a rede, ou modificando a página servida no trânsito. Esta detalha os mecanismos de segurança que o Firefox criou para alertar os utilizadores e programadores dos riscos que envolvem as palavras-passe inseguras e o roubo da mesma.
The HTTPS protocol is designed to protect user data from eavesdropping (confidentiality) and from modification (integrity) on the network. Websites that handle user data should use HTTPS to protect their users from attackers. If a website uses HTTP instead of HTTPS, it is trivial to steal user information (such as their login credentials). This was famously demonstrated by Firesheep.
To fix this issue, install and configure a SSL/TLS certificate onto your server. There are various vendors offering free and paid certificates. If you are using a cloud platform, they may have their own ways of enabling HTTPS.
Indicadores de segurança de palavra-passe do Firefox
To inform you of the threat described above, Firefox implements many warning mechanisms:
Firefox 51+ will display a lock icon with a red strike-through in the address bar when a login page does not have a secure connection, as seen below.
Firefox 52+ will display a clear warning in the URL bar and below a focused password field in any insecure form:
Firefox 52+ has also disabled autofill for insecure login forms. Users can still manually autocomplete saved logins from the dropdown.
Warnings about insecure login forms can also be found in the security pane of the developer console in all Firefox releases, as described in the next section.
Mensagens da Consola da Web
This section describes the security messages displayed in the developer console of the Firefox DevTools, in response to insecure passwords.
Servindo o formulário de sessão sobre 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 change the form destination to post the sensitive data to a server that they control, or they can insert a keylogging script that swipes their password as they type it). The security tab of the Web Console will warn developers and users about the security issue:
Nota: It's also not secure to embed an HTTPS login page in an HTTP document — an attacker could change the frame URL to point to a malicious site.
Utilizar um URL HTTP na ção de formulário
In this case, any data the user enters is sent through the network as plain text. 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.
Nota sobre a reutilização de palavra-passe
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 to 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. 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 log in 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.
- Não Utilizar Mais Palavras-passe sobre HTTP, Por favor! (inglês)— artigo de blogue detalhado com mais informação, e perguntas frequentes.