understanding the importance and impact of anonymity and authentication in a networked society
navigation menu top border
navigation menu bottom border
left side navigation top border

left side navigation bottom border

left side navigation top border
left side navigation top border

main display area top border
PDF Print
“A Man’s Home (Page) is His Castle”
By: Carlisle Adams

November 28, 2006


Many of us have probably heard the saying “a man’s home is his castle”. (By way of parenthetical footnote, let me just mention that I could not find an elegant way to make this old adage gender-neutral: “an [(unspecified gender) entity]’s home is [(unspecified gender) possessive pronoun] castle”. Therefore, for the purposes of this article, I will just state up front that “man” and its variations should be taken to mean “man or woman” and their corresponding variations, and hope that this satisfies any sensitivities in this area.) This saying has been around for quite some time and most people, I think, would probably have some intuitive understanding of its meaning upon hearing or seeing it. However, given some of the new terminology with which we have become accustomed in our Internet age (particularly, “home page”), it may be interesting to explore whether this saying has any relevance in our digital virtual world.

Traditionally, a castle (the residence of a king) has been associated with at least four concepts: protection; identity; privacy; and control. With respect to “protection”, the castle provides a fortress, a stronghold, security from invaders of all kinds. “Identity” suggests ownership, permanence and, at least at some level, a way of authenticating oneself (“I am the king because I have the key to the drawbridge, or because the guard will let me in when I show up”). In terms of “privacy”, the castle is a means of keeping its inhabitants and their discussions away from prying eyes and ears, so that secrets are prevented from flowing out to the general public. The castle also gives a sense of “control” in that the king has ultimate authority over certain aspects of the domain (e.g., the power to decide content and activity within the walls).

When it is said that a man’s home is his castle, the analogy is clear: with his home, the man gets – or at least expects – a measure of protection, a sense of identity, some level of privacy, and a degree of control. So now, out of curiosity if nothing else, one can ask, when we say today that a man has a home page, is the analogy as clear, or is it stretched so thin as to be fragile and useless? Let’s consider the above four associations with the term “castle” to see how well they apply to our digital (rather than physical) homes.

Protection. When Bob sets up a Web server and creates on that server a home page for himself, does he have the security from invaders that a castle might provide? Even a superficial awareness of security issues with websites over the past few years will confirm that the answer is “no”: attackers break into websites every day all over the world to enter, change, or steal data. Well-known buffer overflow or SQL injection attacks are commonly used to break into websites to cause damage. If a website is expecting some user input (such as a username and password), the attacker may send far more data than the buffer allocated to receive this data can hold (a password of 10,000 characters, for example). This input data may “spill over” beyond the buffer into another area of memory. If the overflow area is a place where instructions are executed, and if the overflow characters are carefully constructed to be valid executable instructions, then this attacker will have succeeded in having arbitrary code of his choosing run on Bob’s machine. This is the essence of a buffer overflow attack. With SQL injections, the attack is similar in that data input by the user contains some extra, unexpected characters and these characters are treated as commands to the SQL database that sits behind Bob’s webpage.

If Bob has routines that do proper input data validation (e.g., make sure that the username that has been entered is really a username and is not longer than a specified value), he may be able to avoid some of these attacks, but it is not always easy to distinguish an attack script from valid data. Unfortunately, the conclusion is that unless he puts extensive effort into setting up particular safeguards, Bob’s home page gives him very little protection from the malicious entities that live outside his “virtual walls”.

Identity. Is Bob’s home page a valid mechanism for showing ownership and authenticating himself? The answer to this question is also negative. Webpage spoofing attacks are not very difficult to perform and can be fairly successful. Making an identical copy of an existing webpage is almost trivial (it is essentially a copy-and-paste operation to move every image, every piece of text, every logo, etc., from one webpage to another. The (slightly trickier) step is to get other people to go to the new site while thinking that they’re going to the old one. This can be accomplished using a technique called DNS cache poisoning. The Domain Name Server (DNS) is a machine that performs an important service on the Web: you give it a host name (such as bob.com) and it gives you back the IP address of that host machine (such as 192.12.567.30). This way, your computer can communicate with that machine using the Internet Protocol (IP). The data pair {bob.com, 192.12.567.30} is stored in the DNS cache (a fast portion of its memory). Cache poisoning is an attack in which that the attacker changes the data pair so that bob.com is instead associated with a different (i.e., the attacker’s) IP address in the DNS cache. Now everyone that wants to go to Bob’s machine will send bob.com to DNS, get back the attacker’s IP address, and then go to the attacker’s website, which has been made to look identical to Bob’s site. Thus, the attacker gets Bob’s customers (their money, or their personal data), and Bob has no way of knowing that this has occurred.

If Bob’s machine is a Web server, technologies such as SSL server authentication can help, but they provide no guarantee: users often do not check that the certificate of the site they have reached is the one they’re expecting, and often ignore warnings in pop-up windows even if they do check. In general, website spoofing means that Bob’s home page is not sufficient to prove ownership or to validate or authenticate Bob in any way.

Privacy. Does Bob’s home page give him a private place to store his personal and confidential information? At first glance, this seems like an odd question to even be asking: the Internet is a public space and Internet search engines (such as Google) will find a website once it exists (this is what they were invented to do). The idea of putting something on a website and expecting it to be private is a bit like building a house with glass walls and expecting that others will not see what goes on inside. However, it is possible to create private spaces within a website; typically, these are password-controlled areas (anyone with the password can view the page, and all others are redirected to another page telling them that they are not authorized to see the contents). But the problems with passwords as an authentication mechanism are extremely well-known and well-documented. Compounding this is the fact that the site owner usually wants a number of people to access these areas (friends, family, students in a course, etc.) and so will deliberately choose a password that will be easy for that group of people to remember. It may therefore be conjectured that the passwords used to protect these areas are probably even weaker than typical passwords, which are notoriously weak in many cases.

It is unlikely to be the case that Bob’s home page will be a safe place for his private data.

Control. Does Bob have authority over his home page? Does he have the power to decide content and activity? Again we see that the answer to this question is negative. Website defacement (in which a hacker changes the content or appearance of a target website, altering or inserting messages, pictures, or other data) shows that owners do not really have complete power over the content on their sites. Furthermore, session hijacking attacks (in which a hacker takes over an active session and begins interacting with the server as if he was the original client, or interacting with the client as if he was the original server), buffer overflow attacks, SQL injection attacks, and so on, demonstrate that the site owner may also have little power over the activities that take place on his site.

Integrity detection / protection mechanisms, intrusion detection / protection mechanisms, and good session management practices can all help but these are hard to do well and, again, unless Bob takes extensive efforts to defend his website, he will not have the control over content and activity that he might wish to have.

Where do we go from here?

OK, so home pages don’t really have any of the properties we might associate with homes. But “home” and “home page” are just names; what difference does any of this make? At this point, it may be tempting to pull out another old saying: What’s in a name? That which we call a rose by any other name would smell as sweet [1]. There may be much truth in this (after all, Shakespeare was right about a great many things!), but we need to exercise a little caution. The danger lies not in using two different names for the same thing, but rather in using the same name (or very similar names) for two different things: “home” and “home page”. All the security (i.e., protection, privacy, identity, and control) we associate with our home does not translate immediately to our home page. Although there are some similarities (locking the front door with a key is something like password-protecting the website), there are some major differences as well (for example, website spoofing: the attacker makes an exact replica of your house and fools your family and friends into going there when they want to visit you? Nothing in the real world (outside the “twilight zone” [2]) corresponds to this). Using essentially the same term (“home” and “home page”) could lead the unsuspecting user to think that similar behaviour – both precautions and activities – are appropriate, when in fact this is not the case.

I am not advocating that we should call home pages something else (it’s far too late for that sort of change, although “start page” might have been a good choice that is free of other associations). But I am suggesting that this could serve as a reminder to us that we need to be careful when naming things in our created virtual worlds. Choosing names that are familiar (so that people will more readily identify with the technology and feel comfortable using it) can have unintended consequences (including behaviour that is inappropriate because the technology is not as much like its real-world name-sake as the appellation might imply). Let this be a lesson to us: choosing names for concepts should not be taken lightly; we need to think through the connotations of the names we pick and consider whether this may lead to security or privacy problems down the road.

So, a man’s home (page) is his castle? Not really; not in the new Wild West of cyberspace…


[1] Romeo and Juliet, Act II, Scene 2.
[2] http://www.scifi.com/twilightzone/
main display area bottom border

.:privacy:. | .:contact:. | .:1rxdrugs.net:.

This is a SSHRC funded project:
Social Sciences and Humanities Research Council of Canada

© 2014 On the Identity Trail
Joomla! is Free Software released under the GNU/GPL License.