HTML Password Protection: Should You Password Protect HTML Pages?
What is HTML Password Protection?
HTML password protection describes a method by which HTML is protected by means of a password from being read using a browser or text-based editor. While there are a wide variety of ways in which HTML, using passwords is the most common due to their convenience for users.
As its title implies, HTML password protection is a method for protecting HTML code or access to specific HTML pages. We need to remember that in law, both the form and format of a document are critical. And HTML is a markup language that was derived from SGML in order to describe hypertext and how it should be interpreted and displayed.
Using passwords to protect HTML pages and HTML code
There are several common ways to implement a basic password gate on an HTML page. These methods range from client-side scripts to server configuration tweaks:
- JavaScript password prompts: A simple method is to add a JavaScript prompt or form on specific pages asking for a password. That password is then checked against a stored password, which is often hardcoded or hashed in the HTML/JS. If it matches, access is granted via redirect or by revealing a hidden div. The advantage of this method is that it doesn’t require any server processing; everything happens in the user’s browser.
- Apache .htaccess/.htpaswd: Using web server features such as .htpasswd in Apache is a bit more secure because the password check occurs on the server side. This makes it much more difficult to bypass.
- Client-side HTML encryption tools: Client-side encryption tools such as StatiCrypt or PageCrypt let you AES-256 encrypt a static site using a chosen password. Content is then decrypted on the fly when the password is provided, meaning users can’t spy on hidden content using their browser’s developer mode.
While some of these implementations are better than others, they all have some significant issues.
The issues with HTML password protection
Password protection, as a technique, has enjoyed what can best be described politely as a charmed life. There are many published articles on the flaws and inadequacies of using passwords to protect any information, let alone a HTML file. At the time of writing, Google listed some 39 million entries for the search ‘flaws in password protection’, listing primarily either a flaw that enabled a hacker to bypass the protection or a tool that allowed that bypass. Some of the most common flaws with HTML password protection include:
- JavaScript-based password prompts are extremely insecure. The password and logic reside in the page source, which users can access via their browser’s developer mode. They can then find the password, crack the hash, or modify the script.
- Web server-based techniques aren’t perfect either. Passwords can still be brute-forced, phished, intercepted (if the connection isn’t over HTTPS), or shared.
- Client-side HTML encryption may still be bypassed. As the decryption key is derived from a user-supplied password, and the cryptographic operation happens client-side, it’s open to manipulation. See HTML encryption for more details.
- Basic HTML passwords are a shared secret approach. Often, content is protected with the same password for all users. This makes it easy for users to share without consequence.
- HTML passwords grant no control after access or audit trail. A lot of attention is dedicated to stopping users from gaining access to content, but what about when they do? HTML passwords don’t provide any protection against somebody downloading your content and sharing it with others, copy-pasting content, printing, etc. As most techniques use a shared password, it also doesn’t allow you to tell when/if a particular user accessed the page and what they did on it.
- The administration and use of effective passwords to protect any information is complex. Either the passwords are at least 25 characters long, which is totally impossible for any human being to commit to memory or type in reliably, or they are short enough to be trivial to a cracking program. Passwords may also be obtained via a social engineering attack.
There are some mitigations for these flaws. Password managers, for example, provide a solution to this by allowing users to save passwords and autofill them from a secure vault. However, they have their own problems. First and foremost, the vault is usually secured by a single master password, which can be phished, stolen by malware, brute-forced, or leaked to grant access to all of a user’s passwords. Or, to put it succinctly, it represents a single point of failure.
Authenticating passwords on the server-side also improves security, as does implementing additional authentication tools like user accounts with SSO and conditional access controls.
However, none of this changes the fundamental fact that if you’re trying to prevent the intentional sharing of sensitive or copyrighted HTML content, passwords are of little help. Users can share them just as easily as they could an unprotected file or a link to a webpage.
Further, the only real way to prevent content from being downloaded, copied, or printed in the web browser is by using JavaScript. As we mentioned earlier, this executes primarily on the client-side, which means it can be tampered with and usually bypassed. Further, it can’t stop users from performing basic system functions such as taking screenshots, which represents a very common and low-effort way to share content.
So why has HTML Password Protection been around for so long?
The fact that HTML password protection is often so poor makes you wonder why it has been so widely implemented. The simple answer is that everything started with passwords; in fact, a password is still the most popular and most implemented security mechanism in the world. Though everyone knows that passwords are not a very secure method, people are used to them, and lots of software supports them. This reduces friction from a user experience and development perspective. You do what you can with what is available.
Today, better and stronger methods and mechanisms are available, and increasingly we are seeing these implemented by the more advanced suppliers. HTML passwords are useful primarily for low-stakes scenarios such as:
- Draft webpages: In-progress pages for clients or other partners rarely contain sensitive information, and basic protection is therefore usually okay.
- Non-sensitive private pages: There are various pages where you don’t necessarily want people to have free access, but it won’t be particularly damaging if they gain it. For example, a family blog, classroom materials, and event planning pages.
For everything else, you should be looking for stronger security than HTML protection provides. The reality is that HTML passwords are rather what you make of them. Longer and stronger or shorter and easier to cope with? Most systems offering HTML password protection lag so far behind the reality of what current computers are capable of that they are laughable in the extreme, and it is difficult to defend the people who are offering this kind of service as a serious security mechanism.