- Check password strength by checking the contents of “password” fields before being submitted:
- Length. Warn users trying to submit a short password that it’s short enough to be brute-forced.
- Entropy. Possibly encourage users to use a combination of upper and lowercase letters, numbers, and symbols.
- Dictionary. This is something that browsers are in a unique position to check for by including a “common passwords” dictionary with the browser. Check against a dictionary of the top, say, 10,000 – 100,000 most commonly-used passwords (see https://xato.net/passwords/more-top-worst-passwords/), and warn the user that crackers will be checking these first, since the top 10,000 passwords are used by 99.8% of users’ accounts.
- Include a client-side password hashing mechanism, which could hash a combination of the password, username, and sitename with something like bcrypt. This would require some controls to limit the length and allowable characters to make the resulting password hashes compatible with various sites. If this were an industry-standard hashing function used by various browsers, they could all use the same rules, making password hashes portable across browsers and platforms.
- Anonymize the user agent in private browsing mode by not reporting fonts, plugins, or perhaps even the operating system in use, and only a fairly generic version for the browser.
- Enable “opportunistic” encryption in private browsing mode. This would be different from HTTPS Everywhere (though you might want to enable that, too). In this case, if the page was requested over regular http, test for the presence of https, and if port 443 is open and there’s a certificate installed, use it to communicate with the server (without asking or informing the user). If there are certificate problems, don’t report to the user that you’re using an https connection, but do use the “untrusted” encrypted connection since it’s likely more secure (certainly from passive listening) than regular http. Similarly, if any “mixed” content cannot be loaded securely (even after testing for an https connection, for instance from a different server which does not have https enabled), load it anyway. The goal here isn’t to ensure the connection is 100% encrypted, trusted, or protected from MITM (man-in-the-middle) attack, it’s just to opportunistically make use of as much encryption as possible where it is available. Just make sure not to mislead the user about how secure the connection is.
- Encourage the use of VPN services (including TOR) while in private browsing mode. Preferably have a list of “vetted” VPNs and an easy way to get set up using them.