Protecting information with user identifiers and passwords is a common objective on the internet. When you see the above login form (if you have JavaScript enabled), what is the first thing you do?
- Do you wonder what lies beyond the roadblock?
- Do you type and submit something?
- Do you check out the source code?
- Do you leave and never come back? If so, skip to the bottom before you go.
When programmers have access to a server-side technology such as CGI, PHP, or ASP/.NET, it's trivial to set up a database of IDs and passwords to authenticate user credentials before they access protected information:
- A user visits a web site that requires login.
- If they are not logged in, the site prompts them for a username and password.
- The user submits the username and password to the web site to compare
against records.
- If the information provided by the user does not match the records, redisplay the login form and try again.
- If the information provided matches the records, let the user access the originally requested content.
- After a certain amount of time or when the user closes their browser, delete their session so that they will have to log in again on the next visit.
While these techniques work for those who have access to server-side technologies, they can't be used to protect information when one does not have access to such technology (for example, those on “Free” websites or bare-bones hosting.) If one cannot use a server-side technology to protect information or if implementing one is overkill, there is an alternative which uses the client-side technology available in most browsers: JavaScript. The technique for hiding non-critical data from random visitors to your website relies on the fact that it is possible to keep the names of the files on your website hidden if they are not linked from anywhere. You wouldn't know that there was some page called “mymarvypage.html” on some random website unless another page linked to it or if you had access to an index of file names. Someone could potentially guess that such a file existed and get lucky, but that gets harder to do when uncommon file names are used.
Let's imagine that you wanted to create a generic password which you would only give to your friends to protect some information on a page: you'd still have to have some sort of way to check that password against a list of “good passwords”. You wouldn't want to store the password somewhere where a visitor can view the source code of your page and know what the password is to access your page. You could encrypt the password with a one-way hashing algorithm and compare user-provided passwords against an encrypted password but you would still have to have a password-to-destination translation and that would give snoopers your protected information.
If the file name of your protected page is the password required to access the page's content, and the page has never been linked to from somewhere else, your information is quite “secure” because nobody knows it's there but you. Unfortunately, it still might be easy to guess the name of your page if you used a simple password; and the password would be stored right there in the address bar for any shoulder surfer to see and memorize. Also, if you wanted to make your password more secure by adding non-alphanumeric characters, you would be limited by the fact that computer file systems often won't let you use certain characters in the names of files.
If, however, you encrypted the password using a one-way hashing algorithm, such as the MD5 algorithm, and made that hash the file name, you will enjoy the security of unlinked files, plus hard(er)-to-snoop file names, plus the use of any character in your password. Free implementations of the MD5 algorithm have already been written in client-side JavaScript for you to employ right now!
When employing this technique to “secure” your information, keep these things in mind:
- Your information is NOT secure! For real security you need to encrypt your data as it's being transmitted between the client and the server so that someone with a packet sniffer can't find your “private” URL.
- Firewalls, routers, proxies, browsers, web server logs and lots of other systems are often configured to store accessed URLs... once your page has been visited, the cat's out of the bag!
- There is nothing stopping someone out there from posting your password to a message board or Bugmenot.com or even putting a direct link to your “private” page on some other site. Only give your password to people you trust (you might even consider creating separate pages with the same content for different people.)
- The more complex the password, the harder it is to guess. Change the password/file name often.
- Check your web server logs regularly to see which DNS or IP addresses have been accessing your “private” pages (or making failed attempts!)
- If you're really concerned about security, use a server-side solution with HTTPS/SSL encryption.
If you're still wondering what the password to the form on this page is, it's "password" (minus the double-quotes.)
Scripts required for this page:
<script type="text/javascript" src="http://scriptar.com/JavaScript/md5-minify.js"></script>
<script type="text/javascript" src="http://scriptar.com/JavaScript/login-minify.js"></script>